Next up, mixing logic and presentation like it's 1999 cough php cough react native
The Death of Microservice Madness in 2018
151–160 of 469 posts
Re: The Death of Microservice Madness in 2018
#152Background… 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 can often just roll back the affected component.
2. Data isolation. Only certain, privileged components can access certain types of data. Using a separate service for handling authentication is the classic example.
3. Better scheduling. A service made of microservices is easier to schedule using bin packing. Low priority components can be deprioritized by the scheduler very easily. This is important for services with large resource footprints.
The criticisms remind me of the problems with object-oriented programming. In some sense, the transition is similar: objects are self-contained code and data with references to other objects. The 90s saw an explosion of bad OO design and cargo cult architectures. It wasn't a problem with OO design itself. Eventually people figured out how to do it well. You don't have to make everything an object any more than you have to make everything a microservice.
Re: The Death of Microservice Madness in 2018
#153I found out recently that people too often think about microservices in context of broader solution like it would be one app, just scattered around. I did that mistake in the past, either. The longer I work with microservices the clearer it is to me that teams implementing them should forget about the big product, just focus on the service, as it would be product itself. Assume that anyone can use it, for any purpose…
IOW, good, clean function composition.
While this is a simplification, I often catch myself thinking: isn't programming creating functions and functions of functions and that all way down? And on each layer we call them differently because of the context we're in.
Input --> Stuff happens --> Output
Again, it's a simplification, although to be fair, I sometimes don't see how -- other than that I'm feeling that I'm ignoring context too much (e.g. underlying hardware or networks or REST API endpoints).
Re: The Death of Microservice Madness in 2018
#154I 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…
To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject…
I think you actually have hit the proverbial nail with the hammer. I've seen firsthand the terrible talent pool, at least here in the south-west US. We've done ourselves a disservice trying to get everyone and their brother to become a programmer because...economy! and more accurately, I want more money.
Re: The Death of Microservice Madness in 2018
#155Biggest 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…
Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…
> They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM.
I've dealt with an even worse system, with a dozen separate applications, each in its own repo, then with various repos containing shared code. But the whole thing was really one interconnected system, such that a change to one component often required changes to the shared code, which required updates to all the other services.
It was a nightmare. At least your folks had the good sense to use a single repository.
Re: The Death of Microservice Madness in 2018
#156Earlier quoted context omitted.
Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.
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.
Re: The Death of Microservice Madness in 2018
#157Earlier 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.
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".
Re: The Death of Microservice Madness in 2018
#158Will someone enlighten me as to why a microservice should have no dependent services? Seems reasonable to me.
I prefer that the advice not to be dogmatic about saying “no” but rather to be wary of the costs. The big benefit of microservices is being able to easily reason about or scale services, but adding dependencies usually sacrifices those benefits. I’ve seen that done poorly in the various iterations of this cycle and the worst failure modes mean that debugging requires you to understand how to get & interpret state fro…
> The big benefit of microservices is being able to easily reason about or scale services, but adding dependencies usually sacrifices those benefits.
Thank you that makes sense.
Re: The Death of Microservice Madness in 2018
#159Reminds me of distributed architectures like CORBA turning into spaghetti in the 90's.
Seems like every ten years or so a new architecture comes along and quickly devolves into into being yet another distributed RPC mechanism. There was CORBA, SOAP, SOA and now micro services. All promised to fix what came before and all ended up repeating the same mistakes in practice. Can any of the old timers here name any predecessors to CORBA?
PVM (a.k.a. Parallel Virtual Machine) perhaps? Predates CORBA by several years
Re: The Death of Microservice Madness in 2018
#160Earlier quoted context omitted.
Microservice architectures [usually] represent a management failure because they usually don't work well in the real world. It's easy to concoct a paper-only, theoretical version of an idealized microservice architecture, since you can gloss over all the real-world details and practicalities. Mapping that theory into the real physical world is a whole different ball game. Conway's Law might as well be renamed "The La…
This I can entirely agree with - framing my point around Conway's law works well and I think I can reframe my question as "is the expression of Conway's law a management failure, or is it the mis-structuring of the organization causing the expression to be harmful?" The parent post I was replying to seemed to simplify things down to "let your developers communicate and they'll build a more coupled system that works,…
I think my point was misunderstood, probably because I did a poor job of explaining it as I was cramming a hamburger in my facehole and watching the Pats win the AFC :)
I think in many cases microservice architectures appeal to engineering organizations with poor communication and cooperation skills where developers desire to be strongly independent because of the lack of management creating a cooperative and coordinated dev and work environment. I think that's actually saying something very similar to the Conway Law idea brought up by the other poster.