I wouldn't call it a misperception. It does orchestration, service discovery, resilience, secrets management (which is a joke, but still) and whatnot. That's definitely a lot of complexity. Mixing it all together…
Once you get to a place where you need to run really-really huge workloads, like thousands or tens of thousands of machines, kubernetes, hosted or not, will take the will to live away from you. It's not about the…
I wouldn't consider any of these for production.
May be. But operators are a relative pain to develop. I prefer the HCL approach. You can have modules instead of operators, and while HCL overall might be painful, it's less painful, IMO, than constantly changing…
You may not use it for automation. But you usually do much exploratory work before doing the automation. That's where the various CLIs for all kinds of things come in really handy.
We had to add vault to our setup even if we use kubernetes - kubernetes secrets are a joke. We don't use consul, but managing istio, or any other service mesh, on top of kubernetes, isn't any simpler than running your…
You got that sub-1000 boxen wrong. Nomad is usually employed where the infrastructure is huge. IMO, K8s is driven by hype and marketing, not by technical merit. Your enumeration of the managed things is very particular,…
K8s is complicated because it does many things, not because each of the things it does, individually, is complicated. If your orchestrator only runs stuff, if your service discovery is independent of the orchestrator,…
In reality, this is always an illusion, IME. You always have to deal with the platform yourself. You can hire a team to do this dealing with you, but that's not cost effective.
Having a rollback feature at the orchestrator level is useful when you want the rollback to be fast. Sometimes that's critical - when you deploy something buggy in production. One reason I'd prefer to use Nomad over K8s…
I wouldn't call it a misperception. It does orchestration, service discovery, resilience, secrets management (which is a joke, but still) and whatnot. That's definitely a lot of complexity. Mixing it all together…
Once you get to a place where you need to run really-really huge workloads, like thousands or tens of thousands of machines, kubernetes, hosted or not, will take the will to live away from you. It's not about the…
I wouldn't consider any of these for production.
May be. But operators are a relative pain to develop. I prefer the HCL approach. You can have modules instead of operators, and while HCL overall might be painful, it's less painful, IMO, than constantly changing…
You may not use it for automation. But you usually do much exploratory work before doing the automation. That's where the various CLIs for all kinds of things come in really handy.
We had to add vault to our setup even if we use kubernetes - kubernetes secrets are a joke. We don't use consul, but managing istio, or any other service mesh, on top of kubernetes, isn't any simpler than running your…
You got that sub-1000 boxen wrong. Nomad is usually employed where the infrastructure is huge. IMO, K8s is driven by hype and marketing, not by technical merit. Your enumeration of the managed things is very particular,…
K8s is complicated because it does many things, not because each of the things it does, individually, is complicated. If your orchestrator only runs stuff, if your service discovery is independent of the orchestrator,…
In reality, this is always an illusion, IME. You always have to deal with the platform yourself. You can hire a team to do this dealing with you, but that's not cost effective.
Having a rollback feature at the orchestrator level is useful when you want the rollback to be fast. Sometimes that's critical - when you deploy something buggy in production. One reason I'd prefer to use Nomad over K8s…