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

181–190 of 469 posts

Re: The Death of Microservice Madness in 2018

#181

Post by quodlibetor »

bmer wrote: post #157
brandonbloom wrote: post #136

Earlier quoted context omitted.

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.

> ...but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture. hahaha Do you know if there are some well chronicled cases of this happening? I find it very believable, but you know, would love to read something "actual".

I believe this is a paraphrase of Conway's law. The Wikipedia article lists three studies in favor of it, so there's that.

https://en.wikipedia.org/wiki/Conway%27s_law

Re: The Death of Microservice Madness in 2018

#182

Post by learc83 »

jblow wrote: post #138
always_good wrote: post #110

Earlier quoted context omitted.

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.

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 sculpt a basic statue suddenly became really valuable, the skill level of the average working sculptor would plummet.

Re: The Death of Microservice Madness in 2018

#183

Post by humanrebar »

elgenie wrote: post #121
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 critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value. Good developers create code that's prepared for the possibility of being modified repeatedly and becoming fo…

> ...preparing for code/components to be thrown away is a no-op.

You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.

Re: The Death of Microservice Madness in 2018

#184

Post by maga_2020 »

klodolph wrote: post #152

Background… I’ve been on good and bad projects that used microservices, and good and bad monolithic projects. The madness is going away but the microservices are staying. There are some rationales for microservices that are conspicuously missing. 1. Fault isolation. Transcoder stuck in a crash loop? Upload service using too much RAM? With microservices, you don't even really have to figure out what's going on, you ca…

WRT #2. Data isolation argument.

it is not clear to me, why data isolation is your view, is exclusive to microservices.

I have build non trival RBAC+ABAC authorization platforms, using PDP and embedeabble PEP, and did not find that it was useful by micro services only. And I did not feel that it can only be called via 'micro service' pipeline.

In a way the Authorization is a separate service, yes, but it should be offering an embeddable PEP (policy enforcement point) that one can embed (link or call out-of-process if needed), from pretty much anywhere (monolith, or any runtime component).

Authorization decisions require very very low latency, as you are authorizing pretty much every data or function interaction.

In fact, for data interaction, authorization engines offer SQL-rewriting/filtering -- so that the actual 'enforcement' happens at the layer of database you are using, not even at the layer of the component that's accessing the data.

Re: The Death of Microservice Madness in 2018

#185

Post by zenlikethat »

daxfohl wrote: post #126
zenlikethat wrote: post #114

Earlier quoted context omitted.

It sounds like you're conflating a binary barrier with a service barrier here. In your example you have two cleanly defined services which happen to be in the same binary. The issue with monoliths is when they all do the same thing because the code is a big ball of mud that "cheats" by calling shared subroutines and doesn't have a clearly delineated API. Therefore you have only one knob to turn to scale. The 20+2 dis…

That doesn't answer the question though. Suppose the apis are completely independent. Say one is a chess server and the other generates haikus. Granted that's silly architecturally to put into a single binary, but that's not the question. My question is why specifically managing scalability becomes easier when deploying them independently. My thought is that it actually becomes more difficult as you have to manage ea…

No, the whole point is that most teams just shove everything into one monolithic program. If you "suppose the APIs are completely independent", that's not a monolith.

Re: The Death of Microservice Madness in 2018

#186

Post by ChicagoDave »

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.

Re: The Death of Microservice Madness in 2018

#187

Post by virmundi »

linkmotif wrote: post #163
virmundi wrote: post #105

Earlier quoted context omitted.

Service dependencies indicate that you're domain is not properly broken down, or that the services are communicating incorrectly. They can share information, but probably better to do so via events and data copy. For example, you have a centralized security service. It handles the things related to accounts, profiles and group membership. You have a recipe service. It handles things like finding recipes, adding them…

Thank you for the answer. All of this makes sense but also seems unavoidable to some degree. Seems like a set of tradeoffs you make by going microservies that you should be weary of. Having services fully state-decoupled via unified log is interesting. I’ve considered this but it seemed a bit complicated in terms of then being able to scale the services that need, say, local copies of user profiles.

It can be, heck it is difficult if you think about service having to have access to a full profile. If it is the case, that service should probably be part of the profile containing service. But you might not need the full profile.

Here's two examples. Provided you don't get much churn in key profile data, you might be able to use JWT to store group membership for example. All services can read the the token. The token provides the groups necessary for the access operation.

Another example is only copying parts of the data. My current project has profiles and memberships. Interestingly the app side code doesn't actually use that information directly. A copy of group membership is held in the DB. When the user executes any operation, the queries themselves check for rights. When a use wants to read a list of recipes, part of the query is "and has read permission". The same is true of updates. The system queries for the resource to update. Only those that the user has an explicit right to modify are found.

Re: The Death of Microservice Madness in 2018

#188

Post by nucleardog »

rtpg wrote: post #146
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…

Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And it…

> Do you legit think that people are all just doing this as a fad?

As you say there are a lot of pros and cons to any architecture or paradigm, which is why we're still talking about it and saying things like "right tool for the job" and not just using the One True Method(TM).

I legit think that a lot of people using the new hotness as a form of cargo cult programming with no understanding of the methods they're considering or how they apply to the problems they're trying to solve.

It's not just microservices that are improperly applied. I've been in the industry long enough to see dozens of languages, technologies, paradigms, processes, and everything else hailed as the second coming of christ and applied inappropriately all over the place until the shinyness wore off.

And I mean... When we start talking about developing for Amazon scale, we're already talking about situations that don't apply to 99% of developers. Not a great argument that their cases aren't inappropriate applications of the pattern.

Post reply on HN