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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

321–330 of 410 posts

Re: The costs of microservices (2020)

#321

Post by renegade-otter »

jupp0r wrote: post #151
lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

To add another to your list: Being able to easily use different programming languages. Not every language is a good fit for every problem. Being able to write your machine learning deduction services in Python, your server side rendered UI in Rails and your IO and concurrency heavy services in Go might justify the additional overhead of having separate services for these three.

These are almost never pragmatic decisions. Giving teams independence over the stack usually results in resume-driven development, and now your JS developers are forced to maintain a Go server because some jock thought it was a cool thing to do .

Due diligence in these cases is rare.

Re: The costs of microservices (2020)

#322

Post by smaudet »

TeMPOraL wrote: post #242
arzke wrote: post #14

Earlier quoted context omitted.

"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-han...

Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.

Depends who you are, mostly the ones making the decisions aren't usually listening to their developers (maybe by choice maybe because they are at the whim of a customer), so their cost functions are calibrated towards course changing being more expensive than less.

By the time your devs are saying "this sucks" you've long overshot.

Re: The costs of microservices (2020)

#323

Post by dogcomplex »

Can we just build our localized monolith systems in a modular way so they can easily be decomposed into decentralized microservices at any sensible division when the need arises..? Must we always have this debate against an idea that is stupid on its face - sending remote requests for every single service..?

Re: The costs of microservices (2020)

#324

Post by nijave »

elevation wrote: post #193
wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve…

That is all true but most languages have semi-sane libraries with semi-sane defaults that handle most of that. Sure you need some config and tuning but it's not completely uncharted waters

Re: The costs of microservices (2020)

#325

Post by smaudet »

withinboredom wrote: post #260
vrosas wrote: post #229

Earlier quoted context omitted.

I suggested it's possible to write, commit and own code without others' approval to increase productivity and people get _extremely_ defensive about it. It's so odd. It happened in real life and it's happening in this thread now, too. They even attack your character over it.

Yes. Some people get personally attached to code. It’s incredibly frustrating. Some people use reviews to push dogmatic approaches to architecture and/or exert some kind of control over things. Whenever I meet these people in a code review, and they make unnecessary suggestions or whatever, my favorite phrase to say is, “I can get behind that, but I don’t think it’s worth the time to do that right now,” or, “I disagr…

If the code work/it's tested, review is for sanity checking/looking for obvious bugs.

Anything else is un-needed grooming that's more about the other developer's ego, not about good code (sometimes its to follow some other constraint, but its a good sign the person has a personality issue).

Re: The costs of microservices (2020)

#326

Post by yCombLinks »

wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

You lose atomic transactions. Every business action is orders of magnitudes more more complex because of that.

Re: The costs of microservices (2020)

#327

Post by nijave »

jedberg wrote: post #145

Last time I did a survey of my peers, companies that were all in on microservices in the cloud spent about 25% of their engineering time on the support systems for microservices. That number is probably a bit lower now since there are some pretty good tools to handle a lot of the basics. And the author sums up the advice I've been giving for a long time perfectly: > Splitting an application into services adds a lot o…

>A well run platform removes most of the ops responsibility from the team

It might remove most of the responsibility from the original team but it transfers it somewhere else. Making sure the new "platform team" is well staffed is something I don't see mentioned/discussed very often in the context of microservices

Re: The costs of microservices (2020)

#328

Post by yCombLinks »

0xbadcafebee wrote: post #158

So where's "the costs of monoliths" post? They don't show up here, because everyone is out there cluelessly implementing microservices and only sees those problems. If everyone were out there cluelessly implementing monoliths, we'd see a lot of "monoliths bad" posts. People don't understand that these systems lead to the same amount of problems. It's like asking an elephant to do a task, or asking 1000 mice. Guess wh…

The 8 trillion monolith bad posts are why we are now over inundated with microservices. This is the blowback when people are realizing the cost benefit didn't work for them

Re: The costs of microservices (2020)

#329

Post by smaudet »

elevation wrote: post #193
wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve…

This is why I saw microservices are "closer to the metal", i.e. they depend more on the physical characteristics of their environment than non-microservices.

A function call in a monolith can:

  * segfault
  * be called with the wrong number of parameters
  * call the wrong function
  * go through but never return
  * substitute itself with another function
All of which are very similar to the RPC situation. However we practically never see this because of the OS guarantees like memory safety, security, etc, plus there are standardized ways of handling when these problems do occur, notably try / catch patterns.

These issues can* be abstracted as well, but the advantage of scaling (being close to the metal) is the disadvantage as well (being very close to the hardware abstractions that let you scale).

E.g., there is no difference between running a microservice on a scaling computer than guarantees memory access across a cluster with interrupts, etc (some millions of cpus and terabytes of memory), and running it on a bunch of instances, except the hardware. The former is exotic and abstracts the hardware, the later does not and so all these "low level" errors surface with great frequency.

Re: The costs of microservices (2020)

#330

Post by nijave »

The article touches on it a bit, but in my experience microservices multiply operational problems (especially at startups where you don't have big, dedicated infrastructure teams). All of a sudden you have 5-10x things getting built in CI and deployed. You need some way to debug issues so usually distributed tracing comes up. Now that you have 10x as many of everything, you obviously want to try to centralize things like networking, authn/z, service discovery so you introduce some platforms to help with that... but someone has to run and maintain all that. That's fine if you want platform/infrastructure teams to maintain these but many startups only have a very small handful of people (10% or less of eng) handling CI/infra/release/performance/observability/networking/traffic mgmt with some title like "SRE" or "devops"
Post reply on HN