By
Janis Leuenberger
Janis Leuenberger
/01.03.23

Photo by Taylor Vick

At Renuo we build high quality web applications. Though we strive for simplicity, the deployment of our software isn’t straight forward. At the bare minimum one of our projects includes a web server, a database, a job queue and a file storage solution. Luckily we have been able to optimise the setup and maintenance of our basic infrastructure stack to a high degree. Sometimes however an application requires a more complex deployment. This is where Kubernetes may come in.

What is Kubernetes?

Kubernetes is an open-source solution to manage infrastructure. It was created by Google to govern their servers in a convenient way. Since the initial release in 2014 it has matured a lot and seen great adoption in the industry. The main selling point of Kubernetes is the ability to scale your application nearly infinitely without additional overhead. And it offers plenty more:

  • Automated deployments: To release a new version of an application, running processes have to be restarted. To avoid downtime, Kubernetes can run multiple versions of the application in parallel and move the load slowly from «old» to «new». During this, the application health is monitored and if anything goes wrong, the release is automatically rolled back.

  • Horizontal scaling: Kubernetes allows you to increase or decrease compute capacity at a moment's notice. It is also possible to scale automatically based on usage.

  • Self healing: Kubernetes monitors the health of the application not only whilst releasing but also during ordinary execution. If there are timeouts, crashes or other malfunctions, misbehaving parts will be restarted automatically.

Infrastructure as code

Kubernetes is built on the idea of «Infrastructure as Code» whereby the infrastructure is defined using configuration files. This is in contrast to using the GUI of popular hosting providers or self-managing a server using the command line. Infrastructure as Code has been very popular recently and for good reason: Changes to the infrastructure are version controlled. Preserving the history as well as improving quality by requiring the same approval/quality assurance process as the rest of the application. Catching mistakes before they happen.

Merge request from gitlab displaying the different quality assurance and documentation processes an infrastructure change has to go trough before deployment.

Alternatives

Our go-to hosting provider for most use-cases is Heroku. It allows us to run a project with very little effort. Other popular providers include AWS and render. Both of which we have used at Renuo before. dokku is an open-source competitor in the hosting space. It is placed somewhere in between Kubernetes and Heroku on the complexity scale whilst being self-hosted.

Comparison of the most popular hosting solutions based on their complexity.

If we take a deeper look at Heroku and Kubernetes, we can see that they couldn’t be more different. Heroku maintains the servers for you whilst you are responsible yourself when it comes to Kubernetes. On the other hand Heroku is one of the most expensive hosting providers. Using Kubernetes the configuration is written in yaml whilst Heroku relies on a graphical user interface.

Adding a redis database in Herkou as well as Kubernetes. Heroku is simpler whilst Kubernetes offers a lot more flexibility.

Conclusion

There are a lot of good options to manage infrastructure. As always it’s important to choose the correct tool for the project. If the complexity and scale is very manageable, the most cost effective solution is often a fully managed hosting provider like Heroku. Kubernetes however should be considered when working with infrastructure exceeding this simplicity.