> because people realized "You're not Google. Your company will never be Google."
Is that also why almost no one is using microservices and Kubernetes?
Is that also why almost no one is using microservices and Kubernetes?
And it's not that "no one is using microservices", it's just that tons of companies realized they added almost as many complications as they alleviated, and that for many teams they were just way too premature. And a lot of the companies that I've seen have the most success with microservices are also the most pragmatic about them: they use them in some specific, targeted areas (e.g. authn and authz), but otherwise they're content using a well-componentized monolith where they can break off independent services later if there is an explicit reason to do so.
I don’t know of a single 100+ sized organisation in my area which doesn’t use micro services in some form. A lot of places also use kubernetes indirectly through major cloud provider layers line Azure Container Apps.
Our frontend (and indeed quite a bit of our backend) lives in a NX mono-repo. As for how it actually works, however, it’s basically a lot of micro-services which are very independently maintainable. Meaning you can easily have different teams work on different parts of your ecosystem and not break things. It doesn’t necessarily deploy as what some people might consider micro services of course. But then micro services were always this abstract thing that is honestly more of a framework for management and change management than anything tech.
Creating a new deployment is just super fast. Developers can deploy their own apps etc.
And then there is Helm.
If we only decide by “need” then most of the time we also wouldn’t need object oriented programming.
Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").
Yaml is for all intents and purposes a superset of JSON so if you render your subtree as JSON you can stick it in a Yaml file and you don't need to care with indentation.
This argument kind of died when python became one of the most popular programming languages used.
In JSON or s expressions, the various levels of objects can be built independently because they don’t rely on each other. In YAML, each block depends on its parent to know how far it should be indented, which is a huge pain in the ass when templating.
But Kustomize is very nice. Although, their docs could be a bit better.
Sure the full extend of Kubernetes is complicated and managing it might be a pain, but if you don’t go bonkers is not that hard to use it as a developer.
I'd love to have a private pool in my backyard. I don't, even though it's nice to have, because it is too expensive.
We intuitively make cost-benefit choices in our private lives. When it comes to deciding the same things at work, our reasoning often goes haywire.
Sometimes we need an expensive thing to solve a real problem.
Your point about object-oriented programming makes sense. Sometimes, a bash script suffices, and the person who decides to implement that same functionality in Java is just wasting resources.
All of these solutions have a place where they make sense. When they are blindly applied because they're a fad they generate a lot of costs.
Generally I only use it when I see a compelling case for it and the introduced complexity takes away complexity from somewhere else.
Don’t get me wrong, I like K8s and run it at home, and I’d take it any day over ECS or the like at work, but it’s not like you can’t achieve a very similar outcome without it.
There are many ways in tech to achieve the same result. I don’t understand why people constantly need to point that out.
I also don’t understand why k8s ruffles so many feathers.
Reminds me a bit of Linux vs windows vs Mac debates.
I’m a fan of graduated difficulty. Having complex, powerful systems should require that you understand them, else when they break – and they will, because they’re computers – you’ll be utterly lost.
Assuming there aren’t any particular scaling or performance requirements, if I were managing something like that, I would almost certainly not use k8s. Maybe systemd on a big box for the services?
In addition the overhead and reporting drawbacks of running multiple isolated databases is vastly higher than any advantaged gained from small isolated deployments.
Don't get me wrong, maybe they're good choices, but absent any other facts I'd start asking questions about what makes each service necessary.
Some of them try to migrate from it to a unified k8s "platform" (i.e. frequently not pure k8s/EKS/helm but some kind of in-house layer built on top of it). It takes so long that your tenure with the company could end before you see it through.
This way, Azure does most of the heavy lifting you would otherwise have to do yourself, even with managed kubernetes.
In a commercial environment I’d still use kubernetes. But maybe something like k3s or if we are in a cloud environment something like EKS.
Usually with time other services get added to the stack (elastic, grafana, argocd, …)