Managing Risk

Risk management is a popular, albeit often accidental route to polycloud.

Take a look at Figure 2-1. Here you see a typical cloud architecture that has been optimized for risk management. Multiple cloud providers are used to provide parallel services, with the hope that if a single cloud provider has an operational issue, the other cloud providers will not and traffic can be routed to those other providers.

Figure 2-1. Multicloud for risk management

This is not a polycloud architecture, though. Instead, the creator of this architecture, as we learned previously, created a generic multicloud architecture. However, once multiple cloud providers are in use, it’s very easy to start making use of specialized services from particular providers while still working toward a risk-tolerant approach to multicloud. This tendency toward specialized services leads to a polycloud approach to application architecture, even in the guise of a planning for a more simple multicloud architecture to reduce risk.

To illustrate, take for example Figure 2-2. Here you see a single application that is deployed uniformly across multiple providers in order to provide higher tolerance toward risk from provider-availability issues. However, in this example, each provider is using a unique set of cloud capabilities that is differentiated for that particular provider. The services running on AWS make use of Amazon SageMaker, while those on GCP use the Google AI platform. While the two services provide similar capabilities, their implementation, specific capabilities, and actions are radically different. They are, in all respects, unique offerings.

Figure 2-2. Multicloud risk management over time changes to polycloud

This differs from the classic multicloud approach in Figure 2-1, where a uniform product architecture is used across all providers. By using differentiated capabilities in each provider, you are creating a polycloud application even though your motivation is uniform diversity for risk management.

Another classic example where polycloud results from a risk management plan is in archival and backup storage. This is illustrated in Figure 2-3. This is a common situation, as different cloud providers are often used to store backups and duplicate copies of critical data in order to preserve against failure in the main cloud provider.

Figure 2-3. Polycloud backup management

This model allows backups to be kept independently and gives some ability to recover from the failures of a single cloud provider. This is a true polycloud model, because one cloud provider is being used for a specific capability—archival storage—while another cloud provider is being used for active application services.

Managing Costs

Managing costs is a common model used by organizations that leads to a polycloud application.

Many organizations, especially organizations with large operational budgets, will give higher weight during architectural decision-making to criteria based on cloud costs.

An example of this higher weighting is to determine that the cost of object storage may be cheaper in one cloud provider, like AWS, while the cost of server instances may be cheaper in another provider, like GCP.¹ As such, an application may become polycloud simply to optimize cloud costs for a given application. This is illustrated in Figure 2-4.

Figure 2-4. Cost-optimized polycloud

Care must be taken in this sort of operational plan, since data transfer costs between cloud providers may negate any specific service cost advantages. As such, you are more likely to see this model used with less active data, such as for archives and backups, where data transfer and interprovider communications may be more limited.

Selecting Features

Some cloud providers have specialties and provide better capabilities in some of their cloud services than other providers. This results in certain types of services being better in different cloud providers. For example:

• Amazon S3 is a solid object storage system that allows quick access and inexpensive deep storage all within the same infrastructure. If your application has large data requirements with varying accessibility needs, AWS is a cloud provider to consider.

• GCP provides solid management of running containers in a Kubernetes cluster. While other providers offer Kubernetes cluster management, Google has more Kubernetes knowledge and experience, and its offering is more mature than most other providers’. If your application depends heavily on containers and container orchestration, Google’s expertise is quite valuable.

• Microsoft Azure offers the most experience hosting Microsoft-based servers, resulting in the most capable and reliable hosting for Microsoft-based applications. An application or service that requires Microsoft capabilities is a good choice to operate on the Azure cloud.

• GCP has historically had very solid AI and machine learning (ML) capabilities, much more so than other cloud providers. However, lately, AWS has also been focusing in this area, and its AI/ML capabilities have expanded significantly in recent years, making AWS a good choice for services highly dependent on AI/ML capabilities.

• AWS Lambda is one of the best serverless computation platforms available today, allowing you to build specialized functions without having to be concerned about the server deployment and scaling requirements as much as you do with a server-based architecture. GCP provides similar capabilities, but AWS’s offering is more mature.

• Microsoft Azure has invested heavily in Internet of Things (IoT) capabilities for its cloud offering. While AWS has recently started to expand its IoT capabilities, Azure’s focus on IoT is notable and provides more complete capabilities.

These are just some examples that depend on a number of variables. Specific applications will have specific requirements that will encourage the use of specific capabilities by specific providers. As such, it’s easy to see how a large, complex application with multiple moving parts might make use of capabilities that are the specialties of different cloud providers, and hence might be suitable for a polycloud-hosted architecture.

Maintaining Development Team Independence

In a large organization, individual development teams sometimes have a level of independence that allows them to make some decisions about where and how their services are to operate.

Sometimes a development team will have specific guidance and constraints about how it operates its services in its own operations center but may have some flexibility for experimentation outside the systemic structures. This flexibility can lead to testing, experimenting with, and ultimately using specific cloud services in production that are unique and provided by specific cloud providers. When individual development teams are making independent decisions, not surprisingly, those decisions are often different.

Frequently, the net result is the organization ends up using a patchwork of services offered by different cloud providers for distinct parts of larger applications. This leads to individual applications relying on multiple cloud providers. More specifically, these applications have parts that depend on certain capabilities as provided by different cloud providers. These different services, or components of the application, are using different cloud providers, as shown in Figure 2-5.

Figure 2-5. Independent development teams making independent decisions

This process, which leads to a polycloud architecture, isn’t intentional but is the result of independent development teams operating independently. It is a side effect of the operational choice to allow teams to make their own decisions.

Allowing individual teams to make operational choices has many advantages, such as an improved sense of team ownership. This type of polycloud end result may appear suboptimal from a global standpoint—your application is using similar services from separate and distinct providers—but in fact may provide optimizations at the organizational and team level that far outweigh any perceived disadvantages.

Evolution Over Time

Rather than independent decisions being made by independent development teams, polycloud can result when independent decisions are made over time, over the life span of an application.

As an application grows and develops over time, and new and updated features and functionality are added to the application, the design and implementation of those pieces of new functionality are often architected and developed in a vacuum, independent of other decisions made at other times during the lifetime of the application.

Simply put, decisions usually occur like this:

• At this point in time, implementing this specific feature that is currently considered important…

• …is best served by using this capability…

• …offered by this specific cloud provider.

As time goes on, many such decisions like this are made, each decision independent from the others. This process often leads to an application with many individualized dependencies on different services, different capabilities, and, ultimately, different cloud providers.

In Figure 2-6, Service A may have been built at one time, Service G may have been built at another time, and Service F at a completely different point in time. At each point in time, different criteria led to different decisions and, ultimately, the use of different cloud providers.

Figure 2-6. Independent deployment decisions made at different times (Service A through Service G)

This process, which leads to a polycloud architecture, was the result of independent decisions based on the criteria that happened to be important at that time. Each independent decision was a good decision at the time, but the result is a patchwork of independent service dependencies in multiple cloud providers.

Now that we’ve provided some definition and understanding of how your organization may find itself using a polycloud architecture, we’ll dive deeper and look at some specific use cases.