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

131–140 of 469 posts

Re: The Death of Microservice Madness in 2018

#131

Post by jiggunjer »

HelloMcFly wrote: post #117
st3fan wrote: post #108

Earlier quoted context omitted.

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.

I think he is literally asking for the other perspective? "I run 8 services myself" can be read as arrogant, OR it can be read as "I do things very differently", which is how I read it initially.

Re: The Death of Microservice Madness in 2018

#132

Post by luikore »

I think another (important) cause of microservice is politics:

When every department wants the easiest job with max outcome and the boss decides to split the cake equally, then an easy job X can be cut into N services which are usually named "micro", resulting in a huge project of complexity (X/N)^N for each team.

Re: The Death of Microservice Madness in 2018

#133

Post by ec109685 »

These two statements don't reconcile:

> Being both a developer and an operator is already tough (but critical to build good software)

> Yes, with effective automation, monitoring, orchestration and so on, this is all possible

This argues for having a separate ops team to handle the complexity centrally (e.g. operating a kubernetes cluster, providing standard building blocks), so developers can concentrate on their services.

Re: The Death of Microservice Madness in 2018

#134

Post by bayonetz »

The issue with designing an internal service without a consumer in mind is it tends to bloat the functionality and interface to allow for a variety of speculative-at-best use cases. The issue with desiging an internal service with a consumer in mind is that you tend to build a "distributed monolith". It's like a fricken Zen riddle. That's why it takes a master to navigate the middle ground successfully.

Re: The Death of Microservice Madness in 2018

#135

Post by Clubber »

nemothekid wrote: post #33
dvt wrote: post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

>They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM.

9 times out of 10 it's because developers don't know how to properly design and index the underlying RDBMS. I've noticed there is a severe lack of knowledge of that for the average developer.

Re: The Death of Microservice Madness in 2018

#136

Post by brandonbloom »

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.

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.

Re: The Death of Microservice Madness in 2018

#137

Post by tehlike »

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…

If something isn't broken, do not fix. I think part of it is that large companies can keep engineers happy by giving them rewrites. Otherwise, not enough projects to keep everyone entertained.

Re: The Death of Microservice Madness in 2018

#138

Post by jblow »

always_good wrote: post #110
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.

Well, I've also worked for places where I'm on call for some service maintained by one person that's built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self. These days I kinda wince at "I run 8 services myself."

Those of us who have been around since the 80s-90s are astonished by the low productivity of today's programmers.

If it takes 1 person to run 1 microservice, we are all doomed.

Re: The Death of Microservice Madness in 2018

#139

Post by jblow »

Clubber wrote: post #130
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.

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.

Re: The Death of Microservice Madness in 2018

#140

Post by flukus »

Chiba-City wrote: post #92

Reminds me of distributed architectures like CORBA turning into spaghetti in the 90's.

Seems like every ten years or so a new architecture comes along and quickly devolves into into being yet another distributed RPC mechanism. There was CORBA, SOAP, SOA and now micro services. All promised to fix what came before and all ended up repeating the same mistakes in practice.

Can any of the old timers here name any predecessors to CORBA?

Post reply on HN