Chapter 10. Common Compound Patterns

This chapter provides some of the more common and important combinations of the patterns documented in previous chapters. Each such combination is classified as a compound design pattern.

The patterns in this chapter are referred to as “compound patterns” because they document the effects of applying multiple patterns together. One of the most interesting parts of this exploration is that certain combinations of patterns result in design solutions that we are already familiar with.

The compound patterns with patterns that are jointly applied are:

• Cloud Bursting (492)

• Burst Out to Private Cloud (493)

• Burst Out to Public Cloud (496)

• Burst In (499)

• Secure Burst Out to Private Cloud/Public Cloud (501)

• Cloud Balancing (503)

Alternatively, the patterns that comprise a compound pattern can represent a set of related features provided by a particular program or environment. In this case, a coexistent application of patterns establishes a “solution environment” that may be realized by a combination of tools and technologies.

Compound patterns comprised of patterns that coexist to establish such an environment are:

• Private Cloud (474)

• Public Cloud (476)

• Software-as-a-Service (478)

• Platform-as-a-Service (480)

• Infrastructure-as-a-Service (482)

• Elastic Environment (484)

• Multitenant Environment (486)

• Resilient Environment (490)

• Cloud Authentication (505)

• Resource Workload Management (506)

The same “hierarchy style” notation is used to express compound patterns comprised of patterns that are jointly applied and those applied in a coexistent manner.

A private cloud is distinguished by its ownership by a single organization. From a technology architecture perspective, private clouds can be explored as single or multitenant environments. Multitenant variations of private clouds can exist (as per the Multitenant Environment (486) member pattern).

Some multitenant private clouds have a higher tendency of resembling Public Cloud (476). Note that despite its limited ownership, IT resources that are assembled to comprise a private cloud environment may belong to the organization acting as a cloud provider or they may be leased from an external service provider.

The Private Cloud compound pattern is comprised of the following core patterns:

• Automated Administration (310)

• Centralized Remote Administration (315)

• Resource Management (320)

• Self-Provisioning (324)

• Usage Monitoring (285)

• Broad Access (93)

• Realtime Resource Availability (292)

• Shared Resources (17)

• Workload Distribution (22)

• Resource Pooling (99)

• Rapid Provisioning (295)

• Elastic Environment (484)

• Resilient Environment (490)

• Multitenant Environment (486)

As indicated by the dashed lines in the preceding hierarchical diagram, the following extension patterns are part of the Private Cloud compound pattern:

• Bare-Metal Provisioning (305)

• Non-Disruptive Service Relocation (159)

• Pay-as-You-Go (288)

These optional patterns can be applied to enhance the functions and feature-sets of a private cloud environment. For example, they may represent extensions required by particular cloud consumers.

The Public Cloud compound pattern encompasses the patterns that comprised Private Cloud (474), and further expands upon the private cloud feature-set to provide multitenant functions in support of a broader range of diverse cloud consumers. Key aspects that distinguish the public cloud are its emphasis on resource sharing, billing, and the isolation of cloud consumer trust boundaries.

The administration of larger pools of IT resources that are unpredictably accessed and utilized by different cloud consumers can become a significantly more complex responsibility for public cloud providers.

The Public Cloud compound pattern is comprised of the following core patterns:

• Shared Resources (17)

• Resource Pooling (99)

• Rapid Provisioning (295)

• Workload Distribution (22)

• Centralized Remote Administration (315)

• Usage Monitoring (285)

• Pay-as-You-Go (288)

• Realtime Resource Availability (292)

• Self-Provisioning (324)

• Resource Management (320)

• Automated Administration (310)

• Broad Access (93)

• Elastic Environment (484)

• Resilient Environment (490)

• Multitenant Environment (486)

• Isolated Trust Boundary (508)

The Public Cloud compound pattern further contains the following extension patterns:

• Resource Reservation (106)

• Bare-Metal Provisioning (305)

• Non-Disruptive Service Relocation (159)

An SaaS implementation is the equivalent of a cloud-based service or application, owned by the cloud provider and made available to cloud consumers. Cloud consumers are not granted any significant control of the SaaS environment or its IT resources.

As with a PaaS environment, an SaaS implementation can be single-tenant but is more commonly multitenant. When part of multitenant environments, the application data, application profile, and/or database of each tenant is commonly hosted separately and isolated from each other. A single SaaS deployment is typically shared by multiple cloud service consumers, each of which is provided with its own runtime service instance.

The SaaS compound pattern is comprised of the following core patterns:

• Automated Administration (310)

• Self-Provisioning (324)

• Shared Resources (17)

• Usage Monitoring (285)

• Pay-as-You-Go (288)

• Broad Access (93)

• Dynamic Scalability (25)

• Realtime Resource Availability (292)

• Rapid Provisioning (295)

• Workload Distribution (22)

• Resource Management (320)

• Centralized Remote Administration (315)

• Multitenant Environment (486)

The SaaS compound pattern further contains the Non-Disruptive Service Relocation (159) and Resource Reservation (106) extension patterns.

As with an IaaS environment, a PaaS environment is comprised of a collection of IT resources made available to a cloud consumer. The PaaS environment is distinguished by being more controlled, pre-defined, and primarily limiting cloud consumer usage and administration to tasks pertaining to the development and deployment of cloud services and cloud-based solutions.

A PaaS environment, by its nature, is most commonly used as part of a multitenant environment. However, single-tenant implementations are also allowable. Similarly, a PaaS can be implemented as part of a private cloud, but it is more commonly made available via a public cloud.

The PaaS compound pattern is comprised of the following core patterns:

• Platform Provisioning (301)

• Service State Management (61)

• Self-Provisioning (324)

• Centralized Remote Administration (315)

• Shared Resources (17)

• Usage Monitoring (285)

• Pay-as-You-Go (288)

• Broad Access (93)

• Workload Distribution (22)

• Resource Pooling (99)

• Realtime Resource Availability (292)

• Rapid Provisioning (295)

• Dynamic Scalability (25)

• Resource Management (320)

• Automated Administration (310)

• Multitenant Environment (486)

• Isolated Trust Boundary (508)

The PaaS compound pattern further contains the Resource Reservation (106) and Non-Disruptive Service Relocation (159) extension patterns.

The IaaS compound pattern builds upon the architectural layers established by Private Cloud (474) and Public Cloud (476) to provide a concrete environment that offers raw IT resources (virtual and, optionally, physical) for open and independent usage and management by cloud consumers.

The member patterns of the IaaS compound pattern represent feature-sets, as provided to individual cloud consumers. Note that cloud consumers of commercial IaaS products are often able to choose the feature-set they will actually lease.

The IaaS compound pattern is comprised of the following core patterns:

• Multipath Resource Access (127)

• Workload Distribution (22)

• Dynamic Scalability (25)

• Broad Access (93)

• Rapid Provisioning (295)

• Centralized Remote Administration (315)

• Realtime Resource Availability (292)

• Resource Management (320)

• Automated Administration (310)

• Shared Resources (17)

• Resource Pooling (99)

• Pay-as-You-Go (288)

• Self-Provisioning (324)

• Usage Monitoring (285)

• Multitenant Environment (486)

The IaaS compound pattern further contains the Bare-Metal Provisioning (305) extension pattern.

The Elastic Environment compound pattern represents a collection of patterns that coexist in an environment to provide the dynamic feature-set required to realize the elasticity characteristic of a cloud.

This compound pattern is a member pattern of the following compound patterns:

• Private Cloud (474)

• Public Cloud (476)

The Elastic Environment compound pattern is comprised of the following core patterns:

• Elastic Resource Capacity (37)

• Elastic Network Capacity (42)

• Elastic Disk Provisioning (45)

• Storage Workload Management (64)

• Intra-Storage Device Vertical Tiering (81)

• Cross-Storage Device Vertical Tiering (74)

• Workload Distribution (22)

• Usage Monitoring (285)

• Rapid Provisioning (295)

• Resource Pooling (99)

The Elastic Environment compound pattern further contains the following extension patterns:

• Direct I/O Access (169)

• Direct LUN Access (173)

• Dynamic Data Normalization (71)

• Resource Reservation (106)

• Redundant Storage (119)

• Service Load Balancing (32)

The Multitenant Environment compound pattern represents a collection of patterns that co-exist in a physical environment to provide the feature-set required to realize the multitenancy characteristic of a cloud.

This compound pattern is a member pattern of the following compound patterns:

• Private Cloud (474)

• Public Cloud (476)

• PaaS (480)

• SaaS (478)

The Multitenant Environment compound pattern is comprised of the following core patterns:

• Shared Resources (17)

• Resource Pooling (99)

• Isolated Trust Boundary (508)

...and the following extension pattern:

• Resource Reservation (106)

Compound patterns that include Multitenant Environment as a member pattern usually share some or all of its four member patterns. This redundancy is intentional, as the Multitenant Environment compound pattern combines its member patterns to form a distinct (compound) feature-set that can act independently from when the features of its member patterns are applied separately.

Multitenancy is sometimes mistaken for virtualization because the concept of multiple tenants is similar to the concept of virtualized instances. The differences lie in what is multiplied within a physical server acting as a host:

• Virtualization: Multiple virtual copies of the server environment can be hosted by a single physical server. Each copy can be provided to a different user, can be configured independently, and can contain its own operating system and applications.

• Multitenancy: A physical or virtual server hosting an application is designed to allow usage by multiple different users. Each user feels as though they have exclusive usage of the application.

Because the Multitenant Environment compound pattern includes the Resource Pooling (99) and Shared Resources (17) patterns, it inherits their respective and cumulative risks:

• overlapped trust boundary

• resource constraints

These concerns are mitigated by the application of the following patterns:

• Isolated Trust Boundary (508)

• Resource Reservation (106)

The following steps are shown in Figures 10.8 and 10.9:

1. The cloud provider selects and groups the underlying shared resources based on requirements dictated by its cloud consumers. The cloud provider then creates a resource group.

2. A parent-level resource pool is created from the resource group and a smaller resource pool is created for each cloud consumer. Each set of resources is allocated from the parent resource pool.

3. Cloud services designated for sharing to cloud consumers can be shared.

4. Any cloud consumer-specific or dedicated cloud services and IT resources are allocated.

5. Each cloud consumer is given a dedicated administration portal and service catalog access.

The Resilient Environment compound pattern represents a collection of patterns that coexist in a physical environment to provide the failover feature-set required to realize the resiliency characteristic of a cloud.

This compound pattern is a member pattern of the following compound patterns:

• Private Cloud (474)

• Public Cloud (476)

The Resilient Environment compound pattern is comprised of the following core patterns:

• Redundant Storage (119)

• Dynamic Failure Detection and Recovery (123)

• Redundant Physical Connection for Virtual Servers (132)

• Service Load Balancing (32)

• Load Balanced Virtual Switches (57)

• Synchronized Operating State (138)

• Hypervisor Clustering (112)

• Usage Monitoring (285)

• Rapid Provisioning (295)

• Workload Distribution (22)

The Resilient Environment compound pattern further contains the following extension patterns:

• Storage Maintenance Window (147)

• Zero Downtime (143)

Cloud Bursting is a specialized cloud architecture that allows IT resources to scale from on-premise environments to clouds, based on pre-defined usage thresholds. When documented as a design pattern, Cloud Bursting is defined as a compound pattern that is comprised of two primary compound patterns:

• Burst Out to Private Cloud (493) or Burst Out to Public Cloud (496)

• Burst In (499)

Each of these two patterns can be applied as part of a cloud bursting architecture, or independently as part of other forms of cloud architecture.

“Bursting out” enables one environment to dynamically scale (burst) IT resources to another environment. The bursting out cloud architectures explored in this section are specific to bursting out from an on-premise environment to a cloud environment. There are two variations of this compound pattern that depend on whether bursting out occurs to a private cloud or public cloud:

• Burst Out to Private Cloud (493)

• Burst Out to Public Cloud (496)

Burst Out to Private Cloud is a compound pattern comprised of the following patterns:

• Elastic Resource Capacity (37)

• Rapid Provisioning (295)

• Persistent Virtual Network Configuration (227)

• Automated Administration (310)

• Usage Monitoring (285)

• Redundant Storage (119)

• Dynamic Scalability (25)

• Workload Distribution (22)

This pattern further contains the following optional patterns:

• Resource Reservation (106)

• Resource Pooling (99)

• Multitenant Environment (486)

• Service Load Balancing (32)

• Cross-Storage Device Vertical Tiering (74)

Figure 10.13 illustrates a typical burst out from an on-premise environment to a private cloud in the following steps:

1. The cloud consumer requests that are monitored by an automated scaling listener begin to increase in volume.

2. The automated scaling listener detects that received requests have exceeded the pre-defined usage threshold.

3. The automated scaling listener initiates the burst out scaling by signaling to the resource replication mechanism for more instances of the cloud service.

4. The resource replication mechanism calls the intelligent automation engine in the private cloud to automate the generation of more instances.

5. The system established by the application of Rapid Provisioning (295) executes the creation of more requested instances of the cloud service.

6. A load balancer can be optionally incorporated to automatically forward subsequent cloud consumer messages to cloud service instances while bursting remains active.

Burst Out to Public Cloud is a compound pattern comprised of the same patterns as Burst Out to Private Cloud (493), except that the following patterns are no longer optional:

• Multitenant Environment (486)

• Resource Pooling (99)

• Resource Reservation (106)

Architecturally, bursting to a public cloud is similar to bursting to a private cloud with the exception of the multitenancy characteristics that the public cloud must accommodate to ensure that occurrences of bursting out do not impact other cloud consumers or IT resources.

Figure 10.15 illustrates the steps to executing a burst out from an on-premise environment to a public cloud. The step descriptions are almost identical to performing a burst out to a private cloud, as listed under Burst Out to Private Cloud (493). The primary difference is that the multitenant architecture encompasses a resource pool.

“Burst In” is the counterpart to the aforementioned “Burst Out” compound patterns, in that it is a compound pattern that establishes a system that retracts IT resources from an environment that has reached a low level of utilization. A cloud can burst in to an on-premise environment or to another cloud.

The Burst In compound pattern is comprised of the following core patterns:

• Automated Administration (310)

• Usage Monitoring (285)

• Resource Pooling (99)

It also includes the following extension pattern:

• Cross-Storage Device Vertical Tiering (74)

While the patterns are the same when bursting in from a private or public cloud, the resultant scenarios can differ. Figure 10.17 shows a private cloud architecture wherein the Burst In pattern is applied, as follows:

1. Reduced cloud service consumer requests are received.

2. The automated scaling listener determines that the reduction in usage warrants a burst in via the scaling in of cloud services.

3. The automated scaling listener signals the intelligent automation engine to delete the cloud service instances that were previously replicated and provisioned as a result of the burst out.

4. The intelligent automation engine runs a script that interacts with the rapid provisioning program to delete the cloud service instances.

Secure Burst Out to Private Cloud/Public Cloud is a compound pattern that provides additional features for the purpose of securing the cloud architecture resulting from the application of Burst Out to Private Cloud (493) or Burst Out to Public Cloud (496). Cloud bursting requires confirmation of the security level of cloud resources and access privileges, security level of the associated communications channels, and secure authentication of cloud consumers and providers.

When Burst Out to Private Cloud (493), Burst Out to Public Cloud (496), and Burst In (499) are combined, a cloud architecture supporting bi-directional bursting is established.

In order to securely burst out to public or private clouds:

• The cloud platforms need to be confirmed to be at the security assurance level required by the workload and the cloud consumer needs access privileges.

• The network connecting the cloud consumer and prospective cloud platforms needs to be secure to the required assurance level.

• The endpoints involved need to authenticate each other to the required security assurance level.

The Secure Burst Out to Private Cloud/Public Cloud compound pattern is composed of the following required patterns:

• Cloud Authentication Gateway (430) – Enables initiating and receiving endpoints for communications to mutually authenticate.

• Trust Attestation Service (448) – Confirms the security assurance level of compute platforms and compute pools and makes the information available to properly authenticated consumers.

• Secure Connection for Scaled VMs (409) – Ensure that an encrypted and authenticated communications channel is established for scaling of virtual machine compute platforms.

• Trusted Platform BIOS (337) – Has been established to a specified security assurance level through a trusted boot process.

The following member patterns are considered optional extensions:

• Geotagging (341) – Enables workload orchestration services to confirm the proper location of compute resources.

• Trusted Cloud Resource Pools (354) – Have aggregated trusted compute platforms of the same security assurance levels if the workload requires them.

• Cloud Resource Access Control (364) – Uses attributes of the cloud consumer to determine if they have the privileges to access the resource.

It is assumed that the original on-premise resources and workload have been properly secured. If anything changes at any time during the burst out or burst in process, confirming the security of any new platform and required authorizations, connections, and authentication of endpoints must always be accomplished.

The Cloud Balancing pattern establishes a specialized cloud architecture in which IT resources can be load-balanced across multiple clouds. The benefits of a cloud-balanced architecture lie in the improved performance and efficiency of balanced IT resources. Cloud balancing can also be implemented to improve IT resource availability, whereby failed instances of IT resources are balanced by having cloud consumer requests automatically forwarded to redundant instances on another cloud.

The Cloud Balancing compound pattern is comprised of the following core patterns:

• Load Balanced Virtual Server Instances (51)

• Service Load Balancing (32)

• Rapid Provisioning (295)

• Hypervisor Clustering (112)

• Automated Administration (310)

• Elastic Resource Capacity (37)

• Redundant Storage (119)

• Redundant Physical Connection for Virtual Servers (132)

• Storage Workload Management (64)

• Persistent Virtual Network Configuration (227)

• Workload Distribution (22)

The application of this pattern results in a security management system with feature-sets that correspond to the application of the following required pattern:

• Cloud Authentication Gateway – With respect to authentication and access management, Cloud Authentication Gateway (430) provides for the authentication of cloud consumers as a necessary security step before presenting the consumer to the requested cloud resources’ access control mechanisms. The access control mechanisms can be assured that a cloud consumer is who they claim to be, to the required level of security assurance, as they render an access control decision.

The following pattern is considered an optional extension:

• Federated Cloud Authentication – When business partners are sharing information, Federated Cloud Authentication (436) provides for authentication of a federation of credentials in support of the authentication portion of the compound pattern.

This compound pattern represents an environment that ensures that workloads are distributed in a manner that minimizes over-utilization and under-utilization while maximizing resource usage and efficiency.

This compound pattern is comprised of the following patterns:

• Load Balanced Virtual Server Instances – This pattern is responsible for distributing virtual servers across the hypervisors, based on the required computing capacity of each virtual server. This ensures that none of the hypervisors are over-utilized or under-utilized.

• Storage Workload Management – This pattern considers the amount of I/O throughout and data processing required by each cloud consumer, service, application, and virtual server being hosted in storage, in order to balance the workloads between cloud storage devices for even distribution.

• Load Balanced Virtual Switches – This pattern is applied to prevent congestion and bottlenecking on the virtual switch’s physical uplinks.

The following pattern is considered an optional extension:

• Automated Administration – When Automated Administration (310) is applied with the use of the automated scaling listener mechanism, the automated administration system can initiate the workload to add another physical uplink whenever the load is increasing and there are no standby physical uplinks.

The Isolated Trust Boundary is foundational to the multitenancy characteristic of the cloud. This pattern is primarily comprised of security and virtualization patterns that combine to prevent overlapping trust boundaries in a multitenant implementation.

The attribute of being trusted means being verified to a level of assurance and confidence that the information originator, information recipient, processing, and networking meet security requirements. The security assurance level is the measure of confidence that the security functions, features, practices, policies, procedures, mechanisms, and architecture of organizational information systems accurately mediate and enforce established security policies. Specific assurance-related security controls embodied in these patterns can be implemented by organizations based on the security requirements of their information systems. The member patterns must be applied to the security assurance level required by the organization.

Executing trusted workloads in a multitenant environment requires confirmation of the security level of cloud-based IT resources and access privileges, confirmation of the security level of the associated communications channels, and secure authentication of cloud consumers and providers.

The aforementioned requirements are typically achieved as follows:

• All cloud consumer and provider endpoints for a workload execution must be authenticated to the required level of assurance.

• Compute platforms involved in workload execution must be secured to the required level of assurance.

• Networks connecting endpoints involved in workload execution must be secured to the required level of assurance.

• Monitoring, logging, and alerting provide alerts to transaction anomalies and create audit trails to establish trustworthiness and accountability for a transaction.

The Isolated Trust Boundary compound pattern is comprised of the following patterns:

• Cloud Authentication Gateway (430) – This pattern enables initiating and receiving endpoints to mutually authenticate communication.

• Cloud Resource Access Control (364) – This pattern uses attributes of the cloud consumer to determine if they have the privileges to access the resource.

• Cloud VM Platform Encryption (350) – This pattern ensures that VM backups, snapshots, and live migration create files of the organization’s VMs and are kept secure from data leakage.

• Cloud Key Management (444) – Encryption is foundational to security, and key management is critical to managing an organization’s encryption keys.

• Collaborative Monitoring and Logging (452) – This pattern allows cloud consumers and providers to establish the required information to ensure the organization is meeting its industrial compliance requirements.

• Hypervisor Protection (344) – This pattern ensures the hypervisor, whose security is essential for the VMs it manages, is kept secure.

• In-Transit Cloud Data Encryption (391) – This pattern ensures that data traveling between the organization and cloud and between cloud services is protected at the network level.

• Trust Attestation Service (448) – This pattern confirms the security assurance level of compute platforms and compute pools for execution of a trusted workload.

• Trusted Cloud Resource Pools (354) – This pattern aggregates trusted compute platforms of the same security assurance levels as required by the workload.

• Trusted Platform BIOS (337) – This pattern establishes the specified platform security assurance level through a trusted boot process.

• Secure Cloud Interfaces and APIs (360) – This pattern ensures that cloud services require authentication to the proper level of assurance.

The following patterns are considered optional extensions:

• Automatically Defined Perimeter (425) – This pattern establishes protected communications between cloud consumers and providers.

• Geotagging (341) – This pattern enables workload orchestration services to confirm the proper location of compute resources.

• Federated Cloud Authentication (436) – This pattern allows a federation of organizations to interoperate by trusting and authenticating each other’s credentials.

• Independent Cloud Auditing (460) – This pattern provides attestation to industry regulatory authorities that the organization is meeting their security and privacy responsibilities.

• Secure Connection for Scaled VMs (409) – Whether or not scaling is involved, the pattern ensures that an encrypted and authenticated communications channel is established between virtual machine compute platforms.