Recently kubernetes became a trending subject on our IT market. everyone seems to be migrating to kubernetes. it seems that people think their awesome project is doomed to fail, without using this shiny new tool. but there is a high chance that you don’t need it.

Why you might not need kubernetes

You don’t have anyone to work on it

Depending on the size of your service it might take a long time to migrate it into a kubernetes cluster. It’s not a one night job, It’s filled with try and errors (more time spent on fixing and finding unknown issues than deploying things) and it adds a new layer of complexity to your stack.

So if you don’t have someone dedicated to this task or there is a time limit you might need to think about some old school deployment processes.

Your are not using cloud provided kubernetes

If you are on a bare metal environment you need to deploy the whole kubernetes stack and keep it running. this stack needs some hardware resource for running and you need someone to solve issues on the stack itself. And did I mention anything about adding a new layer of complexity to your stack?

Note that one the benefits of using a cloud provided kubernetes is you can simply add nodes to your cluster and remove it later using some kind of API (for example in nights you add 3 nodes to your cluster and then remove them in mornings, and only pay for the time those server were running.)

And there are some question you need to answer on your cluster like how can I manage and view logs? How can I debug a running service? How can I monitor workers? Where should I store files? and other questions like these, that you need find solutions, deploy and manage them yourself.

You have a few nodes

You are managing a few servers (like 3 or less) and you are in a bare metal environment and you love to make your life hard for no good reason.

You have simple stack

You have a postgresql database with a redis and one or two web worker. please do not add a new layer of complexity to your project.

You are not planning to scale your service soon

But what if I want to scale someday?

Yeah, maybe. But what is your main problem? Did you even release your service yet? do you even have a minimum user base to add the second server?

Conclusion

In short if you have a small web service and you are on bare meta environment, you can ignore the hype train and stick to simpler tools for deploying and running your service. Here is a short list of some alternatives:

• Docker Swarm: If you still want orchestration then swarm can be a good choice. It’s simpler, lighter and built into docker. Learning curve is small and swarm works with docker-compose files.
• Docker Compose: You can simply deploy your project with a simple docker-compose.yml file. docker itself doesn’t support HA but it gets the job done. If you have a single node service It can be a good choice. Also consider compose for deploying third party services like wiki, blog, issue tracker and …
• Ansible/Shell Script: If you still manually deploy your service, you can start with writing some small scripts or ansible files to make your life easier. You also can combine shell script/ansible with compose and swarm to get better results from them. Note that you might not need to make huge changes to your project, writing a simple deploy.sh file may be good enough for your team.

Update 2019-03-02: Check kubernetes-failure-stories