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

The Death of Microservice Madness in 2018

dwmkerr.com

Post reply on HN
Print view View original

111–120 of 469 posts

Re: The Death of Microservice Madness in 2018

#111

Post by anfedorov »

ohyes wrote: post #97
JamesBarney wrote: post #90

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

That's nothing. I once ran 20 services before breakfast.

Re: The Death of Microservice Madness in 2018

#112

Post by zero_shift »

CryoLogic wrote: post #8

Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression. Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.

Sounds like a candidate for serverless.

Re: The Death of Microservice Madness in 2018

#114

Post by zenlikethat »

daxfohl wrote: post #109

Why is scaling independently a pro? I've heard that argument before and never understood it. If I have one api that is low throughput and one that is high, say requires 2 and 20 nodes respectively, then you need 22 nodes whether they are two independent microservices or a monolith. I'd think the monolith would actually be easier to manage as you don't have to worry about how to divvy up the resources. All 22 nodes ru…

It sounds like you're conflating a binary barrier with a service barrier here. In your example you have two cleanly defined services which happen to be in the same binary. The issue with monoliths is when they all do the same thing because the code is a big ball of mud that "cheats" by calling shared subroutines and doesn't have a clearly delineated API. Therefore you have only one knob to turn to scale.

The 20+2 distinction isn't clear because each part of the code is causing action-at-distance on the others. Failures become a lot harder to isolate. That's what people mean by scaling is hard with a monolith.

Re: The Death of Microservice Madness in 2018

#116

Post by acdha »

linkmotif wrote: post #50

Will someone enlighten me as to why a microservice should have no dependent services? Seems reasonable to me.

I prefer that the advice not to be dogmatic about saying “no” but rather to be wary of the costs. The big benefit of microservices is being able to easily reason about or scale services, but adding dependencies usually sacrifices those benefits. I’ve seen that done poorly in the various iterations of this cycle and the worst failure modes mean that debugging requires you to understand how to get & interpret state from many locations, making even simple problems challenging.

That might mean that you still take that cost willingly but engineer in the extra tooling to make things easier to manage – i.e. simplifying tracing load or errors across service boundaries back to the source – but it might also be a cue for you raise to reconsider whether the service divisions are in the right place or whether all of the services are appropriately sized. If you find yourself needed distributed transactions, retries, etc. that’s often a good time to pause and reconsider.

Re: The Death of Microservice Madness in 2018

#117

Post by HelloMcFly »

st3fan wrote: post #108
ohyes wrote: post #97

Earlier quoted context omitted.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.

I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.

Re: The Death of Microservice Madness in 2018

#118

Post by zenonu »

JamesBarney wrote: post #90
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.

Re: The Death of Microservice Madness in 2018

#119

Post by nstj »

ohyes wrote: post #97
JamesBarney wrote: post #90

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

Putting the I back in Microservices :)
Post reply on HN