[rdsubhas]

I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API. There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API.

Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and a load balancer.

Before kubernetes, you had to automate by writing terraform scripts which mutate physical infrastructure as you apply.

With kubernetes, you POST a bunch of well-defined resources (container spec for the service, pod spec for the instance, pod as a VM, deployment as the group of VMs, services and ingress for traffic). Every physical cloud resource has a clear API mapping. Basically you save in kubernetes what you need as a first-class API resource. And then, kubernetes responds to what you saved by changing infrastructure to match.

You can do the same for practically any kind of infrastructure resources. Want an S3 bucket? Duh, POST a S3 bucket resource and you can write a controller to react and fulfil that bucket.

Kubernetes comes with a built-in set of functionality that fulfils a certain core set of infrastructure using containers. But you are not restricted to that. In theory, you could POST a VM as a resource, or an Instance Group as a resource, and you can write a kubernetes controller to fulfil those resources.

Why? Because APIs are more powerful than tools. APIs allow a different axis of infrastructure evolution, even if you distribute the control to everyone. By modeling these as APIs, you can bake in a huge amount of infrastructure intelligence into the API. Want to enforce different, code-driven resource-based policies, linting, sane defaults, organizational context? Yeah, make the controller do just that. If you just provide a tool to every engineering team, you basically lose any form of cross-cutting orchestration, and you lose the ability to evolve infrastructure in a separate axis independent of the tool that each team uses.

Basically, kubernetes is "Infrastructure as an API". Thinking about it as a "new application server" kinda hides the whole point of it.

[sciurus]

Before: Write HCL then run `terraform apply`

After: Write YAML then run `kubectl apply`

;-)

[moondev]

terraform has a kubernetes provider so you can still `terraform apply` ;-)

https://www.terraform.io/docs/providers/kubernetes/index.htm...

[blackadder]

Bingo, you've hit the nail :) This is what I love about K8S. In addition you've got the K8S reconciliation loop running constantly to make sure the system is in the state you described via the API.

[zeckalpha]

That’s not a benefit to me. Is it reproducible? Keeping desired state under version control is valuable.

[nojvek]

Yep. Super reproducible. Even more than the old ways. You can store the docker configs and store docker containers in registry. Store the yaml files, or auto generate them using build process based on other central DSL.

We could probably bootstrap our entire product from scratch in a couple of hours if it disappeared off the face of earth.

“Infrastucture as a config” is a very powerful concept. I’d say that’s what the big power of k8s is.

[dsmithatx]

The state is defined in yaml manifests file which are trivial to store in Git and create templates with in Ansible.

[halbritt]

Infrastructure as software vs infrastructure as code.