The world doesn’t need another “as-a-service” acronym, but in coining containers-as-a-service (CaaS), Docker Inc. hopes it can provide a middle ground that makes containers easy to use in production, both from developers’ and IT organizations’ points of view.
“To me, it’s kind of the new layer that satisfies developers and IT pros both,” said Patrick Chanezon, Docker Inc.’s chief developer advocate, speaking this morning at Container World in Santa Clara, Calif.
CaaS, which Docker announced Feb. 1, isn’t really a service. It’s an environment built from pieces that Docker provides. Developers continue to use their Docker tools for building containers and applications. IT operations can use Docker’s pieces for running those applications — such as the Docker Universal Control Plane and the provisioning tools from Tutum, which Docker acquired in October.
It adds up to an alternative to platform-as-a-service (PaaS).
While working at Google, Chanezon got experience running a PaaS and got to know its limitations. Applications had to be refactored to be cloud-native. And Google’s APIs were unique to its cloud, taking away the portability that developers wanted.
Cloud Foundry was an improvement (and Chanezon worked on that one as well, while at VMware). But it didn’t provide the flexibility that developers wanted. Public clouds offered immense flexibility, but you had to build your own platform out of the infrastructure there, a process Chanezon characterized as painful.
Hence the Goldilocks analogy that Chanezon and Docker Inc. are using to describe CaaS. Infrastructure-as-a-service is too low-level for developers’ needs, and PaaS is too high-level for operations’ needs. CaaS is just right, Chanezon believes.
CaaS is managed by the enterprise’s own IT group, providing the desired level of control over production environments. But it leaves developers free to use containers just as they’ve been doing in development environments. The handoff between the two is the Docker Hub or Docker Trusted Registry, both being repositories for making containers available.
He shared a couple of use cases from real, undisclosed customers. One involved a decentralized CaaS implementation for a hybrid cloud, where applications needed to move to different environments.
The other example was a centralized deployment, with a single control plane allowing portability of applications between Amazon Web Services (AWS) and an OpenStack cloud. Applications teams here are using a centralized trusted registry that includes containers as well as elements for operational functions such as authentication or session management.