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

61–70 of 410 posts

Re: The costs of microservices (2020)

#61

Post by simonw »

mjr00 wrote: post #47
simonw wrote: post #15

Earlier quoted context omitted.

> Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a l…

> they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk. This definitely happens but at some point someone with authority needs to show technical leadership and say "you cannot do this no matter how desperately you need those re…

A lot of organizations are screwed.

Re: The costs of microservices (2020)

#62

Post by nicoburns »

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…

> They also allow teams to be uncoupled assuming they don't break their API.

Presumably you would still need tooling to enforce teams not breaking their API, and also to prevent people just modifying services to expose private internals that should not be part of the public API?

Re: The costs of microservices (2020)

#63

Post by paulddraper »

> The term micro can be misleading, though - there doesn’t have to be anything micro about the services. In fact, I would argue that if a service doesn’t do much, it just creates more operational toll than benefits. A more appropriate name for this architecture is service-oriented architecture, but unfortunately, that name comes with some old baggage as well.

What baggage is that?

Because in my experience 90% of the argument revolves around the word "micro."

If "micro" is indeed irrelevant to "microservices," let's name things better, yes?

Re: The costs of microservices (2020)

#64

Post by paulddraper »

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?

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

Re: The costs of microservices (2020)

#65

Post by jacquesm »

vrosas wrote: post #40
insanitybit wrote: post #26

Earlier quoted context omitted.

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

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

Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that. This could come back to haunt you later on when you by your lonesome decide to merge a 'small PR' with massive downtime as a result of not having your code reviewed. Ok, you say, I'm perfect. And I believe you. But now you have another problem: the other junior devs on your team who see vrosas commit and merge stuff by themselves will see you as their shining example. And as a result they by their lonesomes decide to merge 'small PR's with massive downtime as a result.

If you got _reamed_ you got off lucky: in plenty of places you'd be out on the street.

It may well be that you had it right but from context as given I hope this shows you some alternative perspective that might give you pause the next time you decide to throw out the rulebook, even in emergencies - especially in emergencies - these rules are there to keep you, your team and the company safe. In regulated industries you can multiply all of that by a factor of five or so.

Re: The costs of microservices (2020)

#68

Post by insanitybit »

nicoburns wrote: post #56
insanitybit wrote: post #38

Earlier quoted context omitted.

Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundarie…

> Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. That is not too true at all. I've seen "microservice" setups where one microservice depends on the state within another microservice. And even cases where service A calls into service B which calls back into ser…

Well, I'd say you've seen SoA setups that do that, maybe. But those don't sound like microservices :) Perhaps that's not a strong point though.

Let me be a bit clearer on my point because I was wrong to say that you have to treat a service as being totally isolated, what I should have said that they are isolated, whether you treat them that way or not. There is a physical boundary between two computers. You can try to ignore that boundary, you can implement distributed transactions, etc, but the boundary is there - if you do the extra work to try to pretend it isn't, that's a lot of extra work to do the wrong thing.

Concretely, you can write:

    rpc_call(&mut my_state)
But under the hood what has to happen, physically, is that your state has to be copied to the other service, the service can return a new state (or an update), and the caller can then mutate the state locally. There is no way for you to actually transfer a mutable reference to your own memory to another computer (and a service should be treated as if it may be on another computer, even if it is colocated) without obscene shenanigans. You can try to abstract around that isolation to give the appearance of shared mutable state but it is just an abstraction, it is effectively impossible to implement that directly.

But shared mutable state is trivial without the process boundary. It's just... every function call. Any module can take a mutable pointer and modify it. And that's great for lots of things, of course, you give up isolation sometimes when you need to.

Re: The costs of microservices (2020)

#69

Post by soco »

spott wrote: post #55

"Microservices" has always been weird to me. People argue for them from two different, drastically different, points of view: * Microservices become necessary at some point because they allow you to independently scale different parts of the application depending on load. * Microservices become necessary at some point because they allow you to create hard team boundaries to enforce code boundaries. Personal opinion:…

Granular performance and team boundaries are both valid points. But, I haven't seen yet (around me) monolith applications so complex to have more teams working on them. I've seen instead applications developed by two persons where some higher-ups requested splitting them into microservices just because (no, scaling wasn't needed).
Post reply on HN