Despite the fact that I love working with Kubernetes, it is not for every company and every containerized workload. This is my first post from the series: "Container Orchestrators are not for everyone". Enjoy!
This is a short post in which I will try to encourage you to refrain from jumping immediately onto AKS or App Service Fabric if you just want to „deploy a couple of docker images”.
When not to use container orchestrator
When you have only a handful of services to orchestrate
There is no point of setting up Kubernetes or Service Fabric if you want to deploy few applications. Container orchestrators were made to run at scale. There are easier ways to deal with fewer number of applications, such as Google App Engine.
You don’t need A/B testing, canary releases, ring-based deployments
If those fancy words don’t ring a bell or you don’t plan to use those very advanced deployment methods, you probably don’t need a container orchestrator.
You don’t care about money
Container orchestrators are an efficient way to keep your infrastructure’s cost under control. Using Kubernetes wisely you can squeze out every penny out of your infrastructure. If this is something that is not a value to your company, you probably are better off with other hosting options.
Single exception
There is one exception in the container orchestrators world that might not fit the description above. It’s Nomad by Hashicorp. It’s complexity lies somewhere in the middle between simple managed services and full blown solutions, such as Kubernetes or Azure Service Fabric. I have to still discover it’s potential.
Conclusion
I hope I have shed some light on the reasons when it makes sense to use container orchestrators and when you should consider something else. Please bear in mind that this list does not exhaust the reasons for any of the choices. Also there are always exceptions to the rules above. Choose wisely.