You Shalt Not PaaS

The classic PaaS isn’t really a solution for most developer teams using Kubernetes. What most need, instead, is to “just push their code.” But how? 

Classic PaaS isn’t a complete or optimal solution for managing Kubernetes complexity and delivering a simpler, more productive developer and operator experience. There are better, more agile ways forward into the sunlit uplands of software productivity on open, modern clouds.

“Platform as a Service” means defining a service or a software layer that abstracts a host infrastructure, hides complexities, and adds missing features. If you’re confronting Kubernetes complexity, need to help developers become radically more productive in a hurry, and want operations to be safe and deterministic, PaaS is a good and wholesome concept.

But running a classic, all-consuming PaaS on Kubernetes – the way VMware wants you to, with Tanzu Application Services – doesn’t make a ton of sense. Here are some reasons why:

1. Kubernetes already does big parts of what a heavy PaaS does. Tanzu Application Services is basically an updated take on Pivotal Cloud Foundry (PCF), a comprehensive PaaS framework originally developed to solve – not Kubernetes complexity – but container development and operations complexity on infrastructure-as-a-service clouds like vSphere/vCenter and OpenStack.

   These platforms ran virtual machines natively, not containers. And VMs are blunt instruments – big, complicated, hard to build and update, with numerous dependencies that entrap the applications running on them. So they’re slow to rebuild/restart/move when you want applications to be light on their feet. The (at this point, pretty obvious) answer is to put container runtimes on VMs and then orchestrate containerized applications on top of them. So that’s what PCF did: provide an abstract environment with services to orchestrate containers across a cluster of virtual machines.

   In a pre-Kubernetes universe, this was undeniably cool. I remember deploying PCF on OpenStack with BOSH and writing a very, very long and loving reference architecture for how to do this for production. Later on, when Docker released Swarm, I wrote a reference architecture for that, too – much shorter and simpler. And then, of course, Kubernetes emerged to actually provide enduring standards for how full-on, enterprise-class container orchestration should work.

   So your first take-away is a question: given Kubernetes, why cover it up with a competing orchestration system (with a smaller user base) that isn’t simpler? Even Swarm (I think, anyway) still makes a lot of sense for some use-cases, since it’s an extension of Docker-compatible container runtimes, can run right alongside Kubernetes on some Kubernetes cluster models, and because it actually is simpler.

2. When Cloud Foundry emerged, containers themselves were the new-new-things. Now they’re not. Nobody knew how to build containers efficiently and securely as part of a developer workflow. Nobody knew how to curate base images to support common language models well. And of course, there was no standard model for how container workloads could be assembled and configured for automated orchestration. So PCF evolved to fill these gaps and provide – if not the standard, then a standard for doing this stuff.

   And of course, many still don't know how to do these things – which is a problem! But now we have standards and proven methods for all this stuff. Kubernetes itself has Buildpacks as an incubating project. And meanwhile, we have rafts of technologies and services for building and scanning and curating and code injection.

3. The CNCF, however, moves faster than typical organizations. And trying to make choices, integrate new products, and stay on the leading edge of at least hundreds of competing solutions moving at lightspeed can be confusing. So heavy PaaS solutions, for a while, provided an island of stability: preparing folks for the future of standardized container orchestration while they were still focused on IaaS. And, arguably, in the present day, if you’ve already made a many-years-long commitment to running on the Cloud Foundry abstraction, porting that abstraction to Kubernetes looks like a route to all that work not being wasted.

But if you’re not tied to legacy abstractions …

… We can, today, propose more agile, flexible, future-proofed, and standards-based solutions. Mind: typical software development organizations still have the same set of problems: They know they’re moving away from proprietary cloud architectures towards open, and migrating towards Kubernetes. But they’re not sure how to stack open IaaS and Kubernetes and trick it all out for production, and they don’t have time or funds to staff up and experiment.Critical applications need to reach customers today. In this blog series, we’ve talked about replacing proprietary cloud architectures with  enterprise-class open-source-based IaaS and production Kubernetes, and solving cloud build and operations problems by outsourcing to trusted partners who have mastered the entire modern cloud stack.

Organizations know they need a “platform,” not just ‘vanilla’ upstream Kubernetes, to accelerate development. And they grasp (maybe?) that this is a three-part challenge:

1. They need to ensure their production Kubernetes cluster model is appropriately extended to be a functional, secure, productive home for modern applications. They need access control mechanisms that prevent people and teams from stepping on one another and keep bad guys out. They need things like service mesh, which routes traffic into and among dynamically-orchestrated application components; securing it and making it observable. They need a production-class backup and disaster recovery system in place – among much other stuff.

2. They need a containerized software development and GitOps workflow that solves for their particular goals and requirements. One that lets front-line developers “just push code,” and then handles the arcana of building and installing it on heavily-curated, approved, pristine, pre-scanned base images; forwarded to test; to QA; and eventually to production, with appropriate Kubernetes-native automation built around each app to operationalize it, so it can be observed and monitored and updated non-disruptively and so it can babysit itself with Kubernetes’ help.

3. They need standard tools to help coders and operators visualize what’s going on inside Kubernetes, accelerate iteration towards working code and/or fixes, and collaborate effectively around Kubernetes clusters and projects.

Again, the fastest way to production Kubernetes and mature/secure developer workflow – and the only way to get all this stuff without paying a heavy price in operational overhead, toolchain maintenance, and so forth (and also without lock-in to “one true end-to-end” solutions), is to work with experienced, opinionated partners who know what development shops need, and who can provide “DevOps-as-a-Service” in a productized, scalable, dependable way.

Most organizations know they need to ‘hide’ or abstract Kubernetes away from many devs, and appropriately control all the ecosystem variables around workload containerization and operationalization, including performance, security, observability, lifecycle management, and so forth, so that teams can quickly produce quality software for Kubernetes without understanding and taking responsibility for containers and Kubernetes in every scary detail. Developers need to be able to “just push their code.” 

And this brings us full circle to the question of “abstractions adjacent to PaaS.” 

Today, however, we have Kubernetes-optimized solutions to this problem: simple standards, services, and frameworks that help package and operationalize different application footprints (for example, multi-tier production website) with well-understood characteristics and popular components (for example, popular CMSs, and so on). One of the interesting things about this new breed of “light PaaS for K8S” is that these standards actually provide things that Kubernetes still lacks: like a dependable way of enumerating all the containers running on the platform and knowing with assurance what service they’re performing for which application.

If you’re interested in learning more about how to do modern application delivery and DevOps on Kubernetes (any Kubernetes), please join us on May 11 at 12pm PT / 3pm ET for a webinar titled: "Accelerating Application Delivery and Operations in Kubernetes Environments." Mirantis' Daniel Virassamy will discuss modern services and open source-based products that solve operations headaches, simplify development of Kubernetes-native containerized apps by expert teams, and help any developer get to where they can just “push their code.”