However, a lot of new (or just bad) devs miss the whole Keep It Simple Stupid concept and think that they NEED Kubernetes-shaped solutions in order to "do it the right way".
Many times three web servers and a load balancer are exactly what you need.
However, a lot of new (or just bad) devs miss the whole Keep It Simple Stupid concept and think that they NEED Kubernetes-shaped solutions in order to "do it the right way".
Many times three web servers and a load balancer are exactly what you need.
Suddenly you have gone from 3 instances to 20.
All of that is irrelevant to my main point though. It's never one size fits all and then all your problems are solved.
You are far better off actually assessing your needs and picking the right solution instead of relying on solutions that "worked for bigger companies so they'll work for me" without really giving it a lot of thought if you need to go that far.
They often have their own databases, search engines, services etc to deploy along with it. And necessitate multiple instances for scalability and redundancy.
That's what containers are. Containers are applications, packaged to be easily deployable and ran as contained processes. That's it.
Kubernetes is just a tool to run containers in a cluster of COTS hardware/VMs.
I've said it once and will say it again: the testament of Kubernetes is simplify so much the problem of deploying and managing applications in clusters of heterogeneous hardware communicating through software-defined networks thay it enable clueless people to form mental models of how the system operates that are so simple that they actually believe the problem is trivial to solve.
It all depends on the situation and needs of whatever problem you are trying to solve.
May be, just may be, they want k8s not to create value but to develop/enrich resumes - in order to signal that they are smart and can do complex stuff.