Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

281–290 of 469 posts

Re: The Death of Microservice Madness in 2018

#281

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.

Microservices as the M in MVC?

Microservices is a back-end service pattern. MVC (Model View Controller) is a front-end pattern to enforce separation between data, UI and interaction logic.

Re: The Death of Microservice Madness in 2018

#282

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…

This is not wrong; this is I think also the reason behind the "framework of the month" craze in JS that seemed to be a thing last year / year before. Implementing business value is boring; working with new technology is cool and fun. I'm not impervious to that either. I mean I'm writing a HN comment while I should be building a feature :p

Re: The Death of Microservice Madness in 2018

#283
post #169

Earlier quoted context omitted.

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithi…

> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code c…

Management acts this way because they have no way of evaluating the effects of maintaining code quality. Only developers with significant experience are able to evaluate the long-term impact of each technical decision (and even we are still not very good at that).

And why should management be able to evaluate technical decisions and code quality in the first place? That's our job! The problem is that we have given management the false choice of lower quality + faster shipping vs. higher quality + slower shipping, when in fact we should not have given them any say in the matter. And before we hit me with the but we have to be first to the market and fix it later line, I need to point out that companies don't die because they were not first to the market, they die because their operations and development became so slow and costly that they could not compete anymore.

What we should do as developers is to stop talking about code quality to our managers! When we are asked for an estimate, we give them as accurate estimate as possible with the code quality that we feel is sufficient for long-term maintainability of the system. And we don't negotiate on quality anymore, and especially we don't negotiate on estimates! Only functionality (MVP and all that). Then we don't need to ask for refactoring time, rewrite time, code polish time, stabilization time on our systems (that we hardly ever get anyway), because it is all in there in the original estimate.

Management expects stable productivity, they base their estimates of operational costs and investment costs on the number of people working on the system, not on the age of the codebase (why should an old codebase cost more to work with? they ask). If we give them false hope on the productivity of the team by producing crap fast in the beginning, the whole business case may collapse when we produce the same crap slower and slower and slower later. Management is in no position to evaluate the effects of bad code on the business case, because they don't understand that. We do. The only thing we can do as developers, is to remove the option of low quality code altogether.

And we say that it is so slow to create quality code? And estimation is hard?

We learn it. We can write high quality code as fast as the usual junk we see in most systems. We keep track on our estimates and evaluate how well we did, and improve. But it takes effort. All I can say is that it is our responsibility.

On a positive note, the solution to this on a personal level is to find a place to work where technical excellence is built in the development culture (and there are such places), and cultivate that culture especially with the new hires (mentoring, pairing, etc.).

Re: The Death of Microservice Madness in 2018

#284

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.

Trump once met a porn star who said she'd do anything for $130,000. So he told her: "Ok: Paint my tower!" It was all a perfectly innocent transaction.

Re: The Death of Microservice Madness in 2018

#285
Because I find debating about the pro's and con's about microservices somewhat cumbersome, I tried to let the code speak and record a screencast series on exactly this topics. (https://www.marcobehler.com/series/9-microservices-the-good-... ) Because I feel that especially in the Java world, Microservices are an utter abomination most of the time. Comments more than welcome!

Re: The Death of Microservice Madness in 2018

#286
This is a well thought out and well reasoned article.

It resonates on many of the pain points of microservices. I also nearly broke out laughing at his definition of "microservice madness":

> Netflix are great at devops. Netfix do microservices. Therefore: If I do microservices, I am great at devops.

Because it is so hilariously accurate it's almost painful.

I do want to point out something the author implies, which is that there are benefits to microservices as a pattern...and as a pattern it is likely here to stay. It's an advanced pattern that comes with tradeoffs and complexity increases on the ops side. In the best case you're trading developer complexity for operational complexity and perhaps also getting better reliability (but this is not a guarantee).

Additionally, projects like Kubernetes, Istio, and Envoy are all tools aimed at making certain operational complexities of microservices easier...so the operational trade offs are likely to change dramatically this year.

But in the end we can all still hope that madness dies in 2018 though.

Re: The Death of Microservice Madness in 2018

#287
One thing I’ve noticed with microservices is the business rules duplication. Everyone tries to solve their problem so the same rules start popping up (ofc implemented differently and mostly unknowingly) in all these microservices. The problems start when the business requirements change and you need to change all Microservices.

Re: The Death of Microservice Madness in 2018

#289
post #271

Earlier quoted context omitted.

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.

Yes, we do. The ecosystem is great and microservice architecture may be manageable even in small teams, but it's always a process that defines the success. From my own experience, the biggest technical problem of microservices in Java can be the performance of the whole system (in a monolith there's much less logging and state management, no network latencies and mismatching parallelism settings). Discovery, auth, messaging, configuration management etc are solved.

Re: The Death of Microservice Madness in 2018

#290
post #229

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.

They can manage those teams by writing libraries, no need for microservices.

It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.
Post reply on HN