Live data from Hacker News

You Don't Need Microservices

medium.com

31–40 of 169 posts

Re: You Don't Need Microservices

#31
post #11

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

Strong agree. The need to transition to microservices will sneak up on an organization -- and that's okay. It's surprising how much life you can squeeze out of a monolith.

For the bulk of the smaller companies the monolith is an excellent choice. For a smaller number of them decomposition of that monolith into a few (And then there are projects that grow way beyond the point where even that will keep them manageable, in which case microservices may well make sense. But the number of companies faced with challenges at that level is quite small relative to the total and the chances that you find yourself in one of those if you don't have a few hundred co-workers as developer is very small.

Re: You Don't Need Microservices

#32

Earlier quoted context omitted.

Micro-services also good when an organization has a numbers of teams with different domains and release cycles, at some point it would be easier to spit code in some ways and have a boundaries. In this case splitting to services/micro-services creates those boundaries on a network level.

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.

I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now.

I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

Re: You Don't Need Microservices

#33
post #16

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

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?

Re: You Don't Need Microservices

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

Re: You Don't Need Microservices

#35

Earlier quoted context omitted.

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.

I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

> I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

I know you are referring to something else, but it actually means that the battle is won.

Re: You Don't Need Microservices

#36
post #21

>Modularize Your Monolith It is true that probably any monolith can be break down into components, that won't prevent the full redeployment (and all the risks that it brings) though. I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.

Or do the whole redeployment all the time and you'll see the "risk" of doing so was psychological or a few better tests away. I work in a 150+ yo company where change is ... well not welcome. When we said we could try to release without schedule, several times a week, whenever we want just because we finished one thing at a time, you should have seen their looks. We have 100 microservices doing low latency trading in…

>Or do the whole redeployment all the time and you'll see the "risk" of doing so was psychological or a few better tests away.

YMMV but I do have personal experience where the risks weren't psychological. Teams stepping into each other shoes and broken each other features are a real problem, solved by communication but that overhead has real costs.

Re: You Don't Need Microservices

#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?!”

Re: You Don't Need Microservices

#38
post #9

I wrote a library [1] for Laravel that lets you put a kind of "microservice" inside of your monolith. It lets you develop, deploy, and execute AWS Lambda functions from your Laravel application. The theory here is that sometimes you need some other language/infrastructure beyond what you're comfortable devops-ing yourself, and Lambda is actually quite good at providing you with an entire stack of stuff you don't have…

The problem I find with these plugin serverless is that they rarely work well. Even with a framework produced by Chalice, there are issues that are largely so minor in detail but required to work well with AWS. Often they are not even code related but infrastructure.

IMHO, AWS Chalice remains the goto method to generate REST API serverless manner but also curious how yours also differ from the paid Laravel solution that lets you deploy your stack serverless.

Re: You Don't Need Microservices

#39

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

This reminds me a lot of Conway's law:

> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.

Re: You Don't Need Microservices

#40
You are probably correct for small to medium sized tech teams building software. With that said, in 2022 I'd expect any company selling a SaaS product to be built with micro-services. Buying a SaaS I want all of the benefits, but no longer need to deal with the hard parts.
Post reply on HN