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

341–350 of 410 posts

Re: The costs of microservices (2020)

#341

Post by porridgeraisin »

antonvs wrote: post #313
hinkley wrote: post #186

Earlier quoted context omitted.

I think we should start calling this Pendulum Blindness. We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right. The moderates are right, but their answers are wiggly and they're too bu…

> There's no clever soundbite to parrot. Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number! Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10! The "Ten…

You have for sure worked in sales before, amazing write-up

Re: The costs of microservices (2020)

#342

Post by shados »

eduction wrote: post #89
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…

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)

Re: The costs of microservices (2020)

#343

Post by porridgeraisin »

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 didn't quite understand your second-to-last paragraph(the rationale behind...), can you (or someone else) explain it further?

Re: The costs of microservices (2020)

#344

Post by alrs »

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)

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.

Re: The costs of microservices (2020)

#345

Post by andreygrehov »

Freebytes wrote: post #195
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…

This is a very good point, and you could probably write quite a few articles about this particular subject. You may even have a service A that calls service B that calls service C that calls service A. Then you have a problem. Or, you have C get blocked by something happening in A that was unexpected. Ideally, you only have parents calling children without relying on the parents whatsoever, and if you fail in this, y…

I think Robert C. Martin has already described that fairly well [1] [2].

[1] https://www.youtube.com/watch?v=N7agCpAYp1Q

[2] https://en.wikipedia.org/wiki/Acyclic_dependencies_principle

Re: The costs of microservices (2020)

#346

Post by never_inline »

esafak wrote: post #136
never_inline wrote: post #128

Earlier quoted context omitted.

> Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices? One database endpoint as in ? You can use different schemas and have no relations between tables used by different services, or on the other extreme have services which write to same table. I have read in a book that the most important criteria is independent deployability. I fo…

https://samnewman.io/books/building_microservices_2nd_editio... ?

Yep this book.

Re: The costs of microservices (2020)

#347

Post by devjab »

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)

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 of a database that nobody knows who pulls what from because everyone has connected some sort of thing to it and now your monolith isn’t really a monolith because of it. Which isn’t how a monolith is supposed to work, but is somehow always how it ends up working anyway.

I do agree though, that the “DevOps” space for “medium-non-software-development” IT departments in larger companies is just terrible. We ended up outsourcing it, sort of, so that our regular IT operations partner (the ones which also help with networking, storage, backups, security and so on) also handle the management part of our managed Kubernetes cluster. So that once something leaves the build pipeline, it’s theirs. Which was surprisingly cheap by the way.

I do get where you’re coming from of course. If we had wanted to do it ourselves, we’d likely need to write “infrastructure as code” that was twice the size of the actual services we deploy.

Re: The costs of microservices (2020)

#348

Post by marwis »

slowmovintarget wrote: post #221
voxic11 wrote: post #76

Earlier quoted context omitted.

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

Your dependencies might be tied to different JVM versions. Less likely but happened few times, especially during 8 to 9+ transition. You would've been stuck with your entire system on Java 8 for ages.

Also JNI won't be isolated which occasionally might be a factor (more likely for stability).

On the other hand one could make colocated multi-process services to work around this while avoiding all the other complexities of microservices.

Re: The costs of microservices (2020)

#349

Post by switch007 »

tsss wrote: post #185
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…

No one says you can't have all of your microservices use the same language...

You need a CTO with a backbone to say no to the senior people hell bent on padding their resumes and scratching an itch though

Too often devs weaponise micro services and say it’s one of the key reasons for microservices is to allow free language choice !

Re: The costs of microservices (2020)

#350

Post by jabradoodle »

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)

A distributed monolith isn't based on how many services you have, a better question is, how many services do you need to redeploy/update to make a change.

Yes, by the time you get to thousands of services you hopefully have moved past the distributed monololith, if you built one.

Post reply on HN