As organizations move beyond their initial cloud deployments and application migrations, many are looking to diversify into a multi-cloud strategy to enable teams to access specialized capabilities available from different providers. The shift to multi-cloud adoption for supporting IaaS and PaaS capabilities is a critical milestone that an organization must evaluate, plan for and ensure they can take on the additional operational burden and skill set requirements. Many organizations have already adopted different cloud providers through the use of SaaS offerings. This paper will focus on the organizational adoption of cloud platforms supporting IaaS and PaaS, commonly used to migrate infrastructure and applications from traditional data centers. The three most common players in this cloud platform space are AWS, Azure and Google.
Initial cloud deployments typically focused on leveraging a single cloud platform. This early simplicity allowed organizations to build up their operational capabilities with a cloud-centric model, without the added strain of training multiple sets of new skills across the enterprise. This single cloud approach also made choosing third-party software much simpler, since there was a lack of multi-cloud support in many early third-party products. Organizations also used this single vendor approach to provide leverage in contract negotiations to gain cost advantages for first-movers.
Once an organization has established its cloud presence and built an operational model around cloud based applications, it commonly looks to expand to additional cloud platforms to diversify the capabilities available to its teams. Some of the most common triggers to adding platforms are:
- Specialized application teams require a capability that is unique to one cloud provider
- Security and governance posture is mature enough to support a second provider
- The organization’s Minimum Viable Cloud (MVC) is clearly defined to enable like-for-like functionality and protections across cloud platforms
- Specific cost advantages can be achieved by targeting different cloud providers with different workloads
As we begin to make the transition from a single cloud platform to multiple ones, several areas of consideration are key to ensuring scalability, stability and operational excellence. These include: Architecture, Operations, Vendor Management and Third-Party Tooling. Each of these categories will have unique requirements for staffing, planning and investment ahead of a multi-cloud adoption, to ensure continued acceleration in the successful adoption of IT resources.
Architectural changes will be required to support multiple cloud platforms. The most important decision to be made early in the adoption process is the level of portability targeted between providers, versus the need for specialized, advanced capabilities only available on some providers’ platforms.
The MVC is an important concept when defining the functional requirements and technical implementations for an organization’s use of public cloud providers. Functional MVC requirements should stay uniform across all cloud deployments, providing a consistent level of capability in multi-cloud deployments. The MVC technical implementation will then vary based on provider capabilities and specific architectural implementations.
As the use of multiple cloud vendors matures, the MVC will mature to add additional functionality. The goal with multi-cloud deployments is consistency across vendors, with equivalent connectivity and access, allowing staff to fully utilize the unique capabilities any vendor may provide. Figure 1 shows the common elements that go into building an MVC and a typical phased approach for assessment and implementation.
Operations often becomes the largest investment in a multi-cloud deployment. Staff will require additional training, skills and expertise to effectively manage all cloud platforms beyond a single vendor. Before the adoption of multiple cloud platforms, a mature CloudOps model with a single cloud vendor must be in place. This strong model will ensure that there are both mature processes and mature capabilities to build upon internally as additional platforms are added.
Figure 2 shows the seven key guiding principles of a mature CloudOps strategy:
Limit the blast radius – Limiting the blast radius is the operational method we use for isolation and separation, to ensure that an outage, security incident or upgrade does not affect other, unrelated systems.
Enable cost transparency – The key to cloud economics is full awareness of the spending patterns, and automatic response to balance cost and service availability. A strong CloudOps model will ensure that tools are available for all users to see their spend, understand key architectural decisions and receive notification if spending is growing more rapidly than expected.
Minimize complexity – Complexity leads to added costs through the added difficulty of supporting and responding to incidents. Mature cloud implementations will minimize complexity through standard microservices, standard technology stacks and standard communication paths between applications.
Maintain compliance – Many organizations function in domains with standard models for compliance and regulation. Even the most complex of these standards can often be met using public cloud providers; automation is the key to ensuring deployments are compliant and changes do not affect the security and compliance posture of an organization.
Secure access – Security in the cloud should not be an afterthought; it should be part of every plan and implementation, to ensure data is protected at all times and risk to an organization is minimized and managed.
Increase developer agility – The ultimate goal of cloud computing is the rapid adoption of new technologies to give companies a business advantage. At the heart of this is the ability for developers to quickly build and deploy new capabilities, without being held back by slow deployments of IT assets.
Increase resiliency posture – The major cloud vendors all have large, global footprints. This unique capability, which many organizations could not afford, provides a large, scalable platform to build dispersed, highly available systems. Using native capabilities in the cloud can allow organizations to quickly deploy applications with higher levels of availability than possible when deploying in small numbers of data centers.
Security implementation should be planned to ensure that the addition of multiple cloud vendors does not add additional risk or minimize visibility for the organization’s security posture and response. Security has several key categories that must be addressed uniformly across cloud providers:
Policy – Policy is the set of organizational guidelines that control how the business functions, the levels of risk taken, processes followed and rules for data handling. The policy for an organization will not change and will be applied uniformly across cloud providers.
Controls – Controls are the process-based implementations of the policy. The controls are workflows, checks and approvals to ensure that policy is being followed. Controls are commonly seen as passwords, access control lists and other boundaries to allow and prevent access to data and services. Controls will be broadly the same across cloud platforms, with only minor differences to account for technology differences between vendors.
Technical Implementation – Controls are implemented through technology, so this tier can vary significantly from vendor to vendor because of differences in how they provide services and access to them. This technical implementation will be a major component of the MVC and architectural elements in the cloud, ensuring that a strong platform is built for the organization to safely consume services within corporate policy.
Governance – Governance is the enforcement of policies across technology and cloud platforms. While governance can be a manual process to validate that policy is being followed, it should be automated in a cloud environment, to maximize agility for users of the cloud platform.
Multi-cloud strategies introduce a new dynamic for vendor management. Many cloud providers will offer credits tied to the level of spend on their specific platform. By choosing a multi-cloud strategy, you risk splitting the credits or losing them entirely. Multi-cloud strategies must constantly be evaluated against the potential spend of all IT capacity needs, to ensure that if additional spend comes from using multiple vendors, it will be offset by additional capabilities valuable to the business.
In addition to vendor management for platforms, many cloud implementations require using new third-party tools and services. These third party tools provide organizations with the ability to manage capabilities across vendors, as well as add additional governance and management features not natively available on providers’ platforms.
Third-party tools should be carefully assessed to ensure they have a pricing model that fits with organizational usage patterns. This pricing model should complement a strong set of capabilities and a long-term roadmap to continue to add value to the product, post initial investment. The most common third-party tools are used to support financial management and visibility to individual business units, and governance and enforcement of security policies.
Adopting a multi-cloud strategy should be a methodical process for an organization. A careful assessment of the added cost and complexity should be weighed against the added benefits a new or specialized provider will bring to the organization through greater agility and added capabilities. Prior to deploying a second cloud platform, you should architect an MVC to ensure parity for functional capability and the strong enforcement of security policies. Multi-cloud adoption can enable an organization to leverage best of breed technologies from a variety of highly capable and innovative vendors, while ensuring stability, scalability and data protection.