For the majority, it just adds a little value when you compare to added complexity to infrastructure and the cost of a learning curve and the ongoing operation and maintenance.
For the majority, it just adds a little value when you compare to added complexity to infrastructure and the cost of a learning curve and the ongoing operation and maintenance.
What's the alternative? We spin up VMs, templated with AMIs, provisioned with an ASG? That works fine. But we want centralized logging. We want graceful restarts. We want automated rollbacks. The list goes on. These are not Google scale desires, these are "cost of doing business" asks for any cloud company. You can start building all of this on that core architecture of AMIs, or your cloud provider's equivalent, but all you're going to do re-invent what Kubernetes does, probably worse.
Kubernetes' problem isn't that it solves problems most companies don't have. The problem is that these problems most companies have could be solved in a simpler way than Kubernetes, because most companies have the exact same problems.
Actually most medium to large companies do have this problem.
There are often a lot of different languages, libraries, versions, deployment methods etc. And the appeal of Docker was that you can treat them all as block boxes. And the appeal of Kubernetes is that you have this rich support infrastructure to run them all hands-off at scale.
It definitely solves a problem. Just not particularly well.
Kubernetes "done right" is almost a part of your application. It becomes this "machine" that you throw stuff into and good stuff happens.
You'll need a team to integrate it into the pieces you require (auth, secrets, loadbalancers, permissions/app identities, monitoring and logging) but many places lack bits and pieces, and in my opinion k8s gives you a fast track to create a uniform application delivery platform.
What I don't like is that it kind of is the opposite of "the unix philosophy" and in that regard I prefer the hashicorp stack.
Places entrenched in manual processes for release and change management.
With true service delivery in a CI/CD fashion (including infrastructure, as it should be codified) many of these manual processes becomes obsolete.
Don’t get me wrong, the processes still exist, they are just sped up by a magnitude and automated.
The real problem with the K8s and devops world is no understanding of why there is no magic pill in 'codifying' a bad system.
Modern SA is about knowing that your job to help bring business value. Most of the time this is down to automation.
The amount of people heating office spaces at your non-tech large enterprise is astounding in my opinion.
I enjoy discussing the reasons for this, but it’s a lenghty one!
In super-short: lack of competency, meaning IT support and tools are not used even remotely optimal. This lack of competency, which starts at the top, results in laughable lead times for the simplest of tasks and processes. This in turn has resulted in mass outsourcing and off-shoring of a bunch of tasks (processes) that really should have been automated years ago.
Usually the incentive to improve this is 0 with these ”service providers” and things detoriate even further.
The sad state of affairs is that many believe this is the way ”IT” works — slow and error prone.
Awesome example: one place, one of the 500s, built an on-prem ”cloud” within a business unit. Over 2000 physical xen hosts. I wanted them to apply a patch. They refused. The last patch had taken 6 months to roll out. The process was: ssh to server, scp patch, run sudo install patch. The entire operation was bought by a renowned ”service provider”. Ouch.
I could talk about this for weeks! Of course there are those that manage an awesome shop, but my experience is that this is usually isolated teams that are somewhat shielded from the crazyness of big money politics.
I personally believe a society built on and around services in the end need either massive amounts of bullshit jobs or basic income of some sort.
Probably because it started at Google, if it was created by IBM then we'd only hear about it on TV ads.
They run a self-hosted OpenShift cluster, which is managed internally by a team of 4. Not only makes this situation it a lot easier to spin up new environments, it also forces devs to include the ops team from the start for stuff they don't know, and corrections can be made early on.