If your organization has a cloud strategy, you’re right in line with 94% of today’s enterprises, according to the 2019 RightScale State of the Cloud Report. But what does a cloud strategy mean to you? While it might be tempting to assume you’ll be able to evaluate all the major public cloud vendors, choose the best one, and stick with that choice, the reality isn’t that simple.
A growing consensus suggests that few modern enterprises will be able to rely on a single provider for their cloud-based apps and services. Instead, most will provision workloads on various providers, including public and private clouds as needs require. The same RightScale report reveals that 84% of enterprises already have a multi-cloud strategy. That doesn’t just mean “the biggest one, plus another,” either. The survey results show enterprises running workloads in an average of 3.4 public and private clouds, while simultaneously experimenting with another 1.5—for a whopping total of 4.9 clouds each, on average.
The case for multi-cloud
There are many reasons why an enterprise might find itself forced to support multiple clouds. One such situation might result from business lines launching pilot projects without centralized oversight, sometimes referred to as “shadow IT.” Or, in the case of mergers and acquisitions, two entirely separate IT organizations must be made to coexist, despite having developed their cloud plans in parallel.
There are also a number of technical and operational concerns that make a multi-cloud environment actually desirable:
- Product groups may wish to avoid cloud vendor lock-in, in order to diversify risk factors and improve their negotiating power.
- Security or compliance concerns might demand that a given app be confined to a certain cloud, such as a private cloud or one with government security certification.
- Some clouds might offer specific advantages over others, such as high availability, advantageous pricing for certain workloads, or specialized technologies such as machine learning or artificial intelligence.
- Employees might have specialized expertise working with one specific cloud, which might not be the organization’s primary or preferred cloud.
- App customers, too, might have their own preferences; for example, they might have stringent uptime requirements, or they need a cloud that caters to specific geographic regions.
Another argument for maintaining a multi-cloud strategy has to do with the fluidity of the cloud computing market overall. Which cloud provider best meets your requirements for any of the aforementioned concerns might change from year to year, or even month to month, as new services launch, new data centers open, and new pricing kicks in. Or it could be that a software vendor (MongoDB or Confluent, for example) rolls out a new managed service that makes more sense than managing that system yourself or even using a cloud-provider-hosted version.
The multi-cloud conundrum
However, the reality is that managing multiple clouds does present a unique set of challenges. And these aren’t confined to increased costs; after all, it’s perfectly possible to ring up huge bills with a single public cloud provider. Rather, it’s necessary to consider the potential causes of increased costs when it comes to multi-cloud:
- Operations teams who are trained to specialize on different clouds may become siloed, leading to poor communication across teams and inflated payroll costs.
- Various applications may rely on duplicate functionality from different cloud providers for core functions, such as storage and authentication.
- Applications built for different clouds may employ conflicting, incompatible, or noncompliant networking and security models.
- Tools used to manage workloads may be inconsistent, resulting in duplicated operations effort.
- When workloads are spread across multiple clouds, defining tenants may require excess integration effort.
These challenges are not insurmountable, however. For most enterprises, a successful plan for managing multiple clouds should take a two-pronged approach. First, application owners should conduct an audit to determine which applications are running where, and then identify which should be migrated, which could be merged, and which should stay where they are. Second, steps should be taken so that future application development is done in a way that is as cloud-native and cloud-agnostic as possible.
Rising above the clouds
Containerization is a good place to start. Bundling applications as container images and deploying them via container runtimes not only makes them more portable across operating environments, but it can also make them better suited to clustering and more resilient to failure. Containers can also be an effective way to “lift and shift” legacy applications—those that were never designed to play nice with cloud environments—so that they are decoupled from their underlying bare metal or virtual infrastructure and can more easily be migrated to modern platforms.
Containerization by itself, however, is but a means to an end. The next step in the modernization journey is orchestration—that is, automating the processes of instantiating, starting, stopping, monitoring, and managing containerized apps. Kubernetes has emerged as the clear leader in this field. Because it is an open source project with a modular and extensible design, Kubernetes makes it possible to manage whole portfolios of clustered applications and related support tools with a consistent set of declarative procedures and practices.
Equally important, Kubernetes creates an infrastructure that abstracts away the low-level details of your environment. You can manage your Kubernetes cluster (whether that’s pure open source or a commercial offering such as Pivotal PKS) and deploy applications to it using the same tools and practices, no matter if it’s running on bare metal, cloud VMs, or even a fully managed cloud service. This consistency can help you avoid siloed IT teams and establish policies that traverse on-premise and multiple cloud environments alike.
Platform-as-a-service (PaaS) offerings, such as Pivotal Application Service (PAS), create an even higher level of abstraction that targets developer productivity while further automating operational tasks around managing the underlying VM infrastructure. Typically, PaaS offerings will include their own internal container-orchestration systems to handle the scheduling of workloads, but interaction with either the scheduler or the underlying VMs should be minimal. At SpringOne Platform 2019, in fact, DICK’S Sporting Goods demonstrated a live migration of its production—and PAS-based—search application from Google Compute Engine to Microsoft Azure.
What’s next: Everything shifts up
As programmatic infrastructure like this becomes the norm, smart organizations are moving their concerns up the stack. So rather than spending their resources configuring servers or conducting cloud-provider bake-offs, they’re focusing on application development while managing networking and other operational concerns at the container-orchestration and virtualization layers. You might decide to run a workload on AWS, Microsoft Azure, or a private cloud depending factors such as geography or price, but applications should be developed without concern for where they run, and the act of deploying to any cloud should be a standard experience.
Pivotal is already working toward this experience by mitigating the tough decisions around which tools to choose at the all-important platform layer. We’re making PAS run smoothly on top of Kubernetes, and releasing products such as RabbitMQ for Kubernetes and the Pivotal Build Service that will eventually support applications running on any Kubernetes distribution, on any cloud. Meanwhile, our peers at VMware are working on standardizing the multi-cloud management experience with products such as Tanzu, Tanzu Mission Control, and Project Pacific.
The end goal is simple: That you worry about your business and your applications first, and where they run second. Capitalizing on a multi-cloud world means being flexible and taking advantage of the right cloud at the right time. Committing to a single host might be the right option in some instances and for some period of time, but you don’t want to be left starting from scratch when the world around you changes.
