The Cloud Platform Integration Framework (CPIF) provides workload integration guidance for onboarding applications into a Microsoft Cloud Solution. CPIF describes how organizations, Microsoft Partners and Solution Integrators should design and deploy Cloud-targeted workloads utilizing the hybrid cloud platform and management capabilities of Azure, System Center and Windows Server
Table of Contents
Joel Yoker – Microsoft
David Ziembicki – Microsoft
Tom Shinder – Microsoft
Cloud Platform Integration Framework Overview and Patterns:
The Cloud Platform Integration Framework (CPIF) provides workload integration guidance for onboarding applications into a Microsoft Cloud Solution. CPIF describes how organizations, Microsoft Partners and Solution Integrators should design and deploy Cloud-targeted workloads utilizing the hybrid cloud platform and management capabilities of Azure, System Center and Windows Server. The CPIF domains have been decomposed into the following functions:
Figure 1: Cloud Platform Integration Framework
By integrating these functions directly into workloads, “platforms” can be developed which allow for further configuration by tenants to implement extended software services.
Both public and private cloud environments provide common elements to support the running of complex workloads. While these architectures are relatively well understood in traditional on-premises physical and virtualized environments, the constructs found within the Microsoft Azure require additional planning to rationalize the infrastructure and platform capabilities found within public cloud environments. To support the development of a hosted application or service in Azure, a series of patterns are required outlining the various components required to compose a given workload Solution. These architectural patterns fall within the following categories:
- Infrastructure – Microsoft Azure is an Infrastructure- and Platform-as-a-Service Solution which is comprised of several underlying services and capabilities. These services largely can be decomposed into compute, storage and network services, however there are several capabilities which may fall outside of these definitions. Infrastructure patterns detail a given functional area of Microsoft Azure which is required to provide a given service to one or more Solutions hosted within a given Azure subscription.
- Foundation – When composing a multi-tiered application or service within Azure, several components must be used in combination to provide a suitable hosting environment. Foundation patterns compose one or more services from Microsoft Azure to support a given layer of functionality within an application. This may require the use of one or more components described in the infrastructure patterns outlined above. For example, the presentation layer of a multi-tier application requires compute, network and storage capabilities within Azure to become functional. Foundation patterns are meant to be composed with other patterns as part of a given Solution.
- Solution – Solution patterns are composed of infrastructure and/or foundation patterns to represent an end application or service being developed. It is envisioned that complex solutions would not be developed independently of other patterns. Rather, they should utilize the components and interfaces defined in each of the pattern categories outlined above.
This spectrum of patterns is illustrated in the model below.
Figure 2: CPIF Architecture Model
It is expected that architectural patterns for cloud-hosted workloads (applications and services) would generally adhere to this model and complex scenarios can be implemented using one or more of the pattern types outlined above. This document will provide an overview of the key architectural pattern concepts and outline some of the supporting constructs found within each architectural pattern type.
To support the development of Solution architectures within Azure, a series of pattern guides are provided for common scenarios. While these scenario guides will be constructed over time, some envisioned patterns include:
- Global Load Balanced Web Tier
- Load Balanced Data Tier
- Batch Processing Tier
- Azure Networking
- Azure Search
Each architectural pattern will have the following areas covered in their respective pattern guide:
Requirements or Service Description – This section will describe the pattern requirements and outline the service description including the desired service level target (SLT). The SLT (measured in percent uptime) is rationalized across Microsoft Azure architectural constructs to support the number of planned and unplanned failures across Azure regions, within an Azure datacenter, and across Azure virtual machines which can be supported within a year and to still meet the Service Level Agreement (SLA) target. As described before, the architectural patterns are expected be composed with other tiers to support a larger Solution architecture or design patterns.
Architectural Diagrams – Each pattern will include an architectural diagram outlining at a high level the Azure services or constructs required to support the pattern. While pattern diagrams may differ slightly in composition, they are expected to be used together to visually represent the required elements to implement desired workload functionality.
An example diagram is provided below.
Figure 3: Example Pattern Architectural Diagram
Architectural Dependencies – This section will outline any Azure dependencies which can impact the construction of an application or service built using the pattern design. Foundational and infrastructure patterns are not expected to have dependencies on other patterns themselves, however Solution patterns will by their very nature require a series of dependent patterns to bring a given service or capability online.
Required Azure Services – As described earlier, Microsoft Azure is comprised of a series of services which provide discrete capabilities to a hosted application or service. Each pattern will list out the required Azure services utilized by the pattern (e.g. virtual machines, storage accounts and traffic manager) to support a given pattern.
Pattern Considerations – For a given architectural pattern, this section will outline any design limitations or considerations that may impact the pattern such as required or expected extensions to Azure default limits, potential service bottlenecks and other considerations with regards to the services required to deliver the workload.
Interfaces and End Points – This section outlines any internal or external interfaces and Windows Azure end points the pattern utilizes. It will contain any required or optional ACLs or other settings specific to the pattern.
Availability and Resiliency Considerations – Given that a particular pattern may require one or more Azure services, the availability and resiliency factors for the design pattern are outlined in this section. Examples include use of availability groups, update domains, or regions. This section will identify constructs which assist with helping make sure the pattern is resilient to any expected fault conditions or scenarios. This section will also outline the composite SLA for the pattern. For each Azure service utilized, the current SLA and measurement factors will be outlined for each service utilized then determine the composite SLA provided by the entire pattern since the combination of two or more Azure service-level Service Level Agreements (SLAs) might result in a lower overall SLA for composed pattern.
Scale and Performance Considerations – This section will describe minimum number of instances to meet performance requirements (minimum and maximum). It is intended to document any performance requirements during fault conditions and outline any use of autoscale or automation rules to support maintaining acceptable performance criteria.
Cost Considerations – Cost is one of the primary considerations when constructing a Solution within Microsoft Azure. This section of each pattern guide outlines costs in two sections:
- Cost factors
- Cost drivers
For cost factors, the high level cost model and measurement (e.g. Cost per hour for virtual machines) is outlined for each service. While not capturing these costs exactly due to inevitable changes in the market, it is intended to simply capture the services utilized by the pattern and how each is measured from a cost perspective.
Cost drivers impact on the overall cost of the design pattern. Examples include the number of active virtual machines, or the type of storage utilized. This section outlines tradeoffs such as using fewer larger virtual machines vs. a larger number of smaller virtual machines or the use of geographically replicated storage vs. locally replicated. Each factor should is outlined in terms of its impact on the cost of the pattern and is intended to drive a culture of considering cost during architectural planning.
Figure 4: CPIF Pattern Cost Consideration Illustrated Example
Architectural Anti-Patterns – As with any architectural design there are both recommended practices and approaches which are not desirable. This section of each pattern guide briefly lists any solutions or approaches to the given problem that should not be pursued.
Operational Considerations – This section is intended to help make sure that architectural patterns using the Cloud Platform Integration Framework (CPIF) are “designed for operations”, which covers the CPIF areas such as deployment, monitoring, maintenance and business continuity/disaster recovery (BC/DR).
Operational considerations will describe:
- Methods for this pattern to be instantiated
- How the pattern will integrate with monitoring solutions
- Critical metrics that must be monitored for the pattern
- Alert thresholds or triggers
This section will also describe how the pattern will integrated with software updating solutions. It will briefly outline the BC/DR requirements and options for the design pattern and any operations management implications of the design pattern.
It is envisioned that the Cloud Platform Integration Framework can be leveraged as part of any Solution development using Microsoft Azure. As outlined above, CPIF defines infrastructure functional areas in order to describe the management services it provides in a way that application development or deployment teams can consume and utilize in their application development process. This guide is intended to outline the common areas of Azure architecture and how to consume the architectural pattern guides. The CPIF architectural pattern guides themselves are intended to be concise, composable architectural pattern guides which provide guidance around required services and automation for ease of construction.
When used as part of a comprehensive approach, other key areas required by the workloads may also be addressed during the design of a given application or service in Microsoft Azure.
Architectural planning is a required element of any cloud-based workload deployment and therefore is a core functional area of the Cloud Platform Integration Framework (CPIF). This document is meant to serve as a framework for applying Azure architectural concepts in workload planning and design for public and hybrid cloud environments. These concepts and capabilities can be applied to various applications and services and therefore require analysis of each workload’s capabilities and support for the constructs. Along with this guide, a series of infrastructure, foundational and Solution architectural pattern guides are available to assist with the practical application by various workloads in Microsoft Azure.