Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff
I would only seriously consider a move to microservices for deployment/perf reasons.
It's about how to keep the velocity without firing junior dev, without removing bad code from the production system.
So microservice is a leadership tool to manage it. Keep it in control.
I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."
I know you are referring to something else, but it actually means that the battle is won.
For what it's worth, I suddenly feel a lot better about my employer's architecture. :-) But we still call them microservices because language.
The banner on the train was 'The Internet', the cartoon was published in 1995, right when the dot com bubble started its proper inflationary phase.
These hype-trains occur over and over again around a specific theme, the funny thing is that 'the internet' eventually became at least as revolutionary as those that were trying to board that train hoped it would be. But the bulk of those hyped things are usually not going to make such a huge difference and then, instead of adopting the item and incorporating it we move on.
You can usually get an idea after a year or two when a technology is introduced which way it will go, and a good sign that the life is out of it is when the consultants and writers of books move on to greener pastures.
See also: blockchain, the semantic web, etc, etc...
Then I heard about "microservices," and the people using that term were talking about JSON and HTTP and DNS, stuff you could actually imagine working, and then you tried it and you actually could get it working with almost no effort, which was mind-blowing in a different and better way.
That difference was a historical accident based on where those terms were in the hype cycle. Now a lot of definitions of "microservices" describe architectures that are almost as elaborate as the old SOA ideas I was exposed to, and people have the same reaction I did to "services" back then. And now it's the supposed microservices experts who will tell you that if you did anything simple enough that you actually got it working in less than six months with less than fifty people, then you did it wrong and doomed your company. The hype cycle has made a complete turn.
Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).
Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.
Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.
I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"
The reality is like this: You have a critical system that ran for ages, and now what will you do to scale the features ? By allowing/teaching junior devs to understand how to contribute to the codebase ?
There's a simpler way to do that efficiently: Extract a subdomain into its own microservice and you control the interface. Then even that microservice has bad code quality (tech debt), your business is still running fine!
Problem solved.