Kubernetes or VPS: Which is better? My experience.

After several years of working with Kubernetes, I sometimes wonder if it is better to work with virtual machines instead. In this article, I'll share my experience and the advantages and disadvantages of each option.

When I started working as a software engineer, I trained in various areas: front-end, back-end, servers... what is known as a full stack software engineer. I was very interested in the world of deployments since it requires knowing how all the pieces of a system interact together. Coupled with my interest in optimization and performance, this led me to deeply understand how servers work, eventually specializing in DevOps.

Although DevOps is more of a philosophy, it has become a specific role in the industry over the years. I could say I have worked as a Platform Engineer / SRE / DevOps / SysOps / SysAdmin.

In the past, I remember working with manually managed virtual machines, using processes that utilized tools like Ansible, Docker, or simple Bash scripts: very simple but practical and functional processes.

Soon after, Docker and Kubernetes emerged. I experienced what it is like to maintain a Kubernetes cluster on-premise, facing numerous challenges and bugs (yes, Kubernetes also has bugs), and eventually migrating it to a cloud environment. Understanding Kubernetes in-depth involves comprehending the various layers of abstraction, configuring deployments correctly, and understanding its components. This requires studying, practicing, and time to experiment with real-world situations and problems, especially when managing 24/7 workloads that cannot fail.

After several years of using Kubernetes in my daily life, a couple of years ago, I started reflecting: Kubernetes is great, but isn’t a VPS much simpler and better? Who says it’s better or worse? So, I decided to venture back into managing environments with virtual machines to learn, draw conclusions, and share them with you.

Exploring VPS

Since I was young, I have created multiple side projects, deploying various products (some of which I will share here), always wondering about the best way to deploy them simply and cheaply. Today, there are multiple tools available for deploying your project, but in this article, I will simplify it to two: Kubernetes and a VPS.

You can also use serverless platforms, which are convenient as long as you stay within their path, though they come with considerable complexity and cost control issues. I prefer to avoid surprises, so I generally opt for other options, though I have used serverless for specific processes.

Wanting to return to simple (and cheap) but stable deployments, I decided to set up a series of VPS that are very economically accessible. Along with a series of scripts to deploy these projects, this approach has provided me with extensive experience outside the Docker/K8S environment, resulting in very stable deployments that require almost no maintenance.

After several years of experimenting with different options, I am very pleased with this exploration as it allows me to focus on what really matters while maintaining a good balance between productivity and cost.

In summary, you can have a very good and stable product running on VPS/on-premise/leased servers/your own rack hosted in a data center. Being outside the cloud gives you more profit margin, though you will need to compensate for it with knowledge or people who master and know what they are doing.

Kubernetes (or k8s)

I love Kubernetes, although I have had moments of frustration when facing bugs or problems that require a lot of time. Despite this, Kubernetes has many advantages: by using Docker or containers (virtualization), it allows you to have identical environments ensuring they work properly. It eliminates the phrase "it works on my machine" (though there are ways this can happen with Docker too).

The great thing about Kubernetes is that by knowing "just" one stack (a complex stack that requires study, understanding, and refinement), you can deploy and manage all types of workloads with a small team effortlessly (as long as you know what you’re doing, of course).

The downside is the associated complexity and cost. You either set it up in the cloud or have a team that can manage it. Ideally, you should use Terraform to configure it (which is fantastic once mastered). You need to understand how many parts work (storage, networks, compute) and then integrate this with the cloud provider (or on-premise, which is even more fun).

Kubernetes also requires managing other aspects like deployments, which then become templates (Helm or Kustomize), continuous integration (CI/CD), secret management, permission management, Docker image registries, etc.

Indeed, there are many things to know, but if this is your stack and you master it well, you can comfortably manage any workload and optimize costs to a minimum.

It's also true that deploying a small side project is not the same as deploying a product that generates revenue. Therefore, setting up such infrastructure could be seen as a return on investment. As I always say, it depends.

Conclusion: What Should I Use for Deployment?

It all depends on your needs. If you have a few projects and a relatively small team, managing your own servers might be a good option. On the other hand, if you have multiple projects and different teams that need to scale, Kubernetes can help standardize the stack within the department, allowing you to manage all projects comfortably with a single tool.

Clearly, there could be a difference if your product's needs require, for example, monitoring, where you can have Grafana, Prometheus, Elastic/Kibana (ELK), or if you need to maintain a data pipeline with Kafka, or other tools your company or department might need. It will also depend on your need to scale workloads dynamically.

If you have a single project and these aspects are not currently of interest, as I always say, start with the simplest option for you, likely Next.js and Vercel today.

In conclusion, deciding where to deploy your project is an important issue that you should dedicate some time to since this decision will accompany you for years. However, don't overthink it because if your project or company grows or if needs change, don't worry; you can and should migrate or adapt it to the new needs. It will only cost you some time, money, and opportunity cost, but if you don't have much technical debt, it won't be significant.

In my experience, this is a Type 2 (reversible) decision according to Jeff Bezos' framework, so dedicate some time to it, but don't worry too much if you make a mistake, as both options are good.

If you want to start with a low cost, it's best to use platforms like Vercel or a VPS. Kubernetes will be more expensive and requires knowledge of many parts, so you will need to train yourself or have a team to do it for you. You can always transition from one to the other, so as I said, don't spend too much time falling into analysis paralysis.