The Evolution of Cloud Computing and the Updated Shared Responsibility

Written by Vishwas Manral, Founder and CEO at NanoSec, CSA Silicon Valley Chapter.

Cloud computing has changed over the last 10 years. This blog captures the reason why the original service models are no longer sufficient as a result of the changes in the cloud landscape with the growth of Containers, Functions, Low Code and No-code.

This blog also discusses the shared responsibility models for various different paradigms and examines where we are headed in the future.

Background of Service Models (SaaS, PaaS, and IaaS)

The National Institute of Standards and Technology's (NIST) provided a definition of cloud computing comprising of three service models, four deployment models, and five essential characteristics in 2011 (NIST Special Publication 800-145).

The document was intended to serve as a means for providing standards and guidelines, especially when comparing cloud services and deployment strategies, and to provide a baseline on the best uses of cloud computing.

The three service models were SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), and IaaS (Infrastructure-as-a-service). This was the past and the models need to evolve to encompass the new platforms.

Innovation and Software Development as a Key Change Driver

Bringing new and differentiated value to the marketplace is now a competitive necessity and enterprises that are best organized to deliver on innovation quicker in a repeatable manner are the market leaders. Enterprise deployment of cloud computing has matured and changed with the urgency to bring new value and software being the change driver.

This is true for the infrastructure layer, the service layer and the application layer, where we have seen a proliferation of containers, the rise of Kubernetes (K8s), the advent of edge computing, and the broad adoption of serverless architecture, all in service of developers to enable them to bring value to the marketplace faster.

Trying to fit the new architectures into the 2011 SaaS-PaaS-IaaS framework, is like fitting a square peg in a round hole!

New Service Models

At its core, a *cloud* shared responsibility model provides clear demarcation in duties between the cloud providers (Amazon Web Services, Microsoft Azure, Google Cloud Platform, or more generically the platform providers) and cloud consumers or the application owners (enterprises and startups alike).

The diagram below shows the differences in responsibility across the various service models, that we see now.

Some key points:

Slowly more and more responsibility is being taken up by the platform providers, reliving the application owners of non-application logic centric responsibilities.

As one move to the right there is a reduction in operations cost and overhead as the platform provider takes up more responsibility.

As we reach platforms like NoCode/ SaaS the developer responsibilities themselves are reduced. Leading to the rise of a new level of developers, who are not hardcore coders.

The new service models that have evolved since, besides the IaaS, PaaS and SaaS are defined below.

Managed K8s as a Service (K8s-aaS)

Managed Kubernetes is the most widely used Managed Service Control Plane as a service (CPaaS) provided by most cloud providers. In this case the Kubernetes control plane is managed by the platform provider with some control plane (aka K8s Master node) configuration optionally provided by the application owner. The lifecycle of the data plane and managing it, is done by the application owner.

This works best when the application has specific needs from the data plane, cost optimal scale-out is a bigger consideration than additional operational overhead or when the application needs to be a multi-cloud portable application.

Examples are Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE). AWS Elastic Compute Service (ECS) is an example of a non-Kubernetes managed control plane service.

Container-as-a-Service (CaaS)

In the case of CaaS, the application owner provides the application containers, and the platform provider manages both the control and the data plane. This means application users do not need to manage the servers (VMs), the scaling and patching of the Host OS or the bringing up and down of the servers, on top of all the functions provided by the CPaaS.

These services are also termed serverless because the application owner is relieved of a lot of the server management responsibilities. The services are best suited for cases where it’s not an event drive architecture and the application owner is less sensitive to scale out costs.

Examples of Containers-as-a-Service (CaaS) solutions are solutions like Amazon Web Services (AWS) Fargate (both ECS Fargate and EKS Fargate), Azure Container Instances (ACI), and Google CloudRun.

Function-as-a-Service (FaaS)

In the case of FaaS, the application owner provides business logic, along with layers in which to run the function. These functions are built, packaged and run by the service provider. The service control plane and data plane are fully taken care of by the service provider.

This service is best suited for event driven stateless applications.

Examples of this service are AWS Lambda, Azure Functions and Google Cloud Functions.

NoCode-as-a-Service (NCaaS)

In NCaaS the code logic is provided by application owner. The service provider generates code from the specification and configuration, then builds, packages and runs the software.

Another similar but slightly different version of this is Low-Code-as-a-Service (LCaaS).

As there is little coding involved, these platforms are best designed for even non-technical users to create applications. This will see tremendous growth in the coming years and cause a huge growth in software developers.

Examples of this service are Azure Power Apps, Google AppSheet and AWS Honeycode.

Serverless

Serverless platforms enable developers to develop and deploy faster, allowing an easy way to move to cloud native services without having to manage infrastructure - including container clusters or virtual machines.

Examples: In the above model CaaS/ FaaS and NCaaS platforms would be treated as Serverless.

Selecting a platform for your applications

The below diagram provides a summary of how an application owner can decide which cloud platform to use for their services.

Summary

In summary, the future landscape of applications is very diverse, highly hybrid and multi-cloud. Enterprise cloud computing platforms will include a vast variety of infrastructure, service layers and APIs including serverless and server apps, on-premises and cloud.

There isn’t going to be a “one-size fits all” model or a single rule of the thumb. In true cloud fashion, it’s an agile and elastic decision to support a scalable and secure environment that evolves as organizations change.

I invite you to connect with me on Twitter @vmanral or Linkedin, to share your thoughts and provide your input.