3 ms·

I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and cluste

I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and clustering. They don't need to go hand in hand. Containers without orchestration has been proven to save money. It's hard at the moment to prove the real value of k8s. It's too early and there isn't enough adoption. When you look at most success cases of k8s they often can achieve the same benefits using an plain old docker and some auto scaling groups.

jrs95 8y ago
Makes sense. I suppose in my case it’s ease of service to service communication + deployment that’s the primary benefit. Consul could easily handle the first, but deployment could be a bit trickier. Ultimately I think if GKE didn’t exist I very likely would have ended up using Nomad and Consul for simplicity’s sake. To me it seems some sort of scheduler is necessary if you want to have an easy way to control the horizontal scalability and availability of your individual containers and not just your hosts. Unfortunately setting that up isn’t nearly as well documented as setting up a k8s cluster right now, but IMO the end result is a lot easier to comprehend. The lack of end to end documentation is really what kept me away from adopting Hashicorp’s tools instead, so hopefully that will improve and k8s can have some real competition. All of this is in the context of a microservices architecture, though. Something I generally wouldn’t choose to do unless there were good reasons for it. Defaulting to a monolith is still the safer choice IMO, and if you are deploying existing monoliths, or a small number of services, then it’s very possible that you don’t have a need for an orchestrator at all.