[ad_1]
How you use cloud computing will be a major decision in your application strategy architecture and planning, and multicloud is becoming increasingly the popular choice among cloud architects for building high-end, cloud-centric, enterprise applications. If you’ve already decided on a multicloud strategy, you must decide what type of multicloud strategy is best for your application. That decision may not be as clear-cut as you might think.
Types of multicloud strategies
In general, multicloud is a strategy with which a single application is deployed using more than one cloud provider. For example, as shown in Figure 1, an application could be deployed to both Amazon Web Services (AWS) and Google Cloud Platform (GCP), and take advantage of both sets of cloud services.
IDGFigure 1. Application deployed to multiple cloud providers.
But what is the application using each cloud provider for? That depends on how the decision to use multiple providers was made. Why would you want to deploy an application across more than one cloud provider?
Often, no formal decision is made and the choice to become multicloud happens haphazardly. This is especially common with companies that are new to the cloud or lack cloud sophistication. One group of engineers on one day decided to use an AWS service, such as Amazon S3. Another group on another day decided to use a GCP service. Independently, service teams may decide they need to deploy service capabilities within one or the other cloud provider’s services, and different groups may make different decisions.
While using multiple cloud providers does have advantages, using them randomly or haphazardly like this seldom does. Yet, it’s a common pattern.
Cloud specialization with polycloud
Fortunately, often the choice to become multicloud is planned.
As the cloud matures, cloud providers are creating more sophisticated services. These services are specialized, and designed to be competitive against equivalent services offered by other cloud providers. The result? Cloud specialization.
Each cloud provider has specialties—areas that they consider part of their strength—and often the services they provide in those areas are better than equivalent services provided by other clouds. Depending on the service you want to use, the best version of that service may vary among cloud providers:
- Microsoft Azure specializes in providing Windows Server operating systems.
- Microsoft, Google, and AWS all have excellent artificial intelligence (AI) and machine learning (ML) services, but one might be more suitable than the others for your use case.
- AWS has a best-of-breed object storage service that is inexpensive and supports extremely large datasets (S3).
- Azure provides high-quality and highly integrated development tools.
- GCP specializes in Kubernetes service deployments.
- AWS specializes in serverless functions.
The net result is that—to use the best cloud service available—an application may span multiple cloud environments. An application may use Amazon S3 for object storage and Amazon DynamoDB for database, use GCP for its Kubernetes cluster management, use Azure for Microsoft Windows Server instances, and finally rely on Google’s AI capabilities.
When a single application uses multiple cloud providers, each for specialized service requirements, we call this polycloud. Each cloud provider is used because of its particular strengths matching a specific need of the application. The polycloud scenario described above is illustrated in Figure 2.
IDGFigure 2. Polycloud deployment.
Generic cloud with sky computing
Another common reason to use multiple cloud providers is redundancy. In this case, the decision to use multiple clouds was not made haphazardly, but strategically. The thinking is, if one cloud provider goes down, having a second cloud provider available will allow our services to continue to function.
One problem with this approach is, to be successful, you need to ensure your application will run, without modification, on each of the clouds that you are using. All parts of your application must be able to operate on each cloud provider. This is because the stated goal—using one cloud provider as a backup for the failure of another cloud provider—works only if the application can be moved from one provider to another relatively easily.
This can be problematic because each cloud provider has a different interface to its applications. You need to support each of these different interfaces in every part of your application, and you have to test to make sure these different interfaces work in all combinations.
In this case, one solution is a new cloud model that is gaining popularity: sky computing. Sky computing is an attempt to put a generic API layer on top of multiple cloud providers. Then you build your application to use this generic API. Because the generic API is equivalent for all cloud providers, in theory it is much easier to move your application from provider to provider, especially in an emergent situation such as during a provider failure.
IDGFigure 3. Application using sky computing.
Figure 3 shows how this might work. This diagram is similar to the multicloud in Figure 1, but includes a generic API between the application and the specific cloud services provided by each cloud provider. The generic sky API provides a common set of capabilities to the application, and those capabilities are implemented separately on each cloud provider. The sky API itself is cloud-specific, but the rest of the application remains cloud-agnostic.
Which is better? Polycloud or sky computing?
Both polycloud and sky computing are strategies for managing the complexities of a multicloud deployment. Which model is better?
Polycloud is best at leveraging the strengths of each individual cloud provider. Because each cloud provider is chosen based on its strength in a particular cloud specialty, you get the best of each provider in your applications. This also encourages a deeper integration with the cloud tools and capabilities that each provider offers. Deeper integration means better cloud utilization, and more efficient applications.
Polycloud comes at a cost, however. The organization as a whole, and each development and operations person within the organization, need deeper knowledge about each cloud provider that is in use. Because an application uses specialized services from multiple providers, the application developers need to understand the tools and capabilities of all of the cloud providers.
Sky computing relieves this knowledge burden on application developers. Most developers in the organization need to know and understand only the sky API and the associated tooling and processes. They can avoid having a deep understanding of the details of each cloud provider. Fewer people need the specialized knowledge of how each cloud provider operates.
The downside is that sky computing discourages deep integration with a given cloud provider. The sky API ends up being a “least common denominator” cloud solution, as only those capabilities offered by all cloud providers are visible in the interface. This means advantages afforded with a deeper integration are not possible. The cloud ends up becoming more of a commodity, and less of a tool for innovation.
In practice, a sky API cannot completely remove the cloud-specific understanding needed by individual developers. Undoubtedly, when deep in the diagnostics and debugging cycle, trying to solve a problem with a cloud-based application, a developer who lacks knowledge of the underlying cloud platform will be at a disadvantage. Realistically, developers will find they need the detailed knowledge of multiple cloud providers.
Is monocloud the real best answer?
I’ve assumed in this article that you have already made the decision to move to a multicloud environment. If you haven’t made that decision yet, then I strongly recommend you consider your options. Do you really need a multicloud environment, or is selecting a single cloud provider a better option for you?
No matter the multicloud strategy employed, running an application in a multicloud environment is more complex—and therefore riskier—than running in a single cloud environment. Plus, there are additional costs associated with a multicloud environment—costs such as intercloud data transfer fees.
Consider why you are interested in a multicloud environment in the first place. Is it because you don’t trust the reliability of a single cloud provider? A multicloud may seem to improve your overall durability by adding redundancy, but you can add appropriate redundancy without needing to add cloud providers. Is it for financial reasons? In most cases, multicloud deployments are costlier than monocloud deployments.
Is it because you can’t decide as an organization on one provider or another, and having multiple choices available to your organization is valuable to you? If so, realize that this flexibility does come at a cost, and you should understand what that cost entails.
In the end, whether you use a monocloud strategy or a multicloud strategy, whether you use polycloud or sky computing, or even whether you use cloud native, hybrid cloud, or any of the other myriad cloud strategies, make sure you understand the costs and benefits of your choices, and make sure it is best for your organization.
Copyright © 2022 IDG Communications, Inc.
[ad_2]
Source link