> I'm an independent developer right now, building systems for businesses and there is literally no better way to deliver line-of-business internal applications than via a monolith.
This is the same sort of myopic, naive, clueless take that led people armed with this blend of specious reasoning to dive head-first onto microservices architectures without looking at what they were doing and thinking about the problems they are solving.
The main problems that microservices solve are a) organizational, b) resilience, c) scalability.
If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours then there's nothing preventing you from keeping all your eggs into a single basket.
If you work on a professional environment where distinct features are owned by separate teams then you are way better off running separate services, and perhaps peel out shared responsibilities to a separate support service. This is a fact.
But let's take it a step further. You want to provide a service but some of the features are already provided by a separate service either provided by a third-party or whose project you can simply download and run as part of your deployment. Does this count as a microservices architecture to you or is it a monolith?
Consider also that your client teams have a very specific set of requirements and they rolled out services to provide them. Is this a microservices architecture or a monolith?
Consider also that you start with a monolith and soon notice some endpoints trigger workflows that are so computationally demanding they cause brownouts, and to mitigate that these are peeled out of the monolith to dedicated services to help manage load. Is this a monolith or microservices?
Consider that you run a monolith and suddenly you have new set of requirements that forces you to do a major rewrite. You start off with a clone of the original monolith and gradually change functionality, and to avoid regressions you deploy both instances and have all traffic going through an API gateway to handle dialups. Is this microservices or monolith?
The main problem with these vacuous complains about monoliths is that they start from a place of clueless buzzwords, not understanding what they are talking about and what problems are being addressed and solved. This blend of specious reasoning invariably leads jumps from absolutisms to other absolutisms. And they are always wrong.
I mean, if problems are framed in terms of fashion tips, how can the possibly be right?
> If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours then there's nothing preventing you from keeping all your eggs into a single basket.
There's a whole spectrum between that and "needs to go down for less than a minute per year". For every project/job/app that needs the AWS levels of resilience and availability, there are maybe a few 100k that don't, and none of those are the "barely-used, down for hours" type of thing either.
Having been a developer since the mid-90s, I am always fascinated by the thought that computer, server and/or network resilience is something that humanity only discovered in the last 15 years.
The global network handling payments and transactions worked with unnoticeable downtime for 30-odd years; millions of transactions per second, globally, and it was resilient enough to support that without noticeable or expensive downtime.
> For every project/job/app that needs the AWS levels of resilience (...)
I don't think you're framing the issue from an educated standpoint. You're confusing high-availability with not designing a brittle service by paying attention to very basic things that are trivial to do. For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services. You only need a reverse proxy and just enough competence to design and develop services that can run in parallel. This is hardly an issue, and in this day and age not being able to pull this off is a hallmark of incompetence.
> I don't think you're framing the issue from an educated standpoint.
And I think you'd make a better point without the personal remarks and/or skepticism over my competence.
I mean, was all this really necessary to make your point?
> myopic, naive, clueless take
> specious reasoning
> If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours
> a place of clueless buzzwords
> not understanding what they are talking about
> hallmark of incompetence
I also think you're ignoring what I said about 30-odd years of resilience that came before microservices.
> For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services.
I'm genuinely confused here: what does that have to do with creating monoliths? Are you claiming that monoliths prevent a whole lot of good practices (blue-green, canary deployments, whatever)?
Because monoliths have been deployed in a gradual rollout fashion before, have been multi-sited for DR rollovers onto secondaries, have been deployed with hot rollovers, etc.
There are, right now, COBOL "monoliths" running and managing a significant part of your life.
This is the same sort of myopic, naive, clueless take that led people armed with this blend of specious reasoning to dive head-first onto microservices architectures without looking at what they were doing and thinking about the problems they are solving.
The main problems that microservices solve are a) organizational, b) resilience, c) scalability.
If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours then there's nothing preventing you from keeping all your eggs into a single basket.
If you work on a professional environment where distinct features are owned by separate teams then you are way better off running separate services, and perhaps peel out shared responsibilities to a separate support service. This is a fact.
But let's take it a step further. You want to provide a service but some of the features are already provided by a separate service either provided by a third-party or whose project you can simply download and run as part of your deployment. Does this count as a microservices architecture to you or is it a monolith?
Consider also that your client teams have a very specific set of requirements and they rolled out services to provide them. Is this a microservices architecture or a monolith?
Consider also that you start with a monolith and soon notice some endpoints trigger workflows that are so computationally demanding they cause brownouts, and to mitigate that these are peeled out of the monolith to dedicated services to help manage load. Is this a monolith or microservices?
Consider that you run a monolith and suddenly you have new set of requirements that forces you to do a major rewrite. You start off with a clone of the original monolith and gradually change functionality, and to avoid regressions you deploy both instances and have all traffic going through an API gateway to handle dialups. Is this microservices or monolith?
The main problem with these vacuous complains about monoliths is that they start from a place of clueless buzzwords, not understanding what they are talking about and what problems are being addressed and solved. This blend of specious reasoning invariably leads jumps from absolutisms to other absolutisms. And they are always wrong.
I mean, if problems are framed in terms of fashion tips, how can the possibly be right?