Before discussing whether or not Kubernetes (k8s) makes sense for your startup, we'll need a general understanding of what Kubernetes actually does. If you already know the basics, feel free to skip to the next section.
Understanding Kubernetes: what it is and isn't
At its core, Kubernetes is a container orchestrator. You provide a service to run as a container and k8s automatically schedules it to a cluster of machines. Typically, the cluster is an autoscaling set of VMs running in your own cloud (think EC2 instances if you're on AWS).
How you generate the container for an application you want to run is none of Kubernetes' business. You can use a Dockerfile, a buildpack (for common technologies like Node, Rails, Python, etc), or just point to a Git repo if you're using a PaaS like Porter. What's important is that Kubernetes takes the job of constantly scheduling, scaling, and restarting applications across multiple machines and abstracts everything into a single pool of compute for you.
Crucially, k8s by itself is not a platform as a service (PaaS) like Heroku or Google App Engine. Even managed Kubernetes services like AWS EKS, GKE, and DOKS are just container orchestrators that leave you with the responsibility of packaging your applications and deploying them with valid k8s-friendly configuration.
Think of it like a process scheduler for a distributed computer - you declare the task you want to run and let the OS assign resources and schedule things for execution. The reality is a fair bit more complicated, but for an initial working understanding of k8s, "a multi-machine container OS" isn't a bad start.
Benefits and drawbacks
Canonically, Kubernetes tends to be associated with vague notions of "scalability" - and for good reason. As far as managing containerized services at planet-scale goes, it's fair to say that Kubernetes is now The Industry Standard, with everyone from Spotify to OpenAI scaling applications on k8s across thousands of machines.
Of course, most startups won't ever need to achieve that level of scale, but increasing adoption among enterprises proxies the fact that for all intents and purposes, once you're on k8s you won't need to mature off.
Beyond high performance autoscaling, Kubernetes can also improve application resilience by automatically restarting or "self-healing" your workloads through built-in health checks. As an added benefit, unlike Amazon ECS, Google Cloud Run, and other proprietary alternatives, Kubernetes is fully open source. Whether or not you care to read the actual source code, this has resulted in a larger ecosystem of integrations, better documentation, and a more vendor-agnostic and portable runtime (not to mention a larger pool of DevOps talent to eventually hire from as a startup).
On the flip-side, most teams won't be able to comfortably move to Kubernetes unless they already have some internal k8s familiarity or have the help of an additional platform. As we've previously established, Kubernetes is not a complete PaaS the same way an engine is not a car. While this isn't a fault of Kubernetes itself, most high-velocity startups will need more to be automated on their behalf than just container orchestration.
This creates a need to introduce more tooling on top of k8s. How much more tooling? At the no- to low-DevOps end of things, a Kubernetes-based PaaS will aim to provide a Heroku-like experience on top of services like EKS, GKE, or DOKS with everything needed to manage and deploy applications under one roof. On the more DIY side of the spectrum, some teams opt to directly manage things from the outset with their own Terraform files and Argo CD pipelines, alongside a variety of custom integrations (for everything ranging from application CI to permissions and access management).
While a lot of this additional complexity comes down to internal priorities and individual design decisions, it's worth noting that a startup can quickly end up over-investing in DevOps if they're too eager to adopt a host of new tools while also moving to k8s.
So, should you use Kubernetes?
If you're just getting started and only need to deploy to a single server for the foreseeable future, Kubernetes is probably overkill. Likewise, some use cases with specific hardware requirements are still ill-suited for Kubernetes: GPU-enabled workloads for data science and machine learning can be challenging to configure with the virtualization inherent to a container orchestrator. While still possible, running these kinds of custom-hardware tasks on k8s probably isn't worth it for the average startup (especially in the absence of an infra specialist). For similar reasons, applications that inherently benefit from being as close to hardware as possible (say, for high-frequency trading) are also generally a poor fit for Kubernetes.
Otherwise, for most startups the calculus reduces to the following: is the added complexity of Kubernetes worth its performance benefits?
Half a decade ago, the answer for many earlier-stage (say Seed to Series A) companies was probably "no," especially in a broader market of competing services like AWS ECS, Google App Engine, Cloud Run, etc. This is largely because the "complexity" of Kubernetes was viewed as a constant. If you wanted to reap the benefits of k8s five years ago, you probably needed a DevOps engineer or at least a few people comfortable writing YAML to wrangle your cluster into the desired state.
The ecosystem has continued to evolve, however, and significant resources have gone towards lowering the barrier of entry to k8s for the average team of developers. Most self-hosted and even hosted PaaS offerings in the "Heroku alternative" category now use Kubernetes under the hood regardless. Teams with little to no Kubernetes knowledge are increasingly able to treat k8s purely as an implementation detail when deploying their applications.
At Porter, we've seen this empirically borne out time and time again with various YC and other high-growth startups. Seed and Series A/B companies migrating from fully managed services like Heroku are able to onboard onto a Kubernetes-powered PaaS without hiring DevOps. Particularly for teams that have already containerized their services, the burden of proof is increasingly falling on not deploying to Kubernetes when autoscaling performance and service reliability are important considerations.
Are you a startup looking to adopt Kubernetes with minimal overhead? Learn more about Porter today.
