I can’t wait until the Kubernetes/container/Microservice beasts we are building today become legacy in 20 years. Fixing a COBOL application will probably look simple in comparison.
But I'm getting the feeling that a lot of people worry a lot about the runtime. They break up their applications into microservices not to solve a problem, but because they believe it's the best thing to do because $reason. But you shouldn't do that until you're actually running into an issue and have exhausted the other, simpler options.
I mean I wouldn't mind having or experiencing an actual scaling problem directly, but so far I've never seen it. I've seen a LOT more organizational and technical problems stemming from intentionally building a microservices architecture though.
But building just the one codebase is dull.
But as you can see in the comments in this thread. The coolness of micro services seems to be slowly fading. Feels a bit like the state of noSQL in 2014.
But when you are building systems it becomes slightly more complicated. Especially those that require that the data science team write their code in Python / PyTorch and the application team write their code in Typescript.
It’s really annoying.
the solution, however, would be to hire a small number of really good developers and have code reviews run through them - hopefully teaching the more average developers how to code better in the process.
At least one of them will be guaranteed to be built with some technology/language (probably Scala or Elixir) that one of your engineers (who's since left) was interested in for a few weeks.
Asking in interviews questions like “how many namespaces are you managing or expecting to manage” and often times teams are talking about a single microservice and bringing in k8s “just in case”
To which I’ve oft said “good luck in your endeavors”
From the resume-driven-development angle, probably. I do the same though.
If you prefer to work in a sane environment though, wise choice.
The problem is companies with poorly designed monoliths hit complexity problems more quickly and often. If software architecture is not a core competency, solutions architecture is probably not either, and poorly designed microservices are a completely different beast. A distributed monolith is inherently more difficult to maintain and operate.
If you only need to understand and maintain one of them, sure.
That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.
Maybe if you're CTO. Never seen that in case of individual contributors.
You're not likely ever going to be at the same level of detail on everything all at once, and there can still be fuzzy parts - third party partners in particular can be difficult, especially if the org is not good at making known who's the SME for what - but you absolutely can build an understanding of the architecture as a whole, and that makes you able to dive in and work on just about anything without needing much spinup time.
(Granted this assumes good technical and architectural leadership early on that has specified standards for interservice communication, intraservice code design, what layers exist and how they interoperate, etc. That said, Wild West microservices might still be less painful to work on than a Wild West monolith - I don't actually know, but I could come up with arguments either way.)
I'm thinking more from the perspective of a small team supporting a large operation, because those are the kinds of situations where I've spent a lot of my career. FAANG scale would be a novel experience for me, as I suspect it would for most.
Not to say you can't get in trouble that way, for sure. It's its own kind of tradeoff, not least in that you need more ops support than a simpler infrastructure would require, and you need someone with the architectural vision and authority to ensure things don't get out of hand. It's definitely not where I'd want to start with anything, and you need a strong team to make it work, but I can say from experience that it can work amazingly well. Like, about twenty people supporting about $2B ARR well.
(Sure if you're google sized, nobody will understand or even know the entire system. But nearly every company on earth is smaller than that.)
We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it
Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design.
Teams that design poor monoliths typically have neither a software or solutions architecture proficiency
I still haven't done anything with k8s, but I suspect it's the solution to this problem, even if it would take that same herculean effort to finally get everything moved to using it (we don't even run containers, we run our own application delivery system that has some similarities without the process isolation, because we've been doing so since before Docker existed).
That feels like a self-inflicted wound that will now only get worse with k8s.
What's the alternative? It's not like we're some web property with an application, it's an ISP, and we sell internet services, and we've been around long enough that we still offer traditional ISP services (many for free) such as email, hosting, VPN service, etc, as well as telecom services. These often need to communicate with each other in some way, as well as many back-end services we've written to serve our staff.
Microservices come with problems, but honestly I can't see a large monolithic app (or even a few of them) being much better development wise, even if it might have been easier to test and set up a development environment.
So far I would not say it is worth it for most people. I also hate how much the community just runs random shit from the internet without any strategy for security patches or digital signatures.
Fixing up the docker images will give you some variety outside deciphering cut and paste garbage cryptic mess in helm charts.
Too much monolith ends with abstraction inversion, which is a Bad Thing.
Refactor that estimate by an order of magnitude.
Most are already legacy next year. (Sadly I'm in that situation too, migrating off an expensive AWS cluster to a single Jenkins machine...)