[winternett]

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

It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.

If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into microservice infrastructure only highlights reckless spending and waste that is characteristic of overpriced goods and high taxes that are constantly in turn thrust upon us, as consumers.

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. Microservices architecture also introduces the ability for providers to charge for each specific service as a utility... Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it's a sticker shock that you can only stop by going offline.

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.

We need to stop disparaging traditional (non-cloud) hosting and solutions that aren't obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.

The more we allow marketing minds to take control of our IT decisions over reasonable technical minds, the more costly it will be to us all over time, no matter what salary we make. Bog tech firms will hate me for saying this, but any human in the chain can tell that reckless drive for weak/vulnerable/costly/and over-complex IT solutions cannot be sustained as a viable long-term business sales strategy anyway.

[serial_dev]

Microservices make sense in some scenarios.

I work at a large retail company with who knows how many developers. We have different teams for payment, promotions, product search, account, shipping and more. All of them working on a single codebase with coordinated deployments would be a nightmare.

Previously, I joined a startup (previous coworkers of mine), a developer and a business guy. The developer "drank the microservices kool-aid", and came up with (in theory) super scalable solutions and like a dozen of microservices. It was difficult to keep things in mind, the tech stack was way too complicated for two developers. It was also less performant and more costly. The added complexity was totally unnecessary, especially because we never got neither tons of users, nor more developers. The business guy trusted the developer, so the company never worked enough on their product and USP. I guess the developer just didn't want to accept that the fancy tech solutions won't bring success.

Yet another time, we were a small team (5-ish devs, product owner, and a designer). We started with a monolith and we paid attention to software design and moved quickly.

Also, for some reason it's often overlooked, that you can make your monolith modular and design it so that when the day comes, you can split it up into smaller services. You don't need to start with microservices, you can start with a monolith and figure out later how to split it up (if necessary).

Microservices and "monoliths" have their place, you just need to know when to use which.

[winternett]

This is agreeably congruent with my original statement,

The main problem I have with microservice marketing:

It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them.

That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily.

And clients are often not aware of the operational costs that can rise over time for each component of the distributed architecture.

"Monolithic" solutions have also not stagnated... They can be run in distributed methods, they can leverage microservices in parts, they can also leverage containers, they are far from obsolescence because they are using the same languages that microservice architectures use, just with less distribution overall.

The term monolithic is often used to indicate that less-distributed solutions are somehow "out of date", "obsolete" and "not innovating" inaccurately, when the real story is that the business case usually dictates which solution will fit best.

[throwaway894345]

You’re confusing “microservices” with dependencies on a particular platform (presumably cloud providers). Microservices aren’t more likely to have these dependencies, as monoliths are often also deployed on cloud providers and assume a particular database, etc.

Anyway, if you’re dealing with microservices “lock-in” isn’t a real problem—you just move one service over to your new platform at a time. Good luck doing that with your monolith without decomposing it into services (and frankly, if you can feasibly decompose your monolith into services, your architecture is probably cleaner than 95% of monoliths out there).

[edgyquant]

It really doesn’t seem like they are confusing microservices, I’m not sure what makes you think that.

[throwaway894345]

> That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily.

[withinboredom]

There’s really not much coordination with a monolithic deployment. Merge your commit and get in line. Monitoring tools will ping you on slack if there’s any issues. It’s probably easier than micro services because all tooling and builds are centralized.

[serial_dev]

> Merge your commit and get in line.

Much easier said than done, if there are 50+ devs working on the same service (monolith). Decisions are made much slower, improvements need to go through long discussions, deployments are much more risky, onboarding is a hassle, and so on. Sure, monoliths work very good for small teams (it's hard to define what "small" is), but I'd say that around 15-30 developers you can think about splitting up.

[withinboredom]

Are you saying this from experience? From my experience working on a monolith every day with around 400-500 other devs, this is not the case. I don’t even need a code review for minor things. Just commit and get in line (about 2-3 minutes before my commit hits 100% of production).

[biorach]

Yes! This really sums it up - they have their place, but it takes experience and good judgement to know where they are appropriate, and how to divide up concerns.

[staticassertion]

> It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.

Meh. In order to sound smart on HN it's easiest to point at something and call it "hype".

> Microservices are relatively new and unproven

SOA is old as fuck. Microservices are also fairly old, but especially when you consider they're really just SOA + dogma.

> 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...

No? Not at all.

> Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it's a sticker shock that you can only stop by going offline.

Alternatively phrased: If you only use one service you only pay for it, not for the whole suite of features you don't need or want.

> 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.

And plenty of success stories.

> We need to stop disparaging traditional (non-cloud) hosting and solutions that aren't obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.

Microservices work, are secure, and are cost effective.

Honestly your post contains no useful information and is satirically close to a "return to traditional family values!" speech.

[throwaway894345]

That’s exactly what Big Microservices wants you to think.

[glintik]

> Microservices are relatively new and unproven.

They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.

[da_chicken]

> Splitting monolith into services(not always been micro) is a natural evolution for any software.

No less natural than "joining the innumerable incompatible and bug-ridden fragments into a single unified solution."

Linux is a bazar. Except distros and package repositories are cathedrals.

Windows is a cathedral. Except software distribution is a bazar.

[Clubber]

It was SOA (Service Oriented Architecture) where you would split them up, that predates Microservices by quite a bit. I remember doing that in the early 2000s.

What I think he is saying is that Microservices people pitch their service against monolith as better, but monolith hasn't been in vogue for 20 years. I saw the same tactic with scrum people pitching against waterfall which hadn't been in vogue for quite a while either.

[hdjjhhvvhga]

Well, SOA is such a broad term. If you include CORBA, you could say it's terrible. On the other hand, gRPC is a pleasure to work with if you need to deal with different environments.

[xtracto]

> On the other hand, gRPC is a pleasure to work with if you need to deal with different environments.

I remember doing RPC via Java RMI and Jini at some point early in my career in the late 90s. It was really nice and gRPC reminded me of that.

[jbverschoor]

Although clunky to implement, EJB had really well thought out concepts, architecture and roles

[pjmlp]

I miss dealing with Websphere every time I am fixing Kubernetes spaghetti.

[throwaway894345]

The OP was pretty explicitly arguing in favor of monolithic architecture.

> The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.

[rzz3]

Yeah, it used to be called “Service Oriented Architecture”, and is nothing new.

[winternett]

Agreed in essence... The ideology is indeed old, but the practice of putting flashy wrappers and catchy names around the services are new.. Like "Dynamo DB" and "Route 53". Those names appeal to non technical product owners that then force adoption onto development teams... Pure fluff at it's best.

That's the think about the marketing first model we're dealing with now... No real innovation, just branding/name changes and highly tailored customization to lock a customer into a specific platform.

[throwaway894345]

There’s nothing new about marketing your product, and make no mistake that DynamoDB and Route53 are products.

> Those names appeal to non technical product owners that then force adoption onto development teams

Route 53 is a pun on the DNS port—not exactly common knowledge among nontechnical product owners. Anyway, DynamoDB and Route 53 succeed on merit. There are certainly better examples of shitty technologies that win on marketing or other nontechnical considerations. E.g., Oracle anything (of course Oracle aren’t know for being purveyors of microservices).

[throw_m239339]

> They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.

"Microservice" isn't really about that, it's a marketing paradigm that is here to serve the (paid) tools, not really the architecture, it is EXACTLY like "serverless", it's not an architecture, it's a really about promoting paid platforms.

The parent is 100% right about their point about marketing buzzwords, because that's really all what it is all about.

[ozim]

I don't think it was "splitting monolith" it was more like connecting separate applications.

Like you had a payroll in your enterprise of 1000 employees and you needed that same data in 5 applications in 3 different departments. So you would wrap payroll into a service and have that data accessible in multiple places.

I think that is still a valid approach to build monolith app and use multiple services if they are internal apps.

For customer facing and quickly changing stuff you might want to add microservices to be able to build new features quickly when ideally microservice should have its own database with what it needs to operate.

[drewcoo]

This. And now "microservices" is a rallying cry to avoid any kind of architecture organizing.

Because the broke you know isn't called "broke."

[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.

[dpark]

> that's why I don't buy into buzz words at all.

Clearly you do, because this is mostly nonsense driven by your knee jerk reaction to “microservices”. Very little you’ve written here is substantive. It’s all emotional appeal covering ignorance.

> If it's not broken, don't fix it...

But it is broken. Engineers often experience significant pain from monoliths so they look for a solution. They often also experience significant pain from microservices so the pendulum returns. Hopefully during all of this we learn enough that at least some pain is reduced, whether we land on microservices or monoliths or hybrid solutions.

> We need to stop disparaging … and focus on what works

Here I agree. Focus on what works and stop engaging in low value attacks on solutions that clearly work for some.

> The more we allow marketing minds to take control of our IT decisions…

What “marketing minds” are making decisions about service architecture? This seems like an imaginary issue.

[tomc1985]

> What “marketing minds” are making decisions about service architecture? This seems like an imaginary issue.

It is hard to hold this comment in a generous light (per HN rules) when some of my most poignant experiences in dealing with tech vendor salespeople at conferences is (and I paraphrase), "well, it's working great for $MEGACORP, you do want to be like $MEGACORP dont you?"

One time I asked one of those salespeople point blank if that line actually works on people. Apparently it does. And those people for whom that line works with make big expensive tech decisions.

[dpark]

Did you become a marketing mind because they were pitching you?

I did not say that marketing isn’t making pitches. I said they aren’t making the decisions.

Any company allowing marketing to choose the technical platform for the engineers is going to be very short lived. This is not a real issue.

[mrbungie]

You're assuming engineers can't be victims of cargo cult, and we all know that's not globally true as it's been discussed multiple times on HN. Marketing teams know that as well, and they exploit that as much as they can.

[tomc1985]

> Marketing teams know that as well, and they exploit that as much as they can.

They exploit this mercilessly, just as hard as they exploit our curiosity and desire for novelty as engineers.

To the GP, your company's marketing/sales team may not drive internal technical decisions, but I can promise you that other companies' sales teams do. Why do you think they so persistently step on the heads up their first POC so they can be put in touch with C-levels or department heads?

Enterprise sales is a trip, dude

[dpark]

This is very “everyone else is such an idiot”. I feel like you’re a half step away from saying that engineers shouldn’t be allowed to learn about new tech because they’re too stupid to know when not to apply it.

If your team of engineers is incapable of determining good engineering trade-offs, and you have too little influence on the team to steer them back to a reasonable choice, it’s not really marketing’s fault.

You’re probably going to tell me again that I’m too dumb to understand that marketing impacts engineers, so let me be clear, I am well aware that marketing impacts engineers, just as it influences everyone else. But engineers are not helpless fools incapable of making decent technical decisions just because someone tried to sell them on whatever latest serverless tech.

[dpark]

> You're assuming engineers can't be victims of cargo cult

At no point did I say anything to that effect.

I’m saying that marketers are not making technical decisions. That’s all I’m saying.

[ozim]

That is how you get to it.

If you are noname rapper you start dissing bigger guys so they diss you back and you get notoriety because someone noticed you.

As a politician you have to say others are the worst and broke everything but you have plan to fix everything that is broken now.

In the end all the swearing is posturing and all "great plans" turn out not possible in reality.

While yes you can do nice stuff with microservices, it is not a silver bullet.

[ryan_j_naughton]

> 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

Can you elaborate on this? Examples? Thanks!!

[fendy3002]

Looks like OP talked about serverless / google cloud run, where rather than traditional server deployment, it use specific provider's implementation. Additionally it may also means CI/CD pipeline where usually it's different between provider.

[winternett]

I'd need days to detail it all specifically enough, but I'll give you a simple example...

A "monolithic" solution usually relies on a basic (e.g. LAMP) stack that can all be run on one server if the need arises... Your web and database server can be migrated from AWS to Azure much easier if pretty much all of the functionality relies on a close-knit local server architecture that can have a less complicated security, code, and endpoint design as well.

If you create an app that works based on a highly distributed architecture, suddenly, migrating a solution is far more complex - Platforms like AWS and Azure do not run all of the same services, and those services often require lots of refactoring to work properly with your prior data, you'll also need to do many test cycles after migrating to ensure that solution integrity is maintained.... At that point, a simple migration might as well be a total refactor.

After implementing policies like zero trust and working out whitelisting, if your solution is complicated or large-scale, you also have to deal with service-specific nuances in your code and in your architecture design that don't translate well to the completely different tools available on an alternate cloud hosting platform, because usually they have completely different nuances and conventions on their service architectures.

To put it simply, it's like buying a ford pickup truck and installing an aftermarket 6.34 x 9.85ft camper top (and other ford-specific aftermarket parts) on it, and then trying to install that custom Ford camper top and the other Ford aftermarket parts onto a Toyota which only fits a 5.77 x 8.34ft camper later on... It usually doesn't work out well, and usually provides very unexpected results and more financial loss than using a universally sized 5.55 x 8.20ft camper (The monolithic option that fits in both trucks, albeit not perfectly).

Each platform is very specialized in their own way... Just as with Ford any Toyota pick up trucks, they have completely different build dimensions, and that's why the parts aren't interchangeable between the two trucks.

Monolithic solutions were originally designed to work agnostic of platforms, so they can work on either provided that they are implemented correctly...

Ultimately, the business need should be carefully evaluated by an experienced architect to determine which architecture fits the need best, and then other factors should be reviewed (like if you'll need to migrate any time in the future for example) to make the final call.

[throwaway894345]

You’re confusing “microservices” and “distributed architecture” with “depending on specific cloud provider services”. Microservices don’t have to depend on any cloud services at all and monoliths can (and often do!) use cloud services.

[winternett]

Many "Monoliths" can be run on something as simple as a desktop emulator. They don't generally rely on cloud either.

Microservices are "distributed" across a cloud host platform because they are each updated and maintained by different teams. My use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

[throwaway894345]

> Many "Monoliths" can be run on something as simple as a desktop emulator.

I'm not sure what a "desktop emulator" is, but a lot of micro services can run as native processes or in a VM. There's nothing about micro services that fundamentally restrict where they run--they're just application processes at the end of the day.

> my use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I mean, that's one scenario but the inverse could be true--your custom emoji service could go down but everything else--your payment service, etc could stay up. More than that, you can play it fast and loose with deploying to your emoji service while your important core services get more scrutiny. With monoliths, any change could take down core services so you have to use the same scrutiny when deploying changes to the emoji features. Moreover, you don't need to coordinate with a bunch of other teams to deploy--your team can deploy its own service whenever it needs to. You can use whichever language is best for your component. Etc, etc. But we are agreed that micro services aren't fit for every use case--if you only have a few teams then you probably won't benefit much from micro services.

> I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

You're back pedaling pretty quickly from the tone and claims of your original comment, but I accept all of this--neither is a silver bullet. :)

[winternett]

FTR... A desktop emulator was a reference to something like WAMP or XAMPP... On which a monolith can be run, developed upon, and even tested entirely independent of any host or VM infrastructure.

I'm not back pedaling, you're reading too closely and judging instead of looking at the discussion from an objective standpoint and simply seeking clarity and working towards truth. Here's what I posted in this same thread even before my post in this branch -

+++

by winternett 6 hours ago | parent | context | prev | next [–] | on: Why our team cancelled our move to microservices

A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot. Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone.

It's not a viable statement in any use case, except for people with size 20 feet.

The business need is what determines the solution necessary.

[fendy3002]

Well if the problem domain and scope is very-very well defined, developing a service as microservice is good / better than monolith. I can't imagine google map API to be developed inside the monolith app instead of running as their own service.

The problem that many developers fall on is sometimes some problem domains feel like they're well separated. However in practice those domains are tightly coupled into each other, that merging them together is better.

[Graffur]

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

I am interested in hearing more history on this

[drewcoo]

Well, back in the oughts, I think maybe 2001 . . .

https://2001.fandom.com/wiki/Monolith

[duxup]

I don’t even know what anyone means by monolith or micro services.

I’m somewhat sure everyone is somewhere in between depending on who you ask.

[staticassertion]

ISBN-13: 978-1491950357 ISBN-10: 1491950358

Here you go, you can read this book and it explains.

[duxup]

I know what the terms means, but I think in common language people mean different things when you find out what they are doing.

[staticassertion]

Oh, sure. People are wrong a lot.

[Melatonic]

Pretty sure "Monolith" was originally designed by a weird team of space aliens who left one on the Moon and Europa :-)