I would have agreed with you three years ago, but today there's a ton of surprisingly good off the shelf solutions, you can get very, very far in a brief amount of time with a single engineer. A ton of the functionality exposed by Kubernetes is absolutely necessary at any scale and very difficult to do yourself. "Don't let any process on this host talk to this port except these ones" is something that is so much easier in K8s than anything else I've ever encountered.

My point was that unless you’re running on metal, the cloud people built all this shit, and much, much better than k8s (or Tupperware for that matter).

They’ll stick you Docker container inside a VM happily because people pay them to do it, but it’s redundant.

Google didn’t OSS Tensorflow out of the goodness of their hearts, they did it to sell TPU hours on GCP.

k8s is likewise not charitable giving: it’s to sell managed Kubernetes on GCP, and subtle nudges to get people to make it their careers are uh, just business I guess.

Provisioning as code is in a sad state: Chef/Ansible/Salt/friends can’t deliver on idempotency, Nix is too complicated for most. So people use a container primitive (Docker) to work around that.

This has nothing, absolutely nothing, to do with service discover and failover and auto-grow and other Kube shit.

AWS does all that already. Better.

This is a borderline-cynical business strategy on the part of the cloud providers, and judging from the religious fervor around k8s (someone upthread has it in their username for Christ’s sake), it’s working.

This rings true every time I see someone talking about K8s. Companies just want something that is customizable to their workflow, they don't want a ready-made PaaS offering. Google's play was to provide an industry standard API interface that is available everywhere (which is essentially what Kubernetes is). Now that the control plane for compute is commoditized, GCP et al can sell complements - BigQuery, TensorFlow, GCS etc.

I think Anthos-like solutions are the future. Just buy the cheapest hardware from your local Datacentre or BareMetal providers like Hetzner and run GCP, AWS or some other flavor of software on top of it. This is also where Teleco Clouds are moving with OpenRAN and 5G, they are tired of being locked-in to full stack vendors like Nokia and Ericsson and want interchangeable solutions compatible through a common interface

Well done sir or madame.

It's a powerful abstraction and it's very liberating.

I understand the cynicism, don't get me wrong, but that doesn't mean it's all bad. It definitely feels like a net positive to society even if at times it's unbearable.

Somewhere between "I'm small enough that all of the cloud providers are about the same" and "I'm big enough that I can leverage them against each other to get a better deal, but still small enough to not be on metal" there is maybe a sweet spot where I really do need to be mobile across providers in a push-button way. People in e.g. blockchain use k8s to good effect because they want to run a big distributed system with loose-ish central organization, and that's a real thing. It's also a niche.

I never said Kubernetes was useless full stop. I said that places where it's the right call are niche.

My current gig is humble, a usually-raman-profitable type garage band, we're like 5 engineers with Ethernet cables in our living rooms and a bigger AWS bill than feels fair, and if I proposed to any of the ex-FAANG type people involved that we should get serious about Kubernetes they'd laugh themselves pink in the face and resume typing. We can give our machines names and remember them all, there are a few dozen of them, but that's still "pets".

If we're fortunate and hard-working enough to need 1k machines, I'll spin up a ZK instance or something and write a little Nix/bash.

I won't be networking at KubeCon 2023 unless I lose a bet to one of my peers. I've got work to do.

I do entirely agree with you, I think: there are too many companies using Kubernetes prematurely, but...

It's kind of turned out okay? Because of this, the ecosystem seems to be improving and it's easier than ever for small shops to get started. And selling software that targets Kubernetes is leagues better than targeting Ubuntu or Red Hat or specific kernels.

> I'll spin up a ZK instance

If I never have to run another ZooKeeper instance again I'll die happy.

One of the scenarios I’ve seen Kubernetes replace is something like tying together Packer, Chef, Jenkins, Terraform, And Vault to get an EC2 instance propped up, but that’s just to deploy the code.

What was particularly annoying to me was that the developers were already using containers to build their code and another container for unit testing. So switching to Kubernetes would’ve been far easier. I had to go in and deconstruct the work they were doing with containers to then get their app deployed to an EC2 instance.

Although at this level you’re still not saving a ton by going the Kubernetes route. You get a ton of benefits with it, though. Even just tiny things like being able to get the config from a deployment using kubectl is so good. And then you can modify it, too! That’s been super helpful for troubleshooting.

I'm going to try single-shot learning on one of the newer language models with "I can confirm your viewpoint. I'm single engineer building self-managed k8s for my company." because that remark, reasonable or not, so neatly encapsulates the current zeitgeist.

If you're trolling, respect. And if you're not, my 2c: flash an AMI and work on your product.

It's not the machines. It's the comosible components, the service building blocks I can get with an API call.

* Want traffic into a cluster, ask for an Ingress. * Want to auto-scale? Ask for a HorizontalPodAutoscaler. * Want to manage CPU and memory rather than number of containers? VerticalPodAutoscaler. * Want to point your monitoring system at a port? PodMonitor or ServiceMonitor

And of course, you can extend on the basic plugins. Want a bunch of databases? Maybe install the Vitess operator and simply make an API call to create an instance of VitessCluster. There are a dozen options, depending on what flavor of database you want.

Oh, and you don't need a sysadmin/SRE to do all this for you. You can be granted rights to a Namespace and compose everything you need in your namespace.

What commodity tool should I be replacing it with that gives me:

* super for heterogenous workloads (web servers, big batch loads, streaming workloads)

* autoscaling the workloads

* autoscaling the cluster

* auto-restarting workloads

* basically automatic networking

* the ability to have all that without the need to setup separate infrastructure, and to have the orchestrator move workloads around to optimise machine use

* the ability to hire people with experience in it already

* ability to run stateful workloads, and have disks managed and moved for you

* the ability to do all that by just providing a config

* the ability to do all that without having to let people have actual access to the machines/OS

* per container/workload topology constraints and requirements, that are network and data centre aware, without having to write any code

* have access to a wide range of tooling and docs

* be able to drop in workloads that automatically handle log collection, etc. without needing to configure each deployment.

* ability to swap out Network ingress/reverse proxy without having to redeploy or reconfigure your applications.

* ability to drop in any number of tools to do traffic shadowing, mirroring, splits, etc without reconfiguring or redeploying your applications

* ability to do all this without your devs needing to be networking experts.

* not locked to a specific cloud provider

I’m sure there’s tools out there that cover different subsets of those features, there’s probably tools that do all of them and more. K8s isn’t perfect, but it gives you an awful lot for some reasonable tradeoffs. Sure, if you’re deploying a single web-server/app, you shouldn’t bother with all this; and data centre level stuff probably has tools that make these features look like a cute picnic, but many devs I’ve worked with haven’t the capacity, ability or desire to figure that out.

> If you’re on a cloud provider? You’ve already got secure, restartable, restorable, on-demand-growable, discoverable, fail-over-able, imaginary machines a zillion times more robust

Sure, but you’ve still got to figure out how you want to setup, monitor, configure all of that, then stitch it together and maintain it, and also not get in the way of your main application development. To me, that’s what K8s gives me: I rely on the cloud provider to give me good machines, good networking, good storage primitives, and to heal/replace them when they fail, and K8s gives me a way to use all of that nicely, without needing to build and maintain it myself, and without my applications needing to know everything.

I'm going to make the claim that a load balancer + asg + basic networking setup is all you need in 95% of cases.

Learning how to package services and have them run anywhere? A lost art.

Cloud agnosticism is a red herring. No matter what you do today you are not cloud agnostic.

Nobody ever said it wasn’t possible. Nobody is saying “you can’t run things the way you want”, the argument is “you keep saying K8s is bad, here’s some reasons why it’s maybe not”.

> I'm going to make the claim that a load balancer + asg + basic networking setup is all you need in 95% of cases.

If you can make it support the autoscaling Spark jobs, the jupyter-hub env the analysts use, and all our GRPC API’s, and have everything mTLS’d together, and have all of DNS+cert + routing magic with similar setup and maintenance effort, I’ll convert.

> Learning how to package services and have them run anywhere? A lost art.

The issue isn’t my teams code-if we were only running our own stuff, and we only used a single language, packaging would likely be straightforward. But it’s the fact that we run several other applications, of varying degrees of “packaged” and the fact that I can barely get the Python devs to use a virtualenv properly that makes this statement a bit too unreasonable in my experience. Containers may be messy, but at least I can run 3 different spark pipelines and 4 Python applications without needing to dig into the specifics of “how this particular app packages it’s dependencies” because that’s always an awful experience.

Let's define what you're talking about here and I can show you the way.

What is the difficulty in autoscalling Spark jobs? What jupyter env do they use? You say grpc api. That's genericm what do those services really do? Sync request/response backed by a db? Async processing? What infra do they need to "work"

Where are you running your workloads? Cloud? Which one?

I mean, running spark is an awful experience at the best of times, but let’s just go from there.

Spark drivers pull messages off Kafka, and scale executors up or down dynamically based off how much load/messages they have coming through. This means you need stable host names, ideally without manual intervention. The drivers and the executors should also use workload-specific roles - we use IRSA for this, and it works quite nicely. Multiple spark clusters will need to run, be oblivious to each other, and shouldn’t “tread on each other” so the provisioning topology should avoid scheduling containers from the same job (or competing jobs) onto the same node. Similarly, a given cluster should ideally be within an AZ to minimise latency, doesn’t matter which one, but it shouldn’t be hardcoded, because the scheduler (I.e. K8s) should be able to choose based on available compute. Some of the jobs load models, so they need an EBS attached as scratch space.

> What jupyter env do they use?

We use jupyterhub wired up to our identity provider. So an analyst logs on, a pod is scheduled somewhere in the cluster with available compute, and their unique EBS volume is automounted. If they go to lunch, or idle, state is saved, and the pod is scaled down and the EBS volume is auto-unattached.

> That's genericm what do those services really do? Sync request/response backed by a db? Async processing? What infra do they need to "work"

The API stuff is by far the easiest. Request response, backed by DB’s, the odd analytics tool and monitoring tool as well. Servers themselves autoscale horizontally, some of them use other services hosted within the same cluster, all east-west traffic within the cluster is secured with mTLS via linkerd, between that and our automatic metric collection, we get automatic collection of metrics, latencies, etc. like what you get with the AWS dashboards, but more detail (memory usage for one), automatic log collection too.

> Where are you running your workloads?

AWS, but minimal contact - S3 is basically a commodity API nowadays, the only tight integration is IRSA, which I believe GCP has a very similar version of. So most of this should work in any of the other clouds, with minimal alteration.

a lot of scripts crammed together that could be broken by any single dev

Have you ever done IaC where the whole copy of the infra came up on deployment and traffic was shifted between old and new? And developers could spin up their own stack with one Cloudformation or Terraform command? Have you used cloud primitives that solve most of the problems you are reinventing with k8s?

By the way, Terraform and k8s are not exclusive, I use them together.

I can tell you how we managed to do anything.

We had few servers. They run docker-composes scattered all over people's home directories.

We had one nginx entrypoint. It's forbidden to restart it at work hours because it won't restart and there will be hours outage. You expected to restart it at weekend and then spend hours trying to start it.

Some docker images are built locally.

Backups are basically not worked before I came to this company. It was the first thing I fixed. Now we can restore our system if server dies. It'll take a week or two.

Kubernetes is going to be sane exit.

Yes, I know that it's possible to build sane environment. Problem is people don't bother to do that. They build it in the worse possible way. And with kubernetes, worst possible way is much better because kubernetes provides plenty of quality moving blocks which you don't need to reinvent. You don't need to reinvent nginx ingress with all the necessary scripts to regenerate its config, because you've got ingress-nginx. You don't need to invent certbot integration because you've got cert-manager (which is my personal favourite piece of k8s). You don't need to invent your docker-composes storage conventions, user permissions (777 everywhere, right), because k8s got you covered. All you need is to learn its conventions and follow them.

AWS.