7 ms·
I entered the tech industry with an ops role, which is why I had - from the perspective of most devs - a lot of experience with the kind of issues k8s solves.
by ffsm8 1y ago
I entered the tech industry with an ops role, which is why I had - from the perspective of most devs - a lot of experience with the kind of issues k8s solves.
In this context, your responses are very puzzling. I don't disagree with the core of your opinion - there are languages around that solve the issue of sourcing your language specific dependencies a lot better for it's ecosystem then docker ever could.
Some languages, such as erlang/elixir also come with highly advanced and stable clustering basically buildin, which solves running your own software on your own hardware in a distributed manner.
However, that's a completely different issue to what docker and k8s solves.
From devops centered enterprise: K8s basically replaced over provisioned hypervisors running countless VMs with running services in namespaces, no longer needing to over-commit RAM to multiple machines.
And Docker replaced the VMs we were building before that with OCI.
In a less advanced enterprise, OCI replaced the dreaded "patchday" update process with a unified deployment pipeline that simply rebuild the image every so often, giving you high confidence that the deployment will encounter less adhoc issues then youd have to solve before.
I'm saying this as from the perspective of a not particularly enthusiastic user of k8s.
I would suggest everyone to first just run single node with high availability fail over if necessary... But once you're signing SLA with high availability guarantees, deploying hundreds of services per day: doing anything but k8s is a bad idea. You're not doing that with the built-in tooling of e.g. Erlang/elixir either, because you're still missing all the other parts of your infrastructure.
- lmm 1y ago> You're not doing that with the built-in tooling of e.g. Erlang/elixir either, because you're still missing all the other parts of your infrastructure. If you're deploying on managed serverless infrastructure, you can; certainly you want to manage the other parts of the infrastructure and co-ordinate changes (with terraform or similar), but you do it all at a higher level than what K8s offers you. And if you're deploying on an internal cloud or bare metal, I still find K8s is the wrong abstraction level (at least if your language offers a better deployment model than Linux VMs); probably you want to draw a boundary more similar to what serverless infrastructure providers do, and maintain everything "below the line" as part of your infrastructure rather than your applications. Yes, that means you've got to manage patching your OS and language runtime and rolling out those updates in a safe way, but you'll always need to update the "platform" at some point - even on K8s you end up having to spin up new clusters and shuffle apps from one to another - and drawing the boundary between the platform and the application at the place where it was traditionally done fits with the grain of the tools much better most of the time.