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

251–260 of 469 posts

Re: The Death of Microservice Madness in 2018

#251

Post by somberi »

meddlepal wrote: post #58
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 think it has to do with control. I've written microservices and microservices tooling now for a long time... so long when I started we were just calling it something like (isolated-responsibility) SOA and we didn't have a fancy buzzword. Developers want to own their thing. Microserivces desire springs up because of a lack of communication culture and desire for siloification in a companies organization to keep vari…

" Microserivces desire springs up because of a lack of communication culture and desire for siloification" - Would have upvoted this more than once if possible.

Re: The Death of Microservice Madness in 2018

#252

Post by woolvalley »

bmer wrote: post #157
brandonbloom wrote: post #136

Earlier quoted context omitted.

I agree that it's _easier_ for teams to have their own little fiefdoms, but not necessarily _better_. Shipping the org-chart is often a symptom of a leadership problem. When natural service boundaries exist, good leadership may choose to ship the org-chart, but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture.

> ...but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture. hahaha Do you know if there are some well chronicled cases of this happening? I find it very believable, but you know, would love to read something "actual".

Just go work somewhere that is big enough for that to happen. Usually large tech cos with the amount of devs larger than dunbars number by about 2x or greater.

Re: The Death of Microservice Madness in 2018

#253

Post by sameline »

jblow wrote: post #139
Clubber wrote: post #130

Earlier quoted context omitted.

10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?

How micro can it possibly be if it takes 10 people to deal with it? Seriously.

It’s not unreasonable to imagine that any of the examples provided in the source post could require a team larger than 10 people.

Re: The Death of Microservice Madness in 2018

#254

Post by asfdsfggtfd »

mgkimsal wrote: post #161
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.

> 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. Faced this a couple of years ago, and I was the lone dissenting voice suggesting this was not going to go well. Then I learned that "microservice" in reality just meant everything was going to be one nodejs process running endpoints, with ios and android clients hitting it, which...…

If you are slightly careful and put this service behind a load-balancer/reverse-proxy you can take any given set of end points and turn them into a micro-service when you need to. Sounds perfect for a small team.

Re: The Death of Microservice Madness in 2018

#255

Post by asfdsfggtfd »

brandonbloom wrote: post #136
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.

I agree that it's _easier_ for teams to have their own little fiefdoms, but not necessarily _better_. Shipping the org-chart is often a symptom of a leadership problem. When natural service boundaries exist, good leadership may choose to ship the org-chart, but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture.

Isn't the idea to decide the architecture then update the org-chart to reflect this?

Not that this actually happens-or would be a particularly good idea if it did for other reasons (like breaking up teams etc).

Re: The Death of Microservice Madness in 2018

#256

Post by stctgion »

asfdsfggtfd wrote: post #255
brandonbloom wrote: post #136

Earlier quoted context omitted.

I agree that it's _easier_ for teams to have their own little fiefdoms, but not necessarily _better_. Shipping the org-chart is often a symptom of a leadership problem. When natural service boundaries exist, good leadership may choose to ship the org-chart, but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture.

Isn't the idea to decide the architecture then update the org-chart to reflect this? Not that this actually happens-or would be a particularly good idea if it did for other reasons (like breaking up teams etc).

Happens where I work quite frequently, and yes it does have the effects you describe

Re: The Death of Microservice Madness in 2018

#257

Post by dwmkerr »

kovacs wrote: post #142
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…

Thanks for the comments. When I was writing the article I kept on thinking that really this is just the same old fundamental problem in a new guise, which is in many ways just how to manage component boundaries and dependencies, particularly when you are looking at a system which is being handled by more than one person.

Re: The Death of Microservice Madness in 2018

#258

Post by dwmkerr »

linkmotif wrote: post #164
DSMan195276 wrote: post #83

Earlier quoted context omitted.

I wouldn't say it should never happen, but if you end up with tons of dependent services you're going to be in dependency hell rather quickly. Where, only some versions of some services can be installed along side others, and when you update one component you may end up having up update almost all of them to keep the dependencies correct.

That’s right but kubernetes and helm make it easy to launch entire service stacks at a new version. That’s been my approach. Launch a new application and change DNS or ingress, etc. When satisfied, trash the old application.

Definitely a good approach, I'd like to update the article to mention this as a recipe for success. The only challenge I've seen is when the old app is still doing work behind the scenes, such as running crons or dequeuing messages or whatever.

Re: The Death of Microservice Madness in 2018

#259

Post by kuschku »

dreamcompiler wrote: post #175
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 call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

That may be a bad analogy, considering painting your own apartment is something a great deal of people do, and often with good success.

My parents (not in any way experts on that field) painted their entire house themselves, except for two rooms that were painted by a professional painter, and the professional painter left much worse corners than my parents. This was the paid-for result (ignore the dark corner at the bottom, that’s caused by the flash): https://i.imgur.com/s1VHV2W.jpg

Re: The Death of Microservice Madness in 2018

#260

Post by zimpenfish »

foo101 wrote: post #156
HelloMcFly wrote: post #117

Earlier quoted context omitted.

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.

I think the context is pretty clear: microservices. If it takes 10 people to manage one service, it is not a microservice by definition. It is more like a 10x-microservice or a macroservice.

I suppose it depends if those 10 people are purely developers or include the other teams you'd need - monitoring, devops, etc. For a critical, high-performance microservice, I can easily see it needing the involvement of 2+ devs (at least one senior), product owner, project manager, QA, devops, monitoring, etc.
Post reply on HN