Fundamentally, k8s isn’t a compute job scheduler—it’s an IaaS state converger, like Terraform, or AWS CloudFormation. As such, it needs to know how to model—and manipulate—the state of pretty much any IaaS resource you have. (And, unlike alternatives, it’s also extensible with custom convergible resource types, too.)
That doesn’t mean that k8s itself is all that complex. It just needs a lot of libraries for all the stuff you might do with it, where any given library will be dead code to 99% of people; and an architecture flexible enough to allow it to drive and track the state of those libraries.
I think Kubernetes-the-scheduler and Kubernetes-the-patterns-with-reified-examples have diverged and are going to continue diverging.
The latter is more of a microkernel for distributed control systems.
My hunch is that this means OAM may be dead letter in the long run. Abstract from Kubernetes-as-scheduler, fine and good. But Kubernetes-as-microkernel is close to doing that already. Whatever my gripes about the details, the mechanisms and affordances are consistent and predictable. That's very valuable.
Keeping different perspectives and roles in mind is important here.
I think the quotes in the article make very good points.
I've introduced Kubernetes at multiple companies , usually with good results.
But Kubernetes is a relatively low level runtime. It requires a lot of knowledge if you want to use it correctly, even with hosted Kubernetes offerings.
Application developers want to specify how the application works without having to learn a whole lot about Kubernetes internals. They also want the freedom to run something on different platforms without a lot of changes.
Think Elastic Beanstalk or Google App Engine, but provider independent. With the freedom to run it locally , maybe on a cheap self hosted cluster for dev deployments and on AWS for production. This is a lot of work right now, even with the hosted Kubernetes offerings.
Also enterprises often want to offload the decision making and rely both on common standard solutions and outside support if things happen. This is hard with k8s due to the flexibility of the platform.
I agree that it is too low level and too complex to provide a good company wide foundation on its own.
OAM could be a very valuable tool to have.
Also the points about Dapr resonant e. Building a complex event driven architecture with many services is what a lot of enterprises want , but it is really hard to do it well. There is a similar effort by IBM , but I don't remember the name right now.
I strongly agree with the vision of abstracting away the infrastructure details, having worked on, around or adjacent to Cloud Foundry over the past 5 years. These days I lurk on the fringes of Knative.
Cloud Foundry is my reference model for the power of clear, safe boundaries between roles. Good fences make good neighbours.
Right now I'm writing a book about Knative and one of my goals is to require zero prior Kubernetes experience or knowledge. It's turning out to be trickier than I'd first thought. I can't tell if that's genuinely because of the close adoption of idioms and patterns or whether it's just that I've spent a lot of time around Kubernetes for the past 2-ish years and can't faithfully recreate my original ignorance.
To put it really simply: there's not a lot to kubernetes internals that you should know. The abstractions in k8s are really, really good.
The problem is migration. Old apps don't handle k8s very well. An application that follows the k8s model should be really easy to deal with. It either is one of a bunch of figuratively identical apps, and you connect randomly, or it is part of a master/Replica group. Older applications need help with that, or expect multiple connections to the same host, or... Any number of anti-patterns.
(Databases excluded - the Borg version of Statefulsets operates very differently, significantly because the trade-off of speed/reliability of persistent storage sucks in the cloud world right now.)
That doesn’t mean that k8s itself is all that complex. It just needs a lot of libraries for all the stuff you might do with it, where any given library will be dead code to 99% of people; and an architecture flexible enough to allow it to drive and track the state of those libraries.