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

351–360 of 410 posts

Re: The costs of microservices (2020)

#351

Post by jabradoodle »

devjab wrote: post #347
shados wrote: post #342

Earlier quoted context omitted.

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a couple of services on top. Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess…

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners”

I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith.

More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually finally invest in fixing things.

Perhaps your microservice rewrite goes well because you now know your domain after building the monolith, that is another option.

Re: The costs of microservices (2020)

#352

Post by devoutsalsa »

shados wrote: post #342
eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

>> That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

I called ours a macrolith.

Re: The costs of microservices (2020)

#353

Post by Cthulhu_ »

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.

Yes, but the choice to add a new programming language to your company's profile has to be taken with care and due diligence; you should make sure to have a number of developers that know the new language, offer training, incorporate it into your hiring, etc. It's an added node to your dependency graph, which can quickly become unmanageable.

You should always look into existing languages first. There's a lot of "I rewrote this thing into $language for a 100x performance boost" posts, in a lot of cases the comments are like "Yeah but if you rewrote it in the original language you could make it a lot faster too".

For a cool visualisation of this problem, check out https://boringtechnology.club/

Re: The costs of microservices (2020)

#354

Post by Cthulhu_ »

renegade-otter wrote: post #321
jupp0r wrote: post #151

Earlier quoted context omitted.

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.

I don't believe a team should have that much say in their technology, unless they themselves are also responsible for hiring, training, etcetera - so it kinda depends on how autonomous a team is.

That said, as the article also mentions, "micro" can be a bit of a misnomer; you could have a 50 person team working on a single "micro" service, in which case things like hiring and training are much more natural. (to add, I've never worked in a team of 50 on one product; 50 people is A Lot)

Re: The costs of microservices (2020)

#355

Post by benterix »

alrs wrote: post #344
shados wrote: post #342

Earlier quoted context omitted.

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.

It's not clear to me what you mean by dealing here. Do you mean developing? If so, I completely agree. If you mean deployments, a small number of engineers can manage hundreds of them easily.

Re: The costs of microservices (2020)

#356

Post by anonymousDan »

duncan-donuts wrote: post #277
bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

I was in a meeting to talk about our logging strategy at an old company that was starting micro services and experiencing this problem. In the meeting I half heartedly suggested we write the main lib in C and write a couple wrapper libs for the various languages we were using. At the time it felt kinda insane but in hindsight it probably would have been better than the logging mess we created for ourselves.

Maybe logging should be a microservice....

Re: The costs of microservices (2020)

#357

Post by samsquire »

js8 wrote: post #84

I think people get the modularity wrong. Modularity is important, but I came to conclusion there is another important architectural principle, which I call "single vortex principle". First, a vortex in a software system is any loop in a data flow. For example, if we send data somewhere, and then we get them back processed, or are in any way influenced by them, we have a vortex. A mutable variable is an example of a r…

I like this.

When I look at an architecture diagram, half the battle is trying to work out what is async/sync, push/pull and the direction of travel and ordering.

Enterprise service buses and message queues are kind of solutions to the creating vortexes where there is not a matching direction on each side.

Re: The costs of microservices (2020)

#358

Post by protomolecule »

lemmsjid wrote: post #285
protomolecule wrote: post #253

Earlier quoted context omitted.

"composition over inheritance, because that's how encapsulation can be most easily broken as messages flow across a single-application interfaces, but then I'd also throw in enforced immutability, and separating data from logic" Could you elaborate on this? I see how "separating data from logic" is a problem but what about the other two?

Well now that you mention it I think it does all come down to 'separating data from logic'. I was working backwards from the premise of: "what if we want a monolithic in-process application to have the same cognitive simplicity as an API-based client-server model?" If you want to enforce a clean interface between an in-process client and server (i.e. a piece of code calling a library interface), then the best model i…

I see, thanks. My original interpretation was that by "separating data from logic" you meant data-oriented programming where you intentionally give up on encapsulation.

"which is that if you're passing behavioral inheritance from a "server" to a "client", then it gets harder and harder to predict how that client is going to use it"

You mean a "server" returning the base class object whose methods are overridden by a successor class known only to the "server"?

Re: The costs of microservices (2020)

#359

Post by marcus_holmes »

renegade-otter wrote: post #321
jupp0r wrote: post #151

Earlier quoted context omitted.

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.

I've seen this play out for reals at a place a few years ago. Every team used a different tech, and all of them selected because of resume-driven development. People moving teams to get a particular tech on their resume. No common method for deployment, and endless issues getting things deployed. Everyone's a newbie because we were all learning a new, cool, stack. And everyone making stupid newbie mistakes.

Never again. When I build teams forevermore, I pick the tech stack and I recruit people who know that tech stack, or want to learn that tech stack. And we stick to that tech stack whenever possible.

Post reply on HN