5 ms·
Ok, let’s agree that K8s is overkill. What commodity tool should I be replacing it with that gives me: * super for heterogenous workloads (web servers, big ba
by FridgeSeal 4y ago
Ok, let’s agree that K8s is overkill.
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.
- x86x87 4y agoHow did people ever manage to do anything before k8s? 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.
- FridgeSeal 4y ago> How did people ever manage to do anything before k8s? 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.
- x86x87 4y ago> 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. 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?