There is a bit of confusion in the platform space today as it relates to Kubernetes (k8s). Many refer to k8s as a PaaS, but according to Kubernetes’ (K8s) own documentation, “Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system.” We don’t view that as a bad thing, though, just an important nuance. As Kelsey Hightower said, “Kubernetes is for people building platforms. If you are a developer building your own platform (AppEngine, Cloud Foundry, or Heroku clone), then Kubernetes is for you.” These PaaS (Platform-as-a-Service) offerings allow organizations to deploy cloud-native applications to their infrastructure whether that’s provided by a cloud service provider (CSP) such as Amazon or Google, or a self-owned on-premises infrastructure. But in the enterprise, not everything is a cloud-native app and these do not have to be competing options. In fact, k8s has made it easier than ever to have an opinionated PaaS and a highly flexible container environment running side by side. At Rise8, our approach rejects technology for technology’s sake–every technology choice is driven by our processes, and our processes are driven by our mission-oriented culture. This article will help outline the pros and cons of each based on your specific needs and capabilities.
Kubernetes
Kubernetes is an open-source platform that provides shared services across clusters or nodes such as scaling/load balancing or monitoring and metrics, but unlike a traditional PaaS it operates at the container level so developers are not limited to the services provided. This allows for more flexibility as app developers and the resources or tools that their applications require. At the end of the day, if your application can be containerized it should be able to run on k8s.
So what doesn’t k8s do? It doesn’t limit the types of applications supported but instead provides for a more diverse set of workflows. It does not provide services across applications such as databases or storage systems; nor does it dictate a configuration language such as json. Ultimately, Kubernetes allows for more flexibility across application development by not specifying certain restrictions on the platform; however, this comes at a price.
Because application-level services are not provided by the platform, k8s is inherently more complex for developers because the onus is on them to determine what resources are required and to build those into their code. Also, for organizations utilizing legacy applications, it may be difficult to modernize the newly containerized apps rather than starting from scratch.
DIY Kubernetes Pros
- More out-of-the-box solutions available
- More flexibility for app developers
- Ease of containerized application migration
DIY Kubernetes Cons
- More required of app teams
- More complex for simple applications
- Challenge converting legacy applications
- Flexibility drives compliance complexities
PaaS
A good PaaS decouples application development and deployment from platform operations and allows for an increased focus on Day 2 operations, increased performance capabilities, and streamlined billing. We look for high use of open-source, high opinionation, and high structure in a PaaS solution for deploying and managing cloud applications. It should provide the services necessary for the applications to run successfully rather than the burden being put on the application developers.
An open-source PaaS project we used to recommend was Cloud Foundry. While we no longer recommend it, Cloud Foundry still provides a useful frame of reference for what a PaaS should be. I was able to retrain as a platform operator on Cloud Foundry in a three week dojo and go to production with it as part of a worldwide ops team with full Day 2 support. This is powerful in the federal and legacy enterprise markets where retraining is a necessity. Rise8 is continually looking for tools with this kind of reach. At the same time, its structure and opinionation came at a cost of flexibility. You weren’t able to deploy stateful applications and for all your workloads you are limited to the services provided.
What we can say is we loved the cf push experience, and we demand from the market that its value be kept alive and expanded on k8s. The Cloud Foundry community has been on a mission to replace Diego with k8s and effectively rebuild/migrate Cloud Foundry to k8s, but we have significant concerns with that effort. We could spend an entire article discussing them, but Daniel Jones at Engineer Better summed it up quite nicely in this blog post. TLDR: if you are looking for a cf like developer experience on k8s, you might want to look at Kf and Anthos. We are keeping our eyes on both.
PaaS Pros
- Provides cross-app services
- Decouples platform and app development
- Ease of multi-cloud and hybrid approach
- Structure and opinionation drive simplified controls compliance
PaaS Cons
- More upfront cost
- Less flexibility for app teams
- Larger infrastructure resource requirements
PaaS or K8s?
It’s a bit of a trick question. If you start off using raw k8s, over time your teams will naturally build the structure and opinionation relevant to their processes and technology in order to reduce toil. This becomes an internal PaaS over time and has almost all of the same pros and cons. The question is if you need to build this, or if you can find it elsewhere. Depending on your needs, it may be more cost-effective to build this structure and opinionation yourself. But what we are seeing for many large enterprises is that there are many vendor solutions that offer the structure and opinionation needed to reduce toil and increase developer and operator productivity without imposing realized flexibility costs. The cost of the FTE needed to build these same solutions in-house often dwarfs the subscription costs year over year.
The common response we get is, “What about lock-in.” That’s another article again, and Gregor Hohpe already wrote it. The TLDR is that your in-house solutions will exhibit lock-in as well, and lock-in will come in many forms. We advocate for avoiding IP and data-ownership types of lock-in, while keeping an eye on future migration costs when working with vendors.
There really is no clear-cut answer to this question, as it really depends on your organization, your needs, your proposed infrastructure ownership, and your team’s overall technical competence.
PaaS may result in more upfront cost based on the required infrastructure and manpower to run the platform, but it takes a lot of the weight off of the application developers by providing various cross-application services; whereas, k8s provides more flexibility to the application teams, but also more responsibility.
There is no right or wrong answer as to which platform methodology your organization chooses to move forward with as long as it provides the capability to achieve your goals.
