Is CaaS a thing? [closed]

Question

I often come across charts of application hosting models with a sorting similar to this one:

Dedicated → IaaS → CaaS → FaaS → PaaS → SaaS

• IaaS as machine + operating system
• FaaS as machine + operating system + servers
• PaaS as machine + operating system + servers + extra tools
• SaaS as machine + operating system + servers + extra tools + application/s

These are quite well defined concepts, but a "container" can contain each one of these (besides a non virtual machine); in other words, a container can start with an entire (virtual) machine and end where the sysadmin chooses to delineate it; hence I ask, is CaaS a thing?;
Is it well defined in comparison to other common hosting model categories?

Answer 1

You have Azure Container Instances which is not even similar to Google Cloud Run. You can have a GCE instance running a single container. You can run containers in PaaS platforms like Azure App Service and AppEngine Flexible while this add you these extra tools like SSL, load balancing, CDN etc. AWS has their own ECS, AWS Fargate and Beanstalk.

The container deployment in a serverless model (Azure Container Instances/Google Cloud Run/AWS Fargate) seems useful, however, it is not standardised beyond container format. Most of the time it is for running a single container when you don't need all the bells and whistles of a PaaS, running a tool or a short batch job. ACI and Fargate can serve long running containers, Cloud Run is more like FaaS for containers.

For any more demanding solution Kubernetes definitely is a thing. Requires a little more understanding and configuration but every cloud provider has Kubernetes as a service. You can treat it as a standard.

Hard to say which one is CaaS...

Answer 2

TL;DR

Yes, CaaS is very much a thing it means Container-Orchestration-as-a-Service. Kubernetes is the leading technology in this space.

Long Version

The key to understanding the following progression is the concept of "-as-a-Service":

Dedicated → IaaS → CaaS → FaaS → PaaS → SaaS

It means you are paying either an internal or external team money to host a service onto which you deploy your business solution. Yes, you can use containers on top of a dedicated hardware service. You can use containers on-top of IaaS. Yet you have to look after the low-level concerns such as installing and patching the operating system. If you are simply renting VMs from a cloud provider you are not renting a container solution as a service.

When people talk about CaaS they usually mean “Container-Orchestration-as-a-service”. Examples include Amazon Elastic Kubernetes Service, Azure Kubernetes Service, and Google Kubernetes Engine, IBM Cloud Kubernetes Service and Alibaba Container Service for Kubernetes. There is a vast difference between deploying software onto a Kubernetes cluster that someone else set up, secured, then automated for you and having to configure a bunch of IaaS VMs to reliably run containers yourself. High-performance Kubernetes installations use specialist 'single purpose' operating systems such that the servers are more like appliances than typical VMs. The idea is that the cluster (both OS and Kubernetes software) can be security patched as a rolling upgrade without any downtime of the services hosted on the cluster.

History Lesson ;-)

The historic position around 2011 before Docker was released in 2013 would have been:

Dedicated → IaaS → PaaS → SaaS

In that, it is PaaS which, IMHO, is the vague classification that has changed over time with the rise of containers. Examples of early PaaS solutions that came before containers are the original Heroku, the original CloudFoundry, and early versions of RedHat Openshift. They were “DevOps platforms” before the term DevOps was invented. The original versions used some of the Linux techniques that containers later made famous, but it was an internal detail. The main marketing points made were two-fold. The first was developer productivity of having built-in CI/CD and the second was that the servers were easy to security patch and administer. The servers were treated like sheep and the vendor-supplied service packs to keep them secure.

The problems with the original PaaS concept was no standardisation, vendor lock-in, little portability, as well as proprietary tooling. They had embedded and proprietary build systems as well as proprietary configuration and deployment mechanisms. Opensource container orchestrators have revolutionised things by fixing those problems. The big open-source PaaS solutions such as OpenShift, CloudFoundry and Mesosphere now all support Kubernetes. Users no longer need to use a proprietary build and deploy pipeline nor propriety configuration mechanisms. They can use a vast number of different tools to build containers that they pushed up to any number of hosted container registries. They can then use the Kubernetes API to deploy into their chosen cloud provider. IMHO the original PaaS concept of “rapidly build, deploy and configure a web app” has standardised into CaaS as the main runtime.

More info:

if you want to see what you can do with CaaS checkout my blog on full automation of a start up.

Update:

I found the talks Stop Calling Knative Serverless! - Doug Davis very informative. At around 2:45 which compares PaaS, with CaaS, with FaaS. The talk introduces KNative and at the end around 32:07 compares KNative to PaaS, CaaS and FaaS. The presentation states that the Kubernetes definition of CaaS is rather bare-bones and missing a lot of "obvious" things if you are familiar with a PaaS. Both KNative and OKD (Openshift) are demonstrating that you can build another style of platform (PaaS, FaaS) on top of the bare-bones Kubernetes CaaS.