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

71–80 of 410 posts

Re: The costs of microservices (2020)

#71

Post by jacquesm »

insanitybit wrote: post #60
vrosas wrote: post #40

Earlier quoted context omitted.

The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...

Indeed, dogmatic adherence to arbitrary patterns is a huge problem in our field. People have strong beliefs, "X good" or "X bad", with almost no idea of what X even is, what the alternatives are, why X was something people did or did not like, etc.

Another problem is people making decisions with potentially far reaching consequences well above their paygrade without authorization.

Re: The costs of microservices (2020)

#73

Post by exabrial »

> Getting the boundaries right between the services is challenging - it’s much easier to move them around within a monolith until you find a sweet spot. Once the monolith is well matured and growing pains start to rise, then you can start to peel off one microservice at a time from it.

I couldn't agree more. "Do not optimize your code" applies here.

Re: The costs of microservices (2020)

#74

Post by resters »

There should be a distinction between doing a migration of a "monolithic" system to "microservices" vs adding functionality to a monolithic system by implementing a "microservice" that will be consumed by the monolithic system.

In some cases, microservices are helpful for separation of concerns and encapsulation.

But teams often get the idea that their monolithic system should be rewritten using "microservice" patterns. It's important to question whether the monolithic system is using the correct abstractions and whether spllitting it into different services is the only way to approach the deficiencies of the system.

In most systems there are bits that can (and probably should) be quite decoupled from the rest of the system. Understanding this is a more fundamental aspect of system design and does not apply only to monolithic or microservice approaches.

Re: The costs of microservices (2020)

#75

Post by jacquesm »

sethammons wrote: post #19
jjtheblunt wrote: post #11

Earlier quoted context omitted.

> Team velocity is empowered via microservices and controlling their own data stores. Bologna. Choosing clear abstractions is an enabler of focus, but that doesn’t necessarily imply those abstractions are a network call away.

our team of 300 - we _can't_ enforce the clear abstractions. New dev gets hired, team feels pressured to deliver despite leadership saying to prioritize quality, they are not aware of all the access controls, they push a PR, it gets merged. We have an org wide push to get more linting and more checks in place. The damage is done and now we have a multi-quarter effort to re-organize all our code. This _can_ be enforce…

You can't really retrofit culture and behavior, you can only very gradually move towards a particular goal and usually that's a multi-year effort, if it can be done at all.

Re: The costs of microservices (2020)

#76

Post by voxic11 »

eterevsky wrote: post #58
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…

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

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.

Re: The costs of microservices (2020)

#77

Post by manicennui »

jeffbee wrote: post #9
nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example…

I rarely see anyone claiming that microservices are never justified. I think the general attitude toward them is due to the amount of Resume Driven Development that happens in the real world.

Re: The costs of microservices (2020)

#78

Post by shadowgovt »

sethammons wrote: post #7
jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

As with so many software solutions, the success of microservices is predicated upon having sufficient prognostication about how the system will be used to recognize where the cut-points are.

When I hear success stories like that, I have to ask "Is there some inherent benefit to the abstraction or did you get lucky in picking your cleave-points?"

Re: The costs of microservices (2020)

#79

Post by bingemaker »

paulddraper wrote: post #64
eterevsky wrote: post #58

Earlier quoted context omitted.

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

Those dependencies might cross language boundaries, or interfere with your other dependencies running in the same process.

On the contrary, when they fail silently, it is hard debug "dependent" services

Re: The costs of microservices (2020)

#80

Post by aleksiy123 »

I recently had some discussions and did some research on this topic and I feel like there is a lot people don't talk about in these articles.

Here are some more considerations between micro services and monolothic tradeoffs. Its also important to consider these two things as a scale and not a binary decision.

1. Isolation. Failure in on service doesn't fail the whole system. Smaller services have better isolation.

2. Capacity management. Its easier to estimate the resource usage of a smaller service because it has less responsibilities. This can result in efficiency gains. Extended to this is you can also give optimized resources to specific services. A prediction service can use GPU while web server can use CPU only. A monolothic may need to use compute with both which could result in less optimized resources.

3. Dev Ops Overhead. In general monolothic services have less management overhead because you only need to manage/deploy one or few services over many.

4. Authorization/Permissions. Smaller services can be given a smaller scope permissions.

5. Locality. Monolothic can share memory and therefore have better data locality. Small services use networks and have higher overhead.

6. Ownership. Smaller services can have more granular ownership. Its easier to transfer ownership.

7. Iteration. Smaller services can move independently of one another and can release at seperate cadences.

Post reply on HN