Live data from Hacker News

You Don't Need Microservices

medium.com

51–60 of 169 posts

Re: You Don't Need Microservices

#51
post #16

Earlier quoted context omitted.

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...

When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?

In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much.

You're not Google, you don't have this problem.

Re: You Don't Need Microservices

#52
You got to love the balant disregard for alternative architectures where this article has to advocate for monoliths again.

You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to it.

Think about streaming data systems. These allow for multiple components connecting to durable queues (with maintence polices) that will process data and pass it along. This is more for data that may take longer, and shouldn't be done in the same request.

Slight personal rant: The crap that I've seen people expect of microservices to do in a request is excessive. (If you're doing more than taking a request, reading+writting into a database.. you're doing too much and your performance is terrible) Additionally there is very little consideration about what happens when a microservice performs badly.

Re: You Don't Need Microservices

#53
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

They're irrationally thrown up there as a silver bullet and people are heavily criticised when people suggest non-monolith+microservice alternatives.

Re: You Don't Need Microservices

#54

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

I love the idea of "managing junior level programmers who don't know how to make loosely coupling architecture" as describing engineering leadership, regardless of how cynical it is.

I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"

Re: You Don't Need Microservices

#55

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

I've seen the degenerate states of both extremes:

- a monolith with too many engineers contributing: no continuous deployment but rather "release day," which was a shitshow; said day was an extensive process where hundreds of engineers (anybody who was on git blame) had to be online and sitting by for four hours while it rolled; the release team often had to hand-revert bad patches; bullying of engineers who "broke the build" reached levels that would raise HR eyebrows; there were still often rollbacks and site breakages.

- microservice hell: there were often 2-3 APIs for the same service; platform engineering (for the protobuf RPC generation) had to support five different languages; security auditing was NP-hard; every team had its own release process; services that were still highly used were "deprecated" and left languishing for years until somebody took up the mantle and released their own parallel service that did nearly the same thing but with a different API, so now other services had to use both; etc.

"But that wouldn't happen at $my_company, we know the pitfalls and we'd never be that bad at engineering!" Sure...sure. That's what these companies said to themselves too :)

Re: You Don't Need Microservices

#56
post #52

You got to love the balant disregard for alternative architectures where this article has to advocate for monoliths again. You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to…

> If you're doing more than taking a request, reading+writting into a database.. you're doing too much

And this is why micro-services are poor architecture. If you need an entire service for every DB activity you are in for a terrible time.

Re: You Don't Need Microservices

#57
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

That's true for all ideas.

A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X".

And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"

Re: You Don't Need Microservices

#58
post #18

One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads. Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad. Other major classes of fads are: consultant self promotion fads, re-inve…

> "move stuff around and complexity will magically go away" fallacy

This is a great description of microservices

Re: You Don't Need Microservices

#59
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

That wasn't the argument that was being made. Do you have commentary on the content of the article, or just that you don't like that he had a non-party line opinion?
Post reply on HN