Kubernetes® is dominating in 2018. If you’re not already thinking about Kubernetes or at least containerization, then you’re behind. Fortunately, containers and cloud native architectures have never been more accessible or easier to get started with. From infrastructure providers like AWS and Azure offering their own versions of managed Kubernetes, to organizations like Cloud Foundry offering Kubernetes services, the world is shifting toward containers.

If you’re working inside of a regulated industry, like healthcare or finance, these tools may seem out of reach. The compliance requirements and security restrictions of HIPAA, HITRUST, GDPR, GxP, NIST, PCI, and more can seem like impossible hurdles to jump when it comes to adopting a platform like Kubernetes. This is exactly why Datica is shifting toward Kubernetes. Our customers are asking for it, it’s the future of managing workloads born in the cloud, and Datica is already the most robust solution for compliance management on the planet.

If you’re new to container orchestration and more familiar with a fully managed platform, like Heroku or Datica’s legacy product, Kubernetes can seem complex. The goal of this article is to compare Kubernetes with a traditional PaaS, discuss the differences, and examine the tradeoffs.

Now that the world has sufficiently been eaten by software, applications and tools have become ever larger and more complex.

What is a PaaS? A Platform as a Service, or a PaaS is intended to create a layer of abstraction on top of cloud service providers (or in some cases data centers and bare metal) so the end user can focus on deploying, managing, and scaling their applications and data. Without going into the history of the PaaS concept, it’s easy to think about it as a way of automating many of the repetitive, lower-level tasks of managing workloads on a server.

How a PaaS works The most well known PaaS providers are Heroku, Google App Engine, and Pivotal Cloud Foundry. These systems work when developers make minimal configuration changes to their application’s code and then simply “push” their code to the cloud. The PaaS will then make an attempt to understand the code, install the required dependencies, containerize the application, and then serve it up. These providers then have a UI layer for managing resources, networking, access, and more.

The benefits of a PaaS Being able to directly push your code to the cloud and have it running is a tremendous benefit over the old days of standing up a server, installing an operating system (and then patching it each time there’s a vulnerability), getting nginx configured properly, and much more. With a PaaS, developers can focus on delivering value via their product, not building IT infrastructure.

In addition to being able to simply push your code and have it running, many of these PaaS providers also couple database managed services as part of their Platform.

The pitfalls of a PaaS The ease of use for a PaaS comes at the cost of flexibility. Want to install custom software on an instance? Nope. Want to ssh into an instance to investigate an issue that isn’t appearing in the logs? Nope. Want to do anything beyond a simple Ruby, Python, or Node app? Good luck.

A PaaS serves a very specific purpose — to help small teams with simple applications run those in the cloud without the DevOps overhead of managing a fleet of instances on AWS or Azure.

The primary reason why so many PaaS providers have failed to make substantial headway in the enterprise space is because the model is so restrictive. For an organization managing hundreds of applications with petabytes of data, it makes more sense to build out a team that can manage all of it instead of making substantial changes to your business in order to fit a square peg into a round hole.

Enter Kubernetes and containers Now that the world has sufficiently been eaten by software, applications and tools have become ever larger and more complex. A small organization that just three years ago could have survived on Heroku is now growing at a pace that prohibits them from continuing to use a restrictive PaaS. Maybe they’re exploring machine learning or want a data warehouse. Whatever the case, they’ve outgrown the PaaS model. Now they need to move to something more flexible: Kubernetes.

Since the invention of containers, and specifically with the popularity of Docker, organizations have been figuring out easier ways to orchestrate containers — that is, how to get them running, connected and served up in the cloud. In a way, orchestration is the primary function of a PaaS. Because containers are relatively trivial to build (and in most cases the build process can be automated, ex: Gitkube) the focus in the container space has been on orchestration.

The benefits of containers The benefits of containers over virtual machines has been discussed to no end on the internet. I won’t go into detail here, but simply put — with containers, developers can port their applications from machine to machine whether that’s running it locally on a Mac, on a server in AWS or on a droplet on Digital Ocean. A container is a container and it can run anywhere. Compare this to the complexity of managing an entire fleet VM, each with its own OS. With containers there’s only one operating system to manage, even with hundreds of containers.

Why Kubernetes Kubernetes and containers have many of the same benefits. They can both run anywhere and they both function the same whether they’re running on AWS, Azure, GCP, or in the locked closet down the hall. Kubernetes is open source, financially backed by hundreds of organizations, and is managed by the Cloud Native Computing Foundation. In addition to being cross-cloud compatible and open source, Kubernetes has also shown tremendous growth in the last year.

If you’re coming from a PaaS you’ll no doubt have concerns around the ease of use and lack of automated DevOps support in Kubernetes. When I first explored Kubernetes in late 2014 I walked away feeling like it was too complicated and didn’t fit Datica’s customer use case. In 2018 it’s a different story.

Since Kubernetes officially hit 1.0 in 2015, the community and project have grown at a tremendous pace. What really makes Kubernetes a viable option is not the core project itself, but the community of tools and add-ons that surround it. Kubernetes isn’t a PaaS, it’s a foundation on which to build a PaaS.

Think of Kubernetes and the cloud native community as a set of building blocks. With these building blocks you can construct any number of different solutions. No longer are you held back or restricted by PaaS providers.

Which to choose The decision to choose Kubernetes over a PaaS (or vice versa) is going to depend on your business, technology, market, team, and several other factors. Having said that, even if you currently have a simple application with a relatively smaller user base, you’re likely going to scale and change rapidly. Preparing for the future by moving to containers now is going to save you time and money when it becomes critical later on.