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

231–240 of 469 posts

Re: The Death of Microservice Madness in 2018

#231

Post by klodolph »

maga_2020 wrote: post #184
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 of…

I think you may have misread my comment. I said "authentication" and you are talking about "authorization".

Authentication can be very easily centralized in a separate service, authorization is a completely different beast. Authentication often involves access to high-value data such as hashed passwords, authorization does not.

Re: The Death of Microservice Madness in 2018

#232

Post by [deleted] »

mauritzio wrote: post #207
nurettin wrote: post #203

Earlier quoted context omitted.

Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish. I also feel that ceteris paribus, the meetings got longer, project management tools now…

Sounds for me like productivity went down...

[deleted]

Re: The Death of Microservice Madness in 2018

#233

Post by kumarvvr »

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?

Re: The Death of Microservice Madness in 2018

#234

Post by JamesBarney »

foo101 wrote: post #156
HelloMcFly wrote: post #117

Earlier quoted context omitted.

I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.

I think the context is pretty clear: microservices. If it takes 10 people to manage one service, it is not a microservice by definition. It is more like a 10x-microservice or a macroservice.

While 10 is more than many recommend it's not that much more than Amazon's rule of < 7.

Re: The Death of Microservice Madness in 2018

#235

Post by andyfleming »

maga_2020 wrote: post #184
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 of…

Authorization and authentication are two different discussions. Protecting the data necessary for authentication is valid rationale. That same service could provide read-only data to another service in a single response that would allow for all subsequent authorization logic to be done without any additional latency. Additionally that data necessary for authorization may not be sensitive like the other data used for authentication.

Re: The Death of Microservice Madness in 2018

#236

Post by fulafel »

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 reinvention and re-discovery of the problems can be very good for the new developers who are taking over a slice of the monolith's functionality. And it an happen rapidly, on the new developers' own terms. Depends on the case.

Re: The Death of Microservice Madness in 2018

#237

Post by ramses »

The author omitted an important one: microservices are the new source of spaghetti code.

When trying to implement as multiple microservices something that should actually be a single service—i.e., the ms's are not useful as independent units—answering a single API request is an amazing mess of distributed calls all over the place and unnecessary serialization/deserialization of queries.

Re: The Death of Microservice Madness in 2018

#238

Post by daxfohl »

rurounijones wrote: post #218
daxfohl wrote: post #126

Earlier quoted context omitted.

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…

Usually because they have different usage patterns. Chess API is a daily cycle between 10-1,000 TPS and is CPU intensive. Haiku is uaually 1-10 TPS apart from Fridays (when everyone's device gets a new one) and holidays when it spikes to 100,000 TPS and is IO intensive. Scaling a single service with both these API endpoints being called for different pattens like the above is a pain. Splitting them allows for choosin…

Thanks, and to add to that, it occurred to me that they may have different criticality too. Some services you may want to scale very aggressively because a failure would be catastrophic. Whereas other services may be even more cpu intensive on average but failures are acceptable so you let them run at 90% load. I'd imagine this would be a far more difficult balancing act if they were both in the same process.

For example if you had your chess AI engine running in the same monolith as your web server, it could slow down your response time to the point of timeout. But if they were separate services, your web server could stay snappy and give a meaningful response to the problem. "our ai service is overloaded right now, but here is a nice haiku while you wait."

Though still, I'd think of that as a fairly advanced use case. Not something small projects should have to think about.

Re: The Death of Microservice Madness in 2018

#239

Post by charlieflowers »

zenonu wrote: post #118
JamesBarney wrote: post #90

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.

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?

Re: The Death of Microservice Madness in 2018

#240

Post by dwmkerr »

DanielBMarkham wrote: post #107

There's a ton of stuff here -- enough for a book or two. I loved the article although I might take issue with several of the smaller points. It's way too much to go into on an HN thread. There's just so many topics that all come together here: stateless programming, pure FP, NetOps, DevOps, and so on. It feels like one of those cross-discipline discussions where it's either really simple -- or really complex. In fact…

Hi Daniel,

It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved:

www.slideshare.net/ScottWlaschin/ddd-with-fsharptypesystemlondonndc2013

I was lucky enough to work on a big F# project a while ago and really enjoyed the experience, it was the first time I'd done any functional programming in a professional context and I miss it now that I'm doing more JavaScript and Node.js!

Thanks for the kind words on the article, much appreciated!

Post reply on HN