Containers as a Service (CaaS) Solutions Offer Greater Agility, Portability and Simplicity Benefits Over PaaS For Hybrid Cloud Deployments
Platform-as-a-Service (PaaS) solutions point in appealing conceptual directions. But are Containers-as-a-Service (CaaS) solutions actually better for delivering the agile development workflow, simplicity and no-kinks workload portability that hybrid cloud deployments require?
In real-world organizations with diverse needs, DevOps teams may need to wrangle platforms ranging from relatively simple and generic (e.g., LAMP servers, small SQL database clusters) to complex one-offs (e.g., scalable, resilient, production application hosting clusters or indeed, PaaS platforms). Platform-wrangling is hard and time-consuming. The same wheels get reinvented again and again, with tiny variations and few economies of scale. Deployment automation, where used, tends to remain brittle, naively inflexible, or highly complex. Self-service is hard to provide, clumsy, slow, or all of the above. Platforms tend to remain “pet projects” that are rife with complex dependencies and hard to update, secure and validate. Once built, platforms of any complexity are not readily portable between clouds, even of the same underlying type.
Enter PaaS
Platform-as-a-Service (PaaS), now a decade-old paradigm, offers what seems to be a much better, more agile way of serving out IaaS resources to users. PaaS runs atop IaaS, providing a generalized platform for running containerized, dynamically-assembled application hosting workloads, bound, as needed, to shared service instances (e.g., database instances). The PaaS provides services for DNS, load balancing, resilience, scaling and, in addition, CLI and web tools for life cycle management of applications , services, and the platform itself.
The idea seems brilliant. Much of the complexity of legacy platform wrangling looks to be abstracted away. Applications on a PaaS run against a containerized OS and prebuilt root file system (called a ‘stack’ in Cloud Foundry, or a ‘gear’ in Red Hat’s OpenShift) and a supported “buildpack” (or, in OpenShift lingo, “cartridge” — other PaaS solutions use a range of different terms) defining language interpreter/compiler and associated support services, with external service connections specified in manifest files for action at runtime. In theory, developers can focus entirely on building applications, and trust the PaaS to cloudify them as requested: allocate compute/network/storage, load-balance multiple instances of an app for high availability, scale out by instances for capacity on demand, facilitate monitoring/logging, etc. Stack dependencies, security, and other issues are handled by using (and smoothly updating) buildpacks and services curated by the PaaS provider.
PaaS Problems
PaaS adopters have, however, discovered that some of these benefits are hard to achieve in practice, at least without also accepting certain downsides.
PaaS means choosing one incompatible system over another. There’s no single standard for PaaS. While most PaaS frameworks are architecturally similar, and all strive for the same kinds of information-hiding and service abstraction, often even using identical tools, all are incompatible at the level of CLIs, REST interfaces, manifest file formats, default buildpack/framework base configurations (language and framework versions, etc.), exposure of OS APIs and services, external service API details and other points of component/component integration. So choosing one is a big commitment: choice of PaaS determines what your coders need to learn, how your tooling works, how your organization develops and operates software.
PaaS may play favorites with certain languages and frameworks. Each popular PaaS supports a range of language and framework combinations and lets sophisticated developers compose buildpacks for new languages. In actuality, most favor a small handful of favorites — so, choice of language and framework may, in fact, end up guiding you strongly towards one PaaS vs. another. If you want greatest flexibility for Python development, for example, Google App Engine, which supports Flask and many other frameworks and has pioneered WSGI integration between Python executive and web servers, is probably where you want to be. Conversely, Cloud Foundry is probably a better choice for Java/Spring Framework developers.
PaaS may or (more often) may not elegantly serve your organization’s goals for hybrid cloud and multi-cloud. Not every PaaS can be installed on premise hardware; and public cloud choices may also be very limited. Choosing one PaaS over another can further limit choices due to lack of standardization and non-uniform language support.
PaaS frameworks are architecturally heavy. PaaS platforms that offer the richest capabilities and greatest flexibility to developers e.g. Cloud Foundry turn out to be computationally and architecturally very heavy. Often run atop an IaaS layer (less frequently on bare metal), they have control planes rivaling those of IaaS in complexity and impose significant overhead, even on runner nodes (workload hosts). This limits workload hosting capacity by comparison with containers, and makes lifecycle management of the PaaS framework more ponderous and time-consuming.
PaaS is typically not legacy-friendly and 12-factors can burden coders. Bringing legacy apps into a PaaS environment commonly requires significant refactoring: adapting to genericized/abstracted PaaS language bindings, environment features, service APIs, and eliminating real-world dependencies. This still isn’t enough, however, to let legacy apps work efficiently with PaaS systems that are optimized to support so-called “12-factor” cloud-native apps: stateless, microservice based, horizontally-scalable.
Containers as Service: The Advantages over PaaS
In many cases, it is being increasingly realized that Containers-as-a-Service (CaaS) — now almost-universally provided using Kubernetes — offers a more-agile, simpler path to actually realizing the benefits expected from PaaS.
CaaS has evolved as a kind of compromise between IaaS and PaaS: usefully abstracting the full stack, without adding “gotchas”.
Deploys quickly and lightly on any infrastructure. Drawing on core features of Linux such as containers, Linux networking and storage abstraction, Kubernetes deploys very quickly and easily, running with great efficiency on bare metal or virtualized infrastructure — enabling abstract consumption of that infrastructure through standardized ‘provider’ interfaces and built-in life cycle management e.g., private Kubernetes clusters for individual developers or teams. Unlike PaaS, with its heavy, complex clusters, Kubernetes lends itself to lighter usage paradigms. This is so particularly when cluster deployment is further simplified by CaaS implemented at the IaaS layer.
Provides commodified, standardized functionality on premise or public clouds, and enables hybrid cloud with robust Federation. Kubernetes can run on essentially any premise cloud, including OpenStack; on AWS, Google, Azure and on many other providers. An admin can access and manage all these resources via a single ‘pane of glass’ (webUI and CLI). Disparate clouds can be quickly linked and treated as one, burstable infrastructure continuum, via Kubernetes Federation.
Offers all the power and leverage of standard, open container technology, without “dumbing down.” Many of the benefits of PaaS (such as dependency isolation, composability, workload portability, and fast starts/stops of packaged workload instances for redundancy and horizontal scale-out) actually derive directly from standards-based containerization. PaaS systems exploit containerization, while partially obscuring the fact — all while encouraging developers to prefer a limited set of curated buildpacks and services, and proprietary CLIs and APIs.
Meanwhile, developers have globally embraced standards-based container agility, and are increasingly comfortable with the freedom CaaS/Kubernetes affords them to compose optimal custom composable platform solutions. Organizations building fully cloud-native, 12-factor apps, meanwhile, will find the pure container environment of CaaS more conducive to container best-practice (and thus more beneficial) than the ‘compromise’ approaches PaaS tends to favor.
Implicitly endorsing this line of thinking are several leading PaaS providers, including Pivotal, who have recently introduced a Kubernetes offering; and Red Hat, whose OpenShift presents as a PaaS, but is really Kubernetes under the hood.
Three or so years ago, when container orchestration was still in a primitive state and PaaS offerings (at least market leaders) were looking rich and increasingly mature, it might have made sense to jump into PaaS and try using it as a bridge to the future. Today, for organization looking to move away from old-school platform-wrangling and towards more-modern app development and operations, CaaS may be emerging as the better go-forward investment.
- Beyond Kubernetes Operations: Discover Platform9’s Always-On Assurance™ - November 29, 2023
- KubeCon 2023 Through Platform9’s Lens: Key Takeaways and Innovative Demos - November 14, 2023
- Getting to know Nate Conger: A candid conversation - June 12, 2023