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

241–250 of 469 posts

Re: The Death of Microservice Madness in 2018

#241

Post by cube2222 »

virmundi wrote: post #223
ChicagoDave wrote: post #186

I've delivered two major applications (400k users, critical internal apps) using micro-services in the cloud reducing cost and increasing continuous delivery capabilities. There are definitely special cases, but overall, after 33 years building software, domain driven design, PaaS, micro-services, and continuous delivery is the most productive paradigm I have ever seen.

Please go on. Can you provide details?

Not the OP but also having worked on multi-million user apps, off the top of my head: zero downtime deployments, small failure domains (if you make a bad update to a service, only related functionality suffers, the rest keeps working), frequent small deployments (like, several times a day), easy and quick integration testing (cause you only have to test the functionality of one service, not the whole system), easier debugging, cause if one functionality isn't working, it's easy to analyze only the logs of the service responsible for that functionality (and optionally move to others later, having identified some part of the cause). Also, every microservice is a new clean slate, you can quickly learn from your mistakes and try out new approaches. (Not diametrically different, but you have the ability to iterate more)

Edit: another one, is that if you keep the microservices actually small and well described by an API, you can easily, quickly and safely heavily refactor/rewrite old services.

Re: The Death of Microservice Madness in 2018

#242

Post by charlieflowers »

Chiba-City wrote: post #177
charlieflowers wrote: post #167

Earlier quoted context omitted.

Java RMI, which had the misguided goal of making objects (the whole world was fully in the grip of OO religion) appear the same, regardless of whether they were local or remote to you.

I was going to mention RMI, but couldn't recall the TLA. Does anyone else remember LANS and Windows NetDDE? That got end user machines involved in "distributed" computations.

COM+ also had distributed transactions. I was fortunate not to work with it too much.

Re: The Death of Microservice Madness in 2018

#243

Post by virgilp »

foo101 wrote: post #169
humanrebar wrote: post #104

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…

> good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines.

No, that's not true, except in a very superficial sense. Yes long hours _can_ increase the chance of meeting deadlines... but often, it doesn't - or more precisely, it only works if the code quality is decent.

"Code quality" is not about following whatever patterns are en vogue today, or using the latest dev language. It is mostly about simplicity - dealing with few things at a time, and making those things explicit. If you need to understand the entire solution, and the entire domain model, and all the edge cases before making the tiniest of modifications - long hours are not going to help you.

To go back to microservices: many companies claim to build microservices, but actually build a distributed monolith. This doesn't help productivity, it actively harms it.

Re: The Death of Microservice Madness in 2018

#244

Post by xtrapolate »

Decoupling code/infrastructure is not a bad practice. As it so often turns out to be, "Microservices"/"Monoliths" mean different things to different people, and your mileage may vary. Difficulties may be introduced going either way.

Choosing the right tool for the job is difficult, there are many variables at play. There's a lot of value to people sharing their perspectives/experience about these issues. At the same time, I think the overall discussion shouldn't be so dichotomous.

Re: The Death of Microservice Madness in 2018

#245

Post by snowwrestler »

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.

If "micro" refers to the scope of the service (i.e. very limited feature set), you might still need a team to run it, if the service has to handle a very high volume of transactions or provide very low latency, or both.

Re: The Death of Microservice Madness in 2018

#246

Post by markatkinson »

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.

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

Re: The Death of Microservice Madness in 2018

#247

Post by ec109685 »

philwelch wrote: post #215
ec109685 wrote: post #133

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 se…

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.

Re: The Death of Microservice Madness in 2018

#248

Post by sedachv »

learc83 wrote: post #182
jblow wrote: post #138

Earlier quoted context omitted.

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.

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.

Re: The Death of Microservice Madness in 2018

#249

Post by manigandham »

There is no such thing as "microservices", it's just services, otherwise known as a service-oriented architecture (SOA). A service is a logical grouping of functionality as it makes sense in your business domain. A small service for a large company can be bigger than the entire product of a startup; there is no standard unit of measure.

Computers also don't care how code is deployed and different services can be bounded by classes, or namespaces, or assemblies, or packages, or processes, or completely separate APIs reached over the internet on the other side of the planet.

Microservices can perhaps be defined as more of a deployment model but even then it's 99% about the team and organization structure. As companies get larger, there is a trend towards smaller teams in charge of separate functionalities that create, deploy, and operate their own service. This can be effective in managing complexity and creating efficiency, although definitely not absolutely necessary.

All that being said, outside of the major software companies, I have seen exactly 0 uses of microservices where the benefits were worth the effort, if any benefits even appeared at all.

Re: The Death of Microservice Madness in 2018

#250

Post by analyst74 »

daxfohl wrote: post #109

Why is scaling independently a pro? I've heard that argument before and never understood it. If I have one api that is low throughput and one that is high, say requires 2 and 20 nodes respectively, then you need 22 nodes whether they are two independent microservices or a monolith. I'd think the monolith would actually be easier to manage as you don't have to worry about how to divvy up the resources. All 22 nodes ru…

Here is a non-exhaustive list of possible reasons:

- you use in-memory cache, so with monolith each instance will need X+Y amount of ram, where X is needed for api A and Y is needed for api B.

- say api A serves client http requests, and api B does some asynchronous resource intensive computations. When a large workload lands on api B, api A will suffer until auto-scaling kicks in. Even after auto-scaling kicks in, individual nodes could be overloaded which is fine for api B but unacceptable for api A.

- in a scenario where api A and B both serve client traffic, maybe you want to switch api A load balancing from round-robin to sticky, now you have to worry about the impact on api B as well.

The possible scenarios are endless, and you always have to think about both api.

Post reply on HN