Why not to choose Kubernetes
We’re using Kubernetes to avoid vendor lock-in.
We want our workloads to be portable that’s why we’re using Kubernetes.
We don’t use serverless functions to avoid vendor lock-in
I’ve heard this a lot and I disagree!
Let me explain.
What does portability mean?
Portability is the ability to move an application from running on one platform to run on another platform. I think we can agree on that. Kind of a hidden side to this is that integrations to other systems need to be working still.
Portability should therefore be measured in how easily this porting can be achieved. This could be measured in terms of cost, effort and time.
Let’s look at two simple examples before looking at Kubernetes.
- Monolith (single vm, no integrations)
- File share
Monolith
In order to migrate monolith on a VM we can use backup/restore methods, e.g. by creating an image. No commercial tools needed. Only cloud charges like data transfer. Not very complex or time consuming.
Cost: low, effort: low, time: low
Portability: great
File share
In order to migrate a file share we potentially have to migrate hundreds of terabytes. Let’s say that it shouldn’t take forever and we start multiple synchronisation jobs on other hardware, in order to keep the file share up and running. No commercial tools needed. Cloud charges for data transfer and extra hardware for sync jobs. The complexity is not very high.
Cost: medium, effort: low, time: high
Portability: medium
How portable is Kubernetes?
When we want to migrate Kubernetes there are two parts to look at and consider. First, we need to make sure to have a running Kubernetes Cluster elsewhere. Second, we need to migrate the workload that’s running in Kubernetes.
A running Kubernetes Cluster elsewhere doesn’t necessarily mean that the application we run within Kubernetes will run and perform the same on both clusters.
Let’s look at the first part: running Kubernetes. In order to run Kubernetes we need both the control plane and the worker nodes.
In the public cloud we at least get a managed control plane, if not you’d have to manage and run Etcd, Kube-apiserver, Kube-controller-manager and Kube-scheduler yourself. That alone would take a lot of effort and time simply because of the complexity of having to learn how to run, manage and update those components.
We used to have to manage worker nodes ourselves in the public cloud, but nowadays there are options to have to providers run them for us.
A “naked” Kubernetes implementation is not enough to run any services. One other thing we have to do is configure integrations for networking, authentication and more for ingress control and to connect to other services on the platform like databases.
The second part is more straight forward. As long as our application is completely run in Kubernetes (no external databases, Block storage, Secrets, KMS, Messaging Systems, Queues etc.) our Pods and Services should run on both platforms without changes required to deployments.
Now that stateful applications are properly supported in Kubernetes, I will consider this a valid option, although I would think that most applications will have external dependencies.
Keeping everything I mentioned in mind, let’s look at cost, effort and time. Cost wise we have to have a running cluster before we can port any workload. For actual migrations we could simply create new images for stateless containers and only synchronise stateful data like databases. As for efforts we have to consider the required knowledge for both running Kubernetes and running applications in Kubernetes. Time should also not be underestimated because each cloud platform has unique ways and caveats to get Kubernetes to run properly.
Cost: medium, Effort: high, Time: high
Portability: not good
How portable are serverless solutions?
All major clouds offer solutions to run serverless functions and serverless containers. Due to the level of abstractions these services operate at, the configuration is minimal.
In a very simplistic approach one could say, that serverless solutions are very portable. You will have to change some of your config code, however that’s likely going to be much simpler and faster than getting a whole Kubernetes setup running elsewhere.
However, this is not realistic. You can’t and won’t run stateful applications in serverless functions or serverless containers. You will have to use other products and this is where the unpredictability of portability comes in. One thing to note is that the major cloud providers all offer similar solutions for the majority of services. This would mean that we’d have to change configuration, change libraries and some implementation to use the new libraries in our code.
In terms of cost, this would probably be low, as we most likely don’t need a running environment. Effort and time would potentially be similar or higher than for Kubernetes.
Cost: low, Effort: high-very high, Time: high-very high
Portability: not good
Kubernetes is not as portable as one might think. Numbers would be great to make these ratings more tangible, however this is a blog post and not a scientific paper, so “low”, “high” and “not good” will have to do ;-)
So, portability is not a great reason to choose Kubernetes. Then what is?
A typical answer would be scalability, automation, reliability. However, these attributes are also true for serverless services.
Compared to serverless services,
I think that Kubernetes stands out with its support for open-source frameworks and products.
If you want to embrace the world of running things yourself (in Kubernetes), you open yourself up to way more options for products than any cloud provider can offer and even for the products they do offer, you have more options to configure these products to your liking.
