The Cloud Shared Resource Model and the Cloud Service Model
When a business decides to consume public cloud resources from providers such as AWS, Azure and Google, there will be a shift in the way technology and service support teams operate in this new environment. SecOps and DevOps teams will need to change the way they support the “traditional” on-prem technology environments to now support the off-prem “cloud” technology environments. This is a paradigm shift that can not only be confusing to the support teams but can also potentially lead to business disruptions.
One simple example of this is when moving an application to a public could provider. There are several options when considering migration: lift-and-shift, refactor, reformat, or retire. For illustration purposes, let’s explore moving an application by “refactoring” it. A “high-impact” production application has been refactored to take advantage of cloud-based services. In its previous state the application was deployed in the company’s data center and was supported by several teams that had well established roles and responsibilities. The refactored application, now using cloud-based database services, is now part of a shared application landscape. The provider patches or updates the Data Base Management System (DBMS), updating certain ports. The databases supporting the application, hosted on the DBMS, were not updated synchronously, and the application goes off line. In contrast to this application operating on-premises where teams have unfettered access and complete control over all aspects of the environment, now there are new processes that causes some confusion and misalignment occurs on how teams support the migrated application. Sound familiar? This is an example of the potential confusion and misunderstandings that can arising, evidencing that coordination and delineation of responsibilities and duties must be actively managed when moving to the cloud.
Some cloud providers, such as AWS, have addressed this by developing what is referred to as the “Shared Responsibility Model”. This model is mostly representative from a “security perspective” and considers rather limited aspects of the operational support or management of off-prem cloud services.
The Open Alliance for Cloud Adoption (OACA) has recognized the need to capture the operational and management roles and responsibility of cloud resources. These pertain to operations and management in what the OACA is calling the “Cloud Shared Resource Model”.
The Open Alliance for Cloud Adoption is a member-led consortium of global technology organizations dedicated to easing the adoption of interoperable solutions and services addressing cloud computing for enterprises across the globe. https://www.oaca-project.org
Within this model are two distinct roles: cloud provider and cloud subscriber. For the purposes of this discussion we will use the NIST SP 500-292 (NIST Cloud Computing Reference Architecture) “The Cloud Provider and Cloud Consumer share the control of resources in a cloud system.”
It should be recognized that there exists a delineation of controls over the cloud model that will vary, depending on implementation used and consumption of services needed, and this will define the responsibilities of parties involved and help manage the cloud environment. In order for the cloud provider to provide adequate transaction capabilities sufficient requirements need to be identified. These requirements are usually in the form of KPI’s that are used to develop SLA’s to meet this demand.
The Cloud Shared Resource Model (CSRM)
Therefore, in order to create reliability of a service both the provider and the consumer need to identify the actors, i.e. technology teams, from both the cloud service provider and business technology consumer. This is critical in identifying the point where the roles and responsibilities change, called the “service transfer point”. The service transfer points between these teams are used to identify who has what role at what time. In order to align technology teams and service touch-points businesses will need to change the way they map responsibilities to different aspects of the business function. This process, also called the “Service Chain Transfer”, and is used to coordinate the service at the transfer points between the various parties. These parties can include various IT departments and support teams, the cloud service providers as well as SaaS providers. Layers of functions can range from network provision, through platform services, containerized services, microservices, security and data protection.
Defining the Model
In order to bring clarity to the way services are utilized, from both the provider and consumer perspective, we look to the “Cloud Service Model”. The cloud service model typically consists of three distinct things:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Software as a Service (SaaS)
However, there are many others that are becoming more prevalent in today’s business and technology cloud models, such as Backend as a Service, sometimes known as Function as a Service or (FaaS). Utilizing these services will dramatically change the way we look at security, development and operations.
Let’s look at an example, when looking at the Serverless Architecture model in which the cloud provider platforms dynamically manage the allocation of machine resources via “functions”, the Cloud Service Model no longer fits therefore roles and responsibilities need to shift. When implementing Function as a Service instructions are simply uploaded into the Cloud Service provider function service, such as ASW Lambda or Azure Functions, and is implemented. The needed resources to accomplish the task, compute, storage and network are all provisioned by the provider to enable execution of services. Providers are working to make this code agnostic and can be deployed by a variety of different ways depending on cloud model and platform of choice.
Cloud Service Model and Provider Services
- Software as a Service — Amazon WorkSpaces, Google’s G Suite and Microsoft’s Office 365, etc.
- Infrastructure as a Service — Amazon EC2, Azure VMs, Google Compute Engine, etc.
- Platform as a Service — Amazon Elastic Beanstalk, Azure Websites, Google App Engine, etc.
- Function as a Service — AWS Lambda, Azure Functions, Google Cloud Functions, etc.
Each service provides a different level of complexity and scale of operations. Below are examples of different models of each service and indicates who typically owns the responsibility.
Cloud Service Model
This abstraction, which occurs over various resources, will constitute various levels of responsibility by the provider. Interfaces need to be established and governance put in place that will enable alignment of service capabilities and consumption. Customers need reliable services and service models will need to be created to represent the levels of responsibility. This should map to the business function that drives service consumption.
Mapping Responsibility to Business Function
Mapping the level of responsibility to the appropriate level of consumption is paramount to service optimization. The same holds true for service support, management and operations. It is important to enable technology teams to have clear roles and concise responsibilities. This needs to be understood in order to provide and sustain the service optimization required to meet business function.
Generic Shared Control Model
So, from this model we can see there is a lot of sharing going on when using cloud-based services. Resources are distributed based on the subscription needs of the consumer. How these resources are operated, managed, supported and monitored influences the quality and sustainability of the services. At which point does the subscriber relinquish or accept control of the technology that is running their business.
The answer is “it depends….”
It will depend on a lot of things, not just what the Cloud Service Provider is offering, but may also depend on the cloud maturity* of the business. This will result in the businesses ability to define the level of consumption needed for the business to be successful.
The bottom line is when a business decides to consume public cloud resources there will be a shift in the way technology and service support teams operate. SecOps, DevOps, TechOps, etc., will need to align with the cloud service model, sometimes in unique and profound ways. Scale and consumption can weigh heavily on teams especially when looking at supporting cloud-based solutions which can natively provide elasticity, scale on demand, and enable out-of-the-box features like cloud bursting and high availability.
The hyper connected enterprise is enabling the hyperconvergence of people, process and technology in unforeseen ways. Staying ahead of the curve is “almost” impossible. Until businesses do a self-retrospect of their capabilities to consume and support cloud it will continue to pose a potential for disruption.