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

You Don't Need Microservices

medium.com

Post reply on HN
Print view View original

61–70 of 169 posts

Re: You Don't Need Microservices

#61

Post by tomtheelder »

api wrote: 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…

Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit.

In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and allow more consistent and less risky deployments. There are certainly costs: infrastructural complexity, a new network boundary between services, increased risk of techincal/product drift.

For orgs where the benefits outweigh the costs, due to scale/org structure/perf concerns/etc it can be an enormous win for velocity. For other orgs it can be a huge velocity killer. It just depends.

Re: You Don't Need Microservices

#62

Post by foobarian »

XorNot wrote: post #51
foobarian wrote: post #33

Earlier quoted context omitted.

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.

Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.

Re: You Don't Need Microservices

#63

Post by foobiekr »

blowski wrote: 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?!”

Most of the real world "microservices" usage outside of FAANG has been to legitimize polyglot development (a net negative for most organizations) and the to create heretofore unseen levels of Conway's law. A microservice per person? Sure, why not?

It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service. Most groups I've talked to don't even have a good answer to "why is this in a separate service from that?" when asked, and I've talked to a lot of them.

Re: You Don't Need Microservices

#64

Post by api »

tomtheelder wrote: post #61
api wrote: 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…

Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit. In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and…

The same advantages can be achieved by separating things into libraries or discrete packages.

Microservices just takes that and spreads it around a K8S cluster using gRPC or RESTful JSON or some other RPC bus for all the various modules to talk to each other, consuming far more compute resources and helping increase atmospheric CO2 and make cloud vendors rich. Why is calling a library running in a separate task (possibly on a separate CPU) via gRPC a better approach to code modularity?

The only time this makes sense is when you are (1) totally huge and (2) have specific hot regions of your service that you want to autoscale relative to the rest of the service.

Incremental upgrades can be achieved by just incrementally cycling your service, no microservices needed. Doing so when only some modules change can be achieved with CI without the crazy runtime overhead.

Re: You Don't Need Microservices

#65

Post by foobarian »

jacquesm wrote: post #41
foobarian wrote: post #32

Earlier quoted context omitted.

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

When I see a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together it usually is because someone took the 'services' pattern a bit too far and in that case 'microservices' is a proper moniker. And for Erlang based systems it usually is also appropriate. If there are fewer than 10 or so services usually they are not 'microservices'…

> a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together

For what it's worth, I suddenly feel a lot better about my employer's architecture. :-) But we still call them microservices because language.

Re: You Don't Need Microservices

#66

Post by throwaway894345 »

DoneWithAllThat wrote: post #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.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making dumb things hard. We were also able to deploy individual services much more frequently without needing to coordinate with a bunch of other teams, and builds, tests, etc were much faster helping shorten our iteration loops.

Local development environments were a bit more tedious in certain cases, but that was the only issue I recall.

Re: You Don't Need Microservices

#67

Post by revskill »

msaspence wrote: post #54
revskill wrote: post #17

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

Yes, we have a term for that: Technical debts!

The reality is like this: You have a critical system that ran for ages, and now what will you do to scale the features ? By allowing/teaching junior devs to understand how to contribute to the codebase ?

There's a simpler way to do that efficiently: Extract a subdomain into its own microservice and you control the interface. Then even that microservice has bad code quality (tech debt), your business is still running fine!

Problem solved.

Re: You Don't Need Microservices

#68

Post by throwaway894345 »

seibelj wrote: post #56
monksy wrote: 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.

It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)

Re: You Don't Need Microservices

#69

Post by seibelj »

throwaway894345 wrote: post #68
seibelj wrote: post #56

Earlier quoted context omitted.

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

It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)

Yes let's make every function call its own service with monitoring, a database, the network stack, management, and so on and then enjoy wonderful performance and easy management

Re: You Don't Need Microservices

#70

Post by tlonny »

kkapelon wrote: post #43
tlonny wrote: 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...

This doesn't cover independent deployments. Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.

I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app.

One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices.

Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...

Post reply on HN