Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why our team cancelled our move to microservices

steven-lemon182.medium.com

Post reply on HN
Print view View original

161–170 of 243 posts

Re: Why our team cancelled our move to microservices

#161

Post by tomc1985 »

dpark wrote: post #149
winternett wrote: post #7

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…

> 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 sign…

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

Re: Why our team cancelled our move to microservices

#162

Post by throw_m239339 »

glintik wrote: post #20
winternett wrote: post #7

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…

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

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

Re: Why our team cancelled our move to microservices

#163

Post by scottious »

giaour wrote: post #31

> Microservices allow your team to have control over the full stack they require to deliver a feature. This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.

or even worse: the teams DO have full control over their stack and now you have dozens or more different technology stacks at the company and expertise isn't shared between them

Re: Why our team cancelled our move to microservices

#164

Post by christophilus »

twblalock wrote: post #155
andrewstuart wrote: post #38

Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.

The operations needed to keep a large monolith buildable when a lot of different teams work on it are also highly complex, and increase in complexity relative to the number of contributors to the codebase. It becomes a massive coordination problem at scale. Microservices decouple teams, so they can get their work done without stepping on each other's toes.

Eh. Properly segmented monoliths are just fine. And are probably much simpler to deploy.

Re: Why our team cancelled our move to microservices

#165

Post by scottious »

linuxdude314 wrote: post #5
nurettin wrote: post #2

> A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?

Do you not version APIs you design? When engineering an API meant for consumption by disparate services it’s imperative to provide back words compatibility. This is pretty basic stuff anyone designing a serious API should be taking into account.

sure, but all of that is a cost which you don't have to pay with a monolith. Versioning APIs and having to constantly think about backwards compatibility with independently moving services is not trivial.

Sometimes the cost is worth it. Most of the time it's not

Re: Why our team cancelled our move to microservices

#166

Post by dpark »

tomc1985 wrote: post #161
dpark wrote: post #149

Earlier quoted context omitted.

> 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 sign…

> 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 salespeo…

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.

Re: Why our team cancelled our move to microservices

#167

Post by tetsuhamu »

The #1 reason to split your serving architecture into microservices is that your application can't fit in 1 server's memory.

If your application fits in 1 server, you have a choice, otherwise you don't.

If your application can't fit in 1 server and you can't split it up, you have to refactor so it can.

If you can't refactor your application to have isolated domains, aka your domain is so complex it must take up an entire server, you have a serious problem.

Clustered applications are unavoidable.

Re: Why our team cancelled our move to microservices

#168

Post by patrick451 »

throwaway894345 wrote: post #127
winternett wrote: post #7

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…

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 disparagin…

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

Re: Why our team cancelled our move to microservices

#169

Post by throwaway894345 »

ironmagma wrote: post #152
throwaway894345 wrote: post #141

Earlier quoted context omitted.

Also, security. Each component has an identity and it’s own set of permissions so the custom emoji widget doesn’t have access to the payments system or the health data.

This would be true in a monolith as well unless configured otherwise. Functions don’t just start talking to each other; you have to explicitly connect them via a function invocation. I’m not sure how an architecture would change that.

It’s pretty straightforward. In a monolith everything is in the same memory space, so the payment system credentials and routines are available to the whole monolith. In a microservice architecture, one service can’t access the memory or routines of other services.

Re: Why our team cancelled our move to microservices

#170

Post by noogle »

ARandumGuy wrote: post #78
noogle wrote: post #58

Earlier quoted context omitted.

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version. Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

There isn't really a solution to version bloat aside from good processes and general diligence. There's no easy way to handle that sort of thing, unfortunately. However, I do think it can be easier to deal with for internal services then for something like Java. When the number of users is in the dozens rather then the millions, it's a lot easier to make sure everyone gets moved over to the new version.

That's what makes the whole idea of microservices seems weird to me. If a functionality has merit on its own (e.g. an authentication service), then it will naturally fall outside of the main application. If a service is tightly coupled to other parts of the app, then microservices seems like intentionally hindering yourself: the coupling remains (as evident by the need for backward compatibility), but now we it's harder to keep everything aligned due to the extra separation (e.g. different code bases, multiple databases, no static validation of remote interfaces etc.).

The point of organizations and products is to work as a tightly coordinated machine. The decoupling that microservices create seems opposite to that goal.

Happy to hear different perspectives.

Post reply on HN