Containers are not just for Kubernetes
In the last few years, the word Container (and maybe even Docker) has become somewhat synonymous with Kubernetes. This was of course unintentional — Kubernetes has attained the kind of mindshare very few technology trends in recent times have. This write-up is not to criticize Kubernetes, which I think is a brilliant technology. Instead, I want to make an argument that containers can do so much more even without Kubernetes.
Why Docker?
Let us think about the problems that Docker was created to solve:
1) Remove all the dependency nightmares that cause production environments to be invariably different from development environments.
2) Efficiency of packaging and deployment — both in terms of size and time
3) Improved developer productivity — especially the inner loop of Edit -> Build -> Debug
All excellent goals to achieve, and largely accomplished.
What went wrong?
Along came the Kubernetes wave. It wasn’t meant to solve any of the above problems. It was supposed to provide efficient utilization of compute resources while improving reliability and availability. So, both containers and Kubernetes serve different purposes. And let us accept it, Kubernetes is still complex.
Unfortunately, somehow the concept of Kubernetes and containers got attached to each other. As a result, for many developers, the mental bar for using containers went higher because they thought they need to learn Kubernetes just to use containers.
How is cloud PaaS helping?
That notion is slowly disappearing now, thanks in large part to all the public cloud providers who are now beginning to provide container support in many contexts that don’t require a user to directly use Kubernetes. In fact, now that many Platform-as-a-Service (PaaS) products support bring-your-own-container-image, the whole idea of PaaS is now able to shed its image of being a super restrictive environment that can handle only basic scenarios through bring-your-code mechanism. You can pretty much package anything in your container image. If this container works on your machine, chances are it will work just fine on the cloud PaaS environment.
At DigitalOcean, we have recently announced bring your own container image support for our PaaS product — App Platform. App Platform actually runs on Kubernetes and is entirely based on containers. Even before this feature was announced, it supported building container images using Dockerfile (in addition to regular code and framework based mechanism). Ability to bring pre-built container images provides even more flexibility.
Sometime ago, Google Cloud had introduced their Cloud Run product which is their serverless container platform, primarily optimized for container based workflows. They did this despite the fact that they already had an event-driven serverless compute product (Cloud Functions) but that was mostly for code-based workflows.
AWS, for the longest time, tried to keep the concept of PaaS (Lambda in their case) different from the concept of containers. Their managed Kubernetes service obviously supported containers but they resisted for a long time, adding container support to Lambda. That changed last year when they finally announced that Lambda is going to support containers in addition to code.
In my previous write-up on the topic of PaaS, I had made a simplifying assumption that serverless is just a variant of PaaS. As you can see, I am continuing with that assumption here as well:
If we combine the benefits of Docker we earlier discussed with the benefits of fully managed PaaS (as described in the above linked article), we will soon realize that Docker and containers may actually be a better fit (for most developers and use cases) with PaaS environments rather than with Kubernetes.