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

371–380 of 469 posts

Re: The Death of Microservice Madness in 2018

#371

Post by juanmirocks »

markatkinson wrote: post #246
dreamcompiler wrote: post #175

Earlier quoted context omitted.

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.

Great analogy. I tried to paint my own flat. Was a disaster.

I feel you.

I managed to paint my walls, but it took me much more time than expected and my flat was chaos for some weeks thereafter.

Re: The Death of Microservice Madness in 2018

#372

Post by [deleted] »

dragonwriter wrote: post #200
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.

I think that it is accurate to say that in a system composed of microservices, a microservice should not effect the state of other microservices in the system other than by consuming them. Whether it should consume other microservices is less clear, and gets into the choreography vs. orchestration issue; choreography provides lower coupling, but may be less scalable.

[deleted]

Re: The Death of Microservice Madness in 2018

#373

Post by dragonwriter »

ozim wrote: post #266
dragonwriter wrote: post #200

Earlier quoted context omitted.

I think that it is accurate to say that in a system composed of microservices, a microservice should not effect the state of other microservices in the system other than by consuming them. Whether it should consume other microservices is less clear, and gets into the choreography vs. orchestration issue; choreography provides lower coupling, but may be less scalable.

Services consuming other services, sounds like recipe for spaghetti. I hope people use layering where you don't call stuff that is in the same layer.

Look, I generally prefer choreography over orchestration, too, but architectural dogma can conflict with pragmatism, and at a minimum Netflix’s argument as to why they found orchestration more usable at scale seems plausible enough for me not to reject it out of hand without experience with the two patterns at anything like Netflix scale.

Just like sometimes, in real-world C, “goto” is the right tool, even though arbitrary jumps of that kind are also a “recipe for spaghetti”.

Re: The Death of Microservice Madness in 2018

#375

Post by tvanantwerp »

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…

An important piece of advice I was given when embarking on my technical career:

> You don't solve problems. You take the problems you have, and exchange them for a different set of problems. If you're doing your job, the new problems won't be as bad as the old problems. That's all you can really do.

Re: The Death of Microservice Madness in 2018

#376

Post by smaddox »

sedachv wrote: post #248
learc83 wrote: post #182

Earlier quoted context omitted.

It's because that 1 micro-service has 300 dependencies. Higher levels of abstraction makes it easier to get something up and running fast, but at some point you need to be able to look under the hood and understand what's going on, and many programmers today can't do that. That being said I think the drop in average skill is mostly a product of the growth in the number of programmers. I imagine that if the ability to…

> Higher levels of abstraction makes it easier to get something up and running fast More layers of indirection in a system and more dependencies on external libraries and tooling does not necessarily get you any abstractions. To take a contemporary example, there is no "abstraction" in being driven to use Docker because your dependencies have gotten unmanageable otherwise.

Docker is an abstraction...

Re: The Death of Microservice Madness in 2018

#377

Post by d0mine »

cortesoft wrote: post #205
dreamcompiler wrote: post #175

Earlier quoted context omitted.

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.

So you are saying edge and corner cases are the most difficult?

They are also most common: «the high-dimensional unit hypercube can be said to consist almost entirely of the "corners" of the hypercube, with almost no "middle".» https://en.wikipedia.org/wiki/Curse_of_dimensionality#Distan...

Re: The Death of Microservice Madness in 2018

#378

Post by at-fates-hands »

WalterBright wrote: post #277
markatkinson wrote: post #246

Earlier quoted context omitted.

Great analogy. I tried to paint my own flat. Was a disaster.

I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

I used to work for a home theater company. We were regularly working on newer mansion in the suburbs. If you ever want to see some dudes that work faster than fast, go hang out with a drywall crew.

I remember showing up on a site, and the drywall guys had just started carting in a ton of drywall. By the time we left in the afternoon, they had cut, hung, taped and mudded over 3,000 sq feet of home, it was insane.

Re: The Death of Microservice Madness in 2018

#380

Post by corpMaverick »

kumarvvr wrote: post #233
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…

> It's not a micro-service if you have API dependencies Just out of curiosity, what alternatives are there to avoid API dependencies? Is it really possible to make non-trivial apps while avoiding internal dependencies? At some level, is it really possible to have a truly decoupled system?

> Just out of curiosity, what alternatives are there to avoid API dependencies?

Very important how the boundaries a drawn. Generally, the more fragmented the micro-services the more API dependencies.

Also, look at the Bounded Context concept.

https://martinfowler.com/bliki/BoundedContext.html

And Conway's Law certainly plays a role.

http://www.melconway.com/Home/Conways_Law.html

> At some level, is it really possible to have a truly decoupled system?

You cannot avoid all the API dependencies, but you can reduced their number.

Post reply on HN