What is a shared responsibility model (SRM) in the hybrid cloud?

One difference between private datacenters and public clouds is who is responsible for each: Cloud providers say that the enterprise is solely responsible for private datacenters, whereas the burden is shared between the enterprise and the cloud provider in public clouds. In this way, cloud providers position the public cloud as the sole way an enterprise can alleviate some of its responsibility by outsourcing as many layers of the IT landscape as possible.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

To explain the public cloud concept, each cloud provider provides a shared responsibility model (SRM) that outlines the responsibilities for security and operational workloads. This approach allows enterprises to outsource many traditional operational burdens so that they can focus on competitive advantage.

What these models ignore is that rarely, if ever, have enterprises not already outsourced their private datacenters. Datacenters have long been supported by vendors, internal teams, and managed service providers. For most enterprises, this mixture of third-party vendors is likely to continue. Thus the SRM is an idealistic simplification of reality. However, modeling responsibility is critical to an enterprise architecture, and the division of responsibility is likely unique to each datacenter.

The hybrid cloud recognizes each enterprise's complex requirements and history and provides solutions to assist in modernizing its IT. This means it is up to enterprise architects to define their own SRMs and for cluster administrators to communicate the benefits and boundaries of their platforms to internal stakeholders and tenants.

What is hybrid cloud?

Hybrid cloud architecture allows the enterprise to run applications under different computing environments across a standardized platform. Enterprises continue to spend millions building private datacenters that need to be utilized. However, the public cloud is interesting for innovative and flexible workloads. The hybrid cloud brings these two cloud types together across multiple technologies and providers.

Orchestration platforms such as Kubernetes and OpenShift enable hybrid clouds to provide a consistent environment across numerous clouds, offering a seamless way to develop, test, and operate a hybrid cloud platform. These orchestration platforms allow enterprises to standardize the technology stack across cloud providers and deliver a consistent SRM.

[ See 5 things architects should know about cloud service providers. ]

How various cloud providers define SRMs

Cloud providers' SRMs are remarkably uniform and easy to understand for business and technical stakeholders. However, there are several minor differences:

• AWS's SRM states, "Customer responsibility will be determined by the AWS Cloud services that a customer selects."
• Microsoft Azure expands its SRM by including Software as a Service (SaaS) and on-premises.
• Google's SRM emphasizes a "shared fate" by seeking a partnership, providing "secure-by-default" configurations, and offering extensive monitoring to reduce security and operational risk.
• Red Hat's OpenShift Service on AWS (ROSA) expands the SRM concept (or responsibility assignment matrix) by introducing an additional stakeholder, Red Hat, to the mix of responsibility with AWS and the enterprise.

The key commonality is that, at a minimum, customers are responsible for their data, access control, and configuration. Responsibility increases for layers of control required in the stack. Not shown in the model are the internal layers of responsibility provided within a cloud, namely the IT administrators and the application teams.

In the hybrid cloud, enterprise architects and administrators can adopt an SRM for their customers and behave as a cloud provider, regardless of the datacenter's location. This model helps promote utilization and clearly communicates responsibility in the environment.

These same responsibilities apply to an on-premises environment where IT administrators and the tenants have different roles. These two roles also exist in the public cloud for enterprises, and the delineation between administrators (operators) and application owners is a gap in the SRM.

How a hybrid cloud SRM works in practice

In the hybrid cloud, enterprises have multiple cloud stacks with various shared responsibilities to suit their current and past business needs. An enterprise adopts multiple "consumption models" (such as SaaS, Platform-as-a-Service, Infrastructure-as-a-Service, outsourced, and full-stack) to fulfill different business requirements based on changing strategies and conditions across multiple datacenters.

The diverse and complex nature of the hybrid cloud means there is no "one size fits all" for customers. Despite the limitations, the SRM gives enterprise architects the ability to represent their environments, support capability, and educate stakeholders across the stack and environments. It also describes the active support and managed services engagements provided by third parties responsible for different aspects of the stack.

The following table shows that an on-premises solution could be partially or even fully outsourced like a private cloud, and a cloud stack could also have a mixture of software and hardware vendors working together to provide a managed cloud platform.

Image

[ Discover ways enterprise architects can map and implement modern IT strategy with a hybrid cloud strategy. ]

How to use a SRM within a cluster

You can take the SRM further and use it to help promote internal clouds for consumption. Within a cluster, tenants (application teams) and the platform owner (cluster administrators) have a shared responsibility. Traditionally the delineation between these teams was straightforward, with a common operations team that would take responsibility for the stack end-to-end.

However, DevOps blurs this delineation. This is even more apparent when you have common application services such as Kubernetes operators because this can diffuse responsibility with vendors, platform owners, and application teams. The following chart shows a SRM within a cluster and introduces the tenant stakeholder. Traditional lines of responsibility between administrators and developers are blurring as more parts of the stack (such as databases and SaaS) are being absorbed by platforms like Kubernetes and cloud services. Deployments are unlikely to be uniform. At Red Hat, we see some tenants who want to take on more responsibility by adopting commercial off the shelf (COTS) operators, which they offer to their tenants, further diffusing and complicating the model. This means every cloud (cluster) could have its own SRM to communicate to tenants, helping them onboard customers and grow their cloud consumption.

Image

[ Plan your next cloud project based on your current cloud results. ]

An SRM for every cloud?

Ultimately, there is no clear SRM for every cloud. Every cluster or cloud is different. While SRMs could be derided as a "marchitecture," there is value in ensuring enterprise architects and cluster administrators have a coherent and supported operational framework for cloud and on-premises environments. As hybrid cloud deployments begin to offer more services to their tenants, clear communication between different stakeholders will be crucial in maximizing the promises of agility and cost savings.