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

141–150 of 469 posts

Re: The Death of Microservice Madness in 2018

#141

Post by beamatronic »

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.

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

Re: The Death of Microservice Madness in 2018

#142

Post by kovacs »

narayanbs wrote: post #115

Being a veteran programmer,i find it funny how the article sounds like the stuff we used to read back in 2004-2005, during the heydays of spring and EJB.

You took the words right out of my brain as I was scrolling through the comments. My internal dialogue literally was "This is EJB all over again", which admittedly may be a bit too much but as they say history never repeats but often rhymes :-)

In this go around I think the value of discreet, well factored services clearly have merit but it's really a question of just how often you truly have something that's a good candidate for this pattern. From what I've seen in some places it's used as a reason to rewrite systems and not worry about doing a good job creating well abstracted software because the integrity of the overall system is some other team's problem.

This article is really well written and does a great job shedding light on the truth. Thank you for sharing.

Re: The Death of Microservice Madness in 2018

#143

Post by sooheon »

wst_ wrote: post #125

I found out recently that people too often think about microservices in context of broader solution like it would be one app, just scattered around. I did that mistake in the past, either. The longer I work with microservices the clearer it is to me that teams implementing them should forget about the big product, just focus on the service, as it would be product itself. Assume that anyone can use it, for any purpose…

IOW, good, clean function composition.

Re: The Death of Microservice Madness in 2018

#144

Post by bri3d »

cookiecaper wrote: post #128
bri3d wrote: post #96

Earlier quoted context omitted.

Is this truly a management failure? If a few things are true, I could see this as a win: * I can isolate my developers from outside interests using microservices. * My developers are more effective in each dimension (quality, retention/happiness, velocity) because they are isolated from outside interests. * My software is easier to operate and more reliable because it is a microservice. If any of these three things a…

Microservice architectures [usually] represent a management failure because they usually don't work well in the real world. It's easy to concoct a paper-only, theoretical version of an idealized microservice architecture, since you can gloss over all the real-world details and practicalities. Mapping that theory into the real physical world is a whole different ball game. Conway's Law might as well be renamed "The La…

This I can entirely agree with - framing my point around Conway's law works well and I think I can reframe my question as "is the expression of Conway's law a management failure, or is it the mis-structuring of the organization causing the expression to be harmful?"

The parent post I was replying to seemed to simplify things down to "let your developers communicate and they'll build a more coupled system that works, instead of a morass of microservices that don't." That's another thing that looks good on paper but doesn't scale, at least in my experience.

Re: The Death of Microservice Madness in 2018

#145

Post by t3rmi »

daxfohl wrote: post #126
zenlikethat wrote: post #114

Earlier quoted context omitted.

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 dis…

That doesn't answer the question though. Suppose the apis are completely independent. Say one is a chess server and the other generates haikus. Granted that's silly architecturally to put into a single binary, but that's not the question. My question is why specifically managing scalability becomes easier when deploying them independently. My thought is that it actually becomes more difficult as you have to manage ea…

Other than freeing up memory where the binary would be loaded and maybe some network ports I don't see any advantage to scaling two "light weight" services separately.

Re: The Death of Microservice Madness in 2018

#146

Post by rtpg »

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…

Do you legit think that people are all just doing this as a fad?

There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course.

The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And its not even not doing it right, but simply that scales change. Or patterns change.

And in new companies, it _could_ be that people don't get it.

"Microservices as mass delusion" discounts a lot of people who are really thinking hard about how to handle the pros and the cons of things.

Re: The Death of Microservice Madness in 2018

#148

Post by richardknop »

dvt wrote: post #29
sk5t wrote: post #21

Earlier quoted context omitted.

> A microservice should generally not have side effects I gotta ask, how is this realistic? A salient feature of most of the software I've worked on is that it has useful side effects.

A microservice, imo, should just be a simple black box that takes in some input and returns some output (sometimes asynchronously). No side-effects necessary. No fiddling with database flags or global state, and definitely no hitting other microservices. See @CryoLogic's post for a good example. This means that you simply can't build some things using microservices -- like logging in a user -- and you'd be right.

But that is ridiculous. Fiddling with database flags is silly, I agree, but inserting and updating database is a completely normal side effect of most business logic. So if your microservice handles any kind of ordinary feature of your business solution, it will almost definitely have side effects because it will write to database. There might be services which just do some computation in memory and return result to you but I think those will be a small minority, most of your services dealing with features such as payment, subscriptions, identity etc (just some examples) will have useful side effects.

Re: The Death of Microservice Madness in 2018

#149

Post by rtpg »

napsterbr wrote: post #63
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.

So basically a library? :)

well a library + deploying it into its own space so that it doesn't bring down your main app due to compute time.

The operational part of microservices can end up being pretty important in these cases

Re: The Death of Microservice Madness in 2018

#150

Post by richardknop »

tunesmith wrote: post #106
brown9-2 wrote: post #73

Earlier quoted context omitted.

I’m confused. If a microservice doesn’t call the api of any other microservices, then when is sending the requests to any of them? A large purpose of service oriented architecture is encapsulation. If no other microservices can make requests to your microservice, then you really haven’t encapsulated much.

I'm thinking this concept improperly conflates synchronous requests with eventually-consistent asynchrony. No, you definitely don't want microservices making synchronous requests to other microservices and depending on them that way. But it still may be necessary for your services to depend on each other, and that's where you can allow that communication through asynchronous eventually consistent communication. Actor…

That is nice in theory and I agree it should be done wherever possible but lot of the time business logic will require immediate synchronous response to be returned as a next step in workflow will execute different branch of logic based on condition/result returned from previous microservice and the frontend / consumer / app will need immediate confirmation about whether action succeeded.

Even in such cases you might want to move bulk of processing to asynchronous queue based system but part of the logic might need to be executed synchronously (authorise credit card payment, you can process the payment asynchronously later, perhaps in bulk cron jobs like Apple Itunes does it but initial authorisation which decides whether purchase is successful must be synchronous).

Post reply on HN