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

271–280 of 469 posts

Re: The Death of Microservice Madness in 2018

#271

Post by antonp »

charlieflowers wrote: post #239
zenonu wrote: post #118

Earlier quoted context omitted.

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.

Would love to hear some peoples' thoughts on good contenders in each of these areas. What are some good boxes to get these out of in 2018?

Would like to echo this request.

Had to implement a micro-service architecture in python about a year ago and was jealous of my Java colleagues who (so I heard) have great ecosystem for enterprise service discovery, messaging etc.

Re: The Death of Microservice Madness in 2018

#272

Post by sidhuko »

We are such a totalitarian part of the species. Someone writes about microservices and my next project I'm building services for each feature because some manager heard it increases reliability. The fact is its always science. If you don't want your inconsistent dataset from somewhere else in the corporation taking down your application then chunk a part of the application into your own container to manage calls rather than allowing the event loop to block up. It doesn't have to be 'micro', it has to exist for some reason, if not it is just your developers trying to be cool.

Re: The Death of Microservice Madness in 2018

#273

Post by cc81 »

ec109685 wrote: post #247
philwelch wrote: post #215

Earlier quoted context omitted.

You can and should have a cross-functional team (containing both devs and operators) to build and operate your infrastructure automation. But the operation of the individual services still falls on the teams that own them.

Right, but the complexity the author complains about is then not on the individual services’ developer teams.

I'm starting to like more and more that you have a "devops" team that is responsible for the application in all environments. They deploy and monitor it but also expose that monitoring to others.

Then you have the platform teams that support them by managing the platforms they use, the monitoring solutions etc. and work as much as possible so the devops teams can be self service.

I have no experience with it though but I feel that having all knowledge in all devops teams does not scale to any sufficiently complicated environment and the idea of the dev team not being responsible for deploying to production sucks.

Re: The Death of Microservice Madness in 2018

#274

Post by vanderZwan »

kuschku wrote: post #259
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.

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…

Aside from the "sample size of one"-issue: how much time did your parents take, and how much effort and preparation time, and how did that compare to the time and effort the professional needed? It could be a trade-off issue there.

Also, note that this thread started with a comment about how many developers don't appreciate what the actual hard problems in their own line of work are, and how that produces poor results because of that. I expect that to be true of any profession that doesn't have some kind of rigorously enforced standard.

Re: The Death of Microservice Madness in 2018

#275

Post by drej »

What I "love" about some microservice implementations (so not microservices in general), is that people use fast and scalable data platforms to analyze data in microseconds, but then slap a REST API in front of them, ideally with slow authentication and logging (and ideally in a different availability zone), so instead of waiting 20 ms for your metric, you get it in 3 seconds.

I love (without quotes) microservices for their isolation principle, people can kill off/rewrite parts of the system without affecting other parts, written possibly in a whole different language etc., but lets not abuse it. If you put every tiny function behind an API, what you'll get is a slow and unmaintainable mess.

Re: The Death of Microservice Madness in 2018

#276

Post by WalterBright »

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've been writing code since the 70's. The further back in time one looks, the worse my code is. The good news, I suppose, is that one is never finished learning how to write code better. Until they plant me, that is.

Re: The Death of Microservice Madness in 2018

#277

Post by WalterBright »

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've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

Re: The Death of Microservice Madness in 2018

#279

Post by ZeroGravitas »

simias wrote: post #268
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…

The #1 thing they should teach in any engineering school (or maybe any school period ) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

Would those graduates be rewarded or penalised for their professionalism? I would guess penalised in a depressing number of situations.

Re: The Death of Microservice Madness in 2018

#280

Post by Double_a_92 »

openasocket wrote: post #61
dvt wrote: post #47

Earlier quoted context omitted.

> That's plainly wrong. I get the gist of what you are saying and I more or less agree with it but you expressed it poorly. I'm not sure what you think side effects are, but I'm using the standard computer science definition you can look up on Wikipedia. If you have a microservice that modifies, e.g. some hidden state, it's a disaster waiting to happen. Having multiple microservices that have database side-effects wi…

So, according to your advice, we shouldn't use micro-services that write to a database, ever? That doesn't make any sense to me. Multiple services writing to the same database can be bad, but a single service storing persistent state in a database is perfectly fine. Just because we're micro- doesn't mean we have to cut out 90% of what a service is.

How would services such as "sign up", "login", "edit profile", and others that need auth be split?
Post reply on HN