Clearing the air around cloud shared responsibility models

April 6, 2018

A blog post by Mike Kavis, chief cloud architect, Deloitte Consulting LLP

Differences between cloud service models

It is critical to understand the differences between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Each service model provides a level of abstraction that comes with its own shared responsibility model. In my book, Architecting the Cloud, I use the following images to show the respective responsibilities of CSPs and customers.

Source: Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS), Wiley, 2013.

IaaS abstracts away the data center and physical infrastructure that we traditionally rack, stack, patch, and manage. The CSP’s responsibility is to make sure their physical data centers and infrastructure are secure, complaint, highly available, and reliable. The customer’s responsibility focuses on managing the application stack, the actual applications that are built on top of the IaaS layer, and all of the user access and administration to the cloud and the applications.

Too often, customers get bogged down trying to understand what the CSPs are doing in their data centers even though that is not their responsibility. An easy way to look at it is that the CSP is responsible for everything beneath the hypervisor and the customer is responsible for everything above.

PaaS takes us a level higher up the stack and abstracts away the application stack components. PaaS targets developers in attempt to abstract away not only the physical infrastructure, but also the various stack components such as application servers (e.g. Apache Tomcat^®), database servers (e.g. SQL Server™, MySQL™, Oracle^®, etc.), caching servers (Redis, Memcached, Varnish, etc.), and so forth.

In this model, the customer is responsible for administering the users and building, managing, and operating the application, while the CSP manages all of the underlying infrastructure and application stack software.

SaaS is the highest level of abstraction and adds the actual applications to the list of stack components that fall under the responsibility of the CSP. SaaS providers, such as CRM solution provider Salesforce.com and time-and-expense (T&E) reporting solution provider Concur^®, deliver an entire application on demand that is fully managed by the SaaS provider. Customers only tweak configurations and manage user access and administration to the applications. For applications that are not an enterprise’s core competency, SaaS solutions should be given a strong consideration.

Pros and cons of the models

Each cloud service model has tradeoffs. The higher up the stack the CSP manages, the more dependent the customer is on the CSP for security, service levels, and uptime. At the same time, customers potentially benefit from higher speed to market; lower development, operational, and maintenance costs; quicker availability to new features and services; and more time to focus on value added tasks.

When it comes to the decision-making process for selecting a cloud service model, customers should evaluate each workload separately based on the requirements of that workload. For example, the requirements for a T&E tracking system are entirely different than a transaction processing application. The former has fewer compliance requirements, lower performance requirements, and lower uptime requirements than the latter. It may make perfect sense to leverage a SaaS model for the T&E system, while leveraging IaaS for the transaction processing system.

In fact, some transaction processing systems, such as stock trading, have such low latency requirements and high availability requirements that customers may choose not to use the cloud at all. The key message here is that the selection of the cloud service model should not be a binary decision that applies to all workloads.

Lessons learned

When the shared responsibilities of a cloud service model are not completely understood, an enterprise’s cloud journey often suffers. Following are some anti-patterns I commonly see in such cases:

• Increased complexity—when customers try to monitor and manage stack components that are the CSP’s responsibility, they often introduce unnecessary complexity in the form of wasteful business processes, additional tooling, and bloated architectures.
• Suboptimal decision making—the less customers understand the shared responsibility model, the more likely they are to lean towards building on-prem or not allowing public cloud altogether. Even when they do allow some level of cloud activity, they tend to get increasingly uncomfortable with the higher levels of abstraction that PaaS and SaaS offer. The end result is they often continue to build everything internally and don’t gain any of the agility and cost-reduction advantages that the cloud offers.
• Slow to market—lack of understanding of shared responsibility models often leads to endless meetings between risk and compliance teams and the CSPs. Meanwhile, the development teams are not able to build on the cloud until all risks are mitigated.

Educate your stakeholders

Shared responsibility models between CSPs and customers have been around for several years but are still grossly misunderstood in some organizations. Lack of clarity about who owns what responsibility can lead to reduced time to market, poor decision making, increased complexity, and a suboptimal cloud experience. It is critical that enterprises get out in front of this issue and educate their organization about the different cloud service models and the shared responsibility for each. The sooner that gets accomplished, the less heartburn you will have in the long run.