Applications that span multiple public clouds are becoming more popular, especially with Kubernetes and containers, but think carefully.
These days I hear a lot about the goal to run federated applications across cloud providers. We want to build these multicloud applications for many reasons, including:
- To optimize the underlying cloud resources for the application components. For instance, a CPU-intensive portion of the application can run on a portion of a cloud service that provides the fastest processing at the lowest cost for usage.
- To gain the ultimate resiliency, considering that outages typically don’t span cloud providers. Thus, we’re spreading the risk over more than a single provider.
- To avoid lock-in. Now we can put our eggs in many different baskets with a focus on the higher-level abstracted platforms versus the walled gardens of public cloud providers.
How to run federated applications
Although there are many ways to do federated deployment of applications, let’s focus on the most popular: Kubernetes. You typically set up a Kubernetes container cluster that spans multiple cloud providers. This creates several choices.
You can use Kubernetes Federation to manage multiple Kubernetes clusters across different clouds as a single logical cluster. This approach requires configuring and connecting each cloud-specific Kubernetes cluster to the federation control plane. The control plane is designed to manage the federated clusters and provide access to common interfaces.
Some cloud providers offer managed Kubernetes services, such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), or Azure Kubernetes Service (AKS). You provision Kubernetes clusters in each cloud provider and establish connectivity between them. You can run these on premises, but that’s typically not the cheapest and easiest path.
It’s also advisable to explore cross-cloud Kubernetes solutions (like Rancher) which allow you to manage clusters across different cloud providers from a unified interface. Of course, there are other equally viable ways to pull this off; Rancher is just one.
Are federated deployments a good idea?
It’s not a question of if you can do it. You can. The better question is should you do it? We covered the benefits, now let’s look at some potential downsides.
Complexity and increased management overhead. Deploying applications across multiple cloud providers introduces complexity in terms of networking, security, data management, and deployment strategies. Designing, implementing, and maintaining a multicloud container orchestration environment requires specialized knowledge and skills. This complexity can increase management overhead and operational costs.
Dependency on cloud provider-specific features. Kubernetes and other container orchestration platforms strive for portability and abstraction, although some advanced features and integrations might be exclusive to specific cloud providers. If your application heavily depends on provider-specific features, it could restrict its ability to function smoothly on multiple clouds.
Limited cost optimization. Although multicloud deployments have the potential to optimize costs, attaining substantial cost savings can prove difficult. Pricing models, instance types, and discount structures vary among different cloud providers. Optimizing costs across multiple clouds requires careful monitoring, management, and planning, which can add complexity and overhead.
Deployment inconsistencies and platform disparities. Despite efforts to ensure consistency, the container orchestration platform’s behavior, features, or performance across different cloud providers may vary. Using multiple clouds can result in inconsistent deployments and unpredictable outcomes, which may demand extra attention to identify and resolve.
Specific application requirements. Not all applications benefit from running across public clouds. Some applications may have strict data sovereignty requirements, performance-sensitive workloads, or dependencies on specialized cloud services that are not easily replicated across multiple clouds. In such situations, a private data center or a single cloud provider may be more appropriate options. I’m not seeing many of these emerge because most cloud architects and developers have little experience building federated multicloud applications. Moreover, there are few or no best practices.
Even if we overcome those obstacles, there are still numerous trade-offs to consider. Before embarking on the journey of building a cross-cloud federated application using Kubernetes and containers, it’s essential to thoroughly evaluate all necessary factors, such as security protocols, performance benchmarks, and deployment strategies. By taking the time to analyze these critical aspects, you can ensure a successful and efficient implementation of your application—and it does look like fun.
By: David Linthicum
Originally published at InfoWorld
