December 16, 2017

For cloud people like me—I’m the CTO at Cloud Foundry Foundation—containers are a constant conversation topic. The main issue is how to embrace this new application architecture and put containerized workloads into production use in the best way possible, keeping the agility promise to the Devs that Ops can make it all work—at scale. There are a lot of cloud workloads coming so we all need to get ready. Indeed, my organization recently announced a global initiative to train and certify software engineers on Cloud Foundry to help address the shortfall of cloud developers, another emerging problem as more business goes cloud.

The dirty secret in our industry is that enterprises are increasingly frustrated by the challenge of getting containers off developer laptops and into production at any scale. Until recently, the only viable solution was with platform-as-a-service (PaaS) offerings from vendors such as Red Hat (OpenShift) and Pivotal (Pivotal Cloud Foundry). Now we’re seeing more and more container-as-a-service (CaaS) offerings that promise a lightweight alternative for companies whose priority is to put their containerized workloads into production without the need for a full-fledged PaaS. Let me help you sort this out.

What’s a CaaS? What’s a PaaS?

First, let’s talk about the difference between a CaaS and a PaaS, starting with their similarities. Both a Paas and a CaaS refer to the developer process of getting code running in a platform. A good PaaS will take the code and deal with all the containerization issues internally—which is what Cloud Foundry does. Cloud Foundry has a long history of running containers in secure and multi-tenant environments. Cloud Foundry uses the library runC, which originally came from Docker, and is the lowest-level runtime for containers. Cloud Foundry uses its Diego project as the container orchestration layer of the platform—rather than using Kubernetes or Apache Mesos. Cloud Foundry software probably runs more containers in production today than anyone outside of cloud giants Alibaba, Amazon, Baidu, Google and Microsoft.

What most people don’t realize is Cloud Foundry does both PaaS and CaaS well. Technically, as an open-source foundation, we don’t offer a PaaS, we provide software—Cloud Foundry—that allows you to run a PaaS or a CaaS.

Don’t worry too much, though. Even the major vendors playing in this space don’t agree on a CaaS definition. The most important thing is to focus on your use case and figure out which service makes the most sense for you.

When to Choose a CaaS

The next question is how do you decide when a CaaS is best for you or a PaaS? Personally, I am not religious on this issue. I am a pragmatist. There are times when it’s easier to take an existing application, bundle it into a Docker container, call it good and push it into production. When your development team has fully embraced Docker images as the preferred container format for their workflow, it might be easier to focus on a CaaS to run your Kubernetes or Mesos clusters.

Or, you could choose a container service managed by someone else—which is where I think a CaaS performs best. That could be Docker Cloud or IBM Bluemix, which uses Cloud Foundry. If you’ve adopted Docker files and all the tooling around it, look for a CaaS you can deploy yourself or go for a service.

When PaaS Might Be Better

The downside of a CaaS is that you don’t get much flexibility, which may be critical in an enterprise production environment. I see this as the common thread among leading CaaS solutions. The essential components of a CaaS include core container services, an image catalog called a “registry,” cluster management software and a set of developer tools and APIs. You will notice that there is a lot missing in a CaaS that you get in a real PaaS, including such features as high availability, auto scaling, traffic routing, logging, security, application lifecycle management, infrastructure automation and more. That’s why Cloud Foundry is so popular in the biggest enterprise cloud deployments, from AllState and AT&T to Ford and Volkswagen, among many others.

There is nothing wrong, per se, with a CaaS—so long as you know it’s all you need and you understand what you are getting. There is also a profound philosophical difference in the approach Cloud Foundry takes versus how some of the CaaS solutions are constructed. Our opinion is developers should not be concerned with the intricacies of infrastructure. Developers naturally want to play with the latest shiny stuff. We think that should mean focusing on things like languages and frameworks, not fibre channel versus NAS storage details, or even how to configure a container engine. We’re big believers that cloud developers should only worry about expressing intent for an application, not the implementation specifics for how to make that intent happen.

The Cloud Foundry community prefers to embrace standards and software as they are more broadly adopted and as they mature. We don’t grab the latest thing in infrastructure open source just because it’s new—that’s high-risk behavior for a software project relied on by many people. Cloud Foundry is in use by many of the largest companies in the world, so we take a cautious, reasonable approach to this sort of thing. We can’t afford not to.

About the Author / Chip Childers

Chip Childers is CTO of Cloud Foundry Foundation. Childers has worked nearly two decades in large-scale computing and open source software. In 2015, he became the co-founder of the Cloud Foundry Foundation, an international consortium of the world’s largest technology companies, Fortune 1000 enterprises and a global development community. He was the first VP of Apache Cloudstack, a platform he helped drive while leading Enterprise Cloud Services at SunGard and then he served as VP Product Strategy at Cumulogic. Prior to SunGard, he led the rebuild of mission-critical applications for organizations that included IRS.gov, USMint.gov, Merrill Lynch and SEI Investments. Childers is an experienced speaker at events like OSCON, LinuxCon North America, LC Japan, LC EU, ApacheCon, O’Reilly Software Architecture Conference, and many more. In his free time, he loves trail hiking with his black lab, sailing catamarans and sunfish, and trying to keep up with his young daughter.

Lorum Ipsums asdfasdfasdf

  • MK

    Informative article but I would slightly disagree on few things:
    1. I think developers should be concerned with the intricacies of infrastructure to build better software.
    2. I think CaaS provides greater flexibility than PaaS at this time when large enterprises are moving towards hybrid approach of using on premise infrastructure with being tenant of AWS’s or Azure’s or GCP’s IaaS. And having enterprise grade container management service like Cloud Foundry or OpenShift or for that matter AWS ECS or Kubernetes on GCP or Azure makes a good case of moving more towards CaaS which provides smoother inter-operability

    • sasanka ghosh

      ui r an asshole so u do not understand . u r a dickhead. first understand what is devlopment and cloud in production environment then talk. in ur laptop doing with few MBs of data u fking piece of shit . core Design DOES NOT DEPEND UPON In Premise or CLOUD

    • sasanka ghosh

      when designing a dabase whether it is cloud or In premise thinks abt partition , right indexes , stat collection , data access pattern . similarly when writing a java application garbafe collection , right objects,interfaces, synchronization, exception handling etc. nothing to do with infra. if something can run and scale up or scale out in in house data centre it will do so in cloud. it is all abt cost . Understand mr fake degree holder who never worked in real life . In India Fake ppl like u r everywhere so india is a shit country .

  • Jagrati Gogia

    Is it possible to use Kubernetes as the container orchestration layer of Cloud Foundry instead of the Diego project?