[throwaway894345]

Monoliths are pretty great, and there are tons of valid criticisms of microservices; however, this comment managed to steer clear of all of them. :)

> The term "Monolith" was devised by people who wanted to brand microservices as newer and superior.

Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparaging, so if Big Microservices we’re trying to disparage monolithic architectures, why wouldn’t they use a term with a negative connotation?

> If it's not broken, don't fix it... Microservices are relatively new and unproven.

The microservices people would argue that monoliths are broken for many use cases. In particular, individual teams can’t deploy their code without coordinating with every other team, which yields long user feedback loops and a bunch of other knock-on effects. Microservices exist to support nimble organizations by helping to remove technical coupling between teams. This is all 101-level stuff but the microservices critics always ignore it in their criticism.

> Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases... Thereby locking a customer into platform-specific dependency.

I don’t think you could be more incorrect :). Microservices are almost universally built atop containers, and the whole purpose of containers is to decouple the application from the platform.

> We have also seen enough failures and pain points within microservice and even cloud architectures over the past two years alone to raise questions about whether or not it it indeed a better solution.

Microservices are typically more robust than monoliths if only because components are isolated—a failure in a superficial component doesn’t bring the whole app down. Moreover, monoliths are less secure as well because there’s no way to regulate permissions within the process—anything one component can do, the whole system can do.

> The more we allow marketing minds to take control of our IT decisions over reasonable technical minds

Literally laughing out loud at the idea that marketing people are behind microservices.

[TheOtherHobbes]

>individual teams can’t deploy their code without coordinating with every other team, which yields long user feedback loops and a bunch of other knock-on effects

Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly...

>the whole purpose of containers is to decouple the application from the platform.

Are containers not a de facto platform?

>Literally laughing out loud at the idea that marketing people are behind microservices.

Here's a moderately complete list of products. How many are pay-to-play?

https://www.aquasec.com/cloud-native-academy/container-platf...

All you're really doing with containers is creating a meta-monolith running on external hardware with custom automation - managed by an ever so handy third party software product. Also running on external hardware. All of which you're paying for.

You can also DIY and not pay. In theory. But really...?

This makes sense at global scale where you're drowning in income and need to handle all kinds of everything for $very_large_number customers.

It's complete madness for a small startup that doesn't even have a proven market yet.

[throwaway894345]

> Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly...

1. Right--you only depend on other teams when you need to

2. Even in this case, you just version your API, deploy your new version at your leisure, and incrementally move people over to the new version while deprecating the old version.

> Are containers not a de facto platform?

Not in any interesting or meaningful sense. Containers are precisely the technology that allow you to pack up and go to a different orchestrator or cloud provider. Note that the original concern was being locked into a cloud provider or PaaS--what does it mean to be "locked into containers"? Who has ever been "locked into containers"?

> Here's a moderately complete list of products. How many are pay-to-play?

You're conflating a lot of things. First of all containers aren't micro services or vice versa. Containers are just an interface for processes, and they enable things like orchestrators. "Containers versus <whatever>" is orthogonal to "micro services vs monoliths". Secondly, there's nothing about paying for something that implies more lock-in. Whether you're paying or not, it's a lot easier to transition between platforms with micro services than with a monolith (micro services can move incrementally while a monolith has to move all at once or be painstakingly broken into micro services).

> All you're really doing with containers is creating a meta-monolith

With the enormous caveat that microservices can be deployed independently and even on different platforms and use different technologies... Which is to say microservices are nothing like monoliths. :)

> This makes sense at global scale where you're drowning in income and need to handle all kinds of everything for $very_large_number customers.

It makes sense if you have more than a few teams.

> It's complete madness for a small startup that doesn't even have a proven market yet.

There are degrees between "small startup without a market" and "global scale / drowning in income". But yes, I agree that microservices aren't a good fit for the very earliest, smallest-scale companies.

[patrick451]

> Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparaging, so if Big Microservices we’re trying to disparage monolithic architectures, why wouldn’t they use a term with a negative connotation?

This isn't the reality on the ground. Where I currently work, "Monolith" is absolutely used as a pejorative by those advocating for microservices.

[throwaway894345]

I can't speak to your workplace, but in the broader debate it's never been pejorative. It's always been neutral and descriptive. If they wanted to use a pejorative title, they could have gone with "bulky" or "cumbersome" or "inflexible" or any other number of loaded descriptors.

[edgyquant]

Right but the term monolith was used in at the latest in the 80s to describe kernels (monolithic v micro) so it’s a fairly standard term in software.