The basic definition of a multi-cloud is to create applications that support total or partial deployments in different cloud providers, but in the real world, this is, unfortunately, more complex.
The DevOps team has to deal with supporting multiple cloud providers while leveraging the associated extra effort and cost. To facilitate this, an intermediate abstraction layer is used to separate the application and infrastructure layers. This separation abstracts the cloud provider on the infrastructure layer and its particularities, enabling developers to write cloud-agnostic code whenever possible. Implementing this strategy is easy if you plan for it at the beginning of the project. Otherwise, the migration will pose a significant challenge, binding your development to a single cloud provider until the company is ready to assume the migration cost.
The multi-cloud challenges
But why should you adopt this strategy? The main reason to support a multi-cloud methodology is freedom.
Freedom for choosing the best cloud provider at each moment, for migrating your solution to a private or a new cloud environment without putting extra pressure on your team, and being able to negotiate your price sheet with your cloud provider to reduce vendor-locking. From the development point of view, abstracting the infrastructure layer facilitates incorporating new cloud provider features (e.g., a new type of load balancer) with minimal cost and effort on the application layer.
In other situations, there may be business constraints that benefit from a multi-cloud approach, such as internal vendor approval procedures, security compliance requirements at the application/business level, strategic alliances, or new opportunities. As the business evolves in this ever-changing environment, the cloud provider in use now may no longer be the best for companies in some key areas.
If you adopt this multi-cloud strategy, in an ideal world you should be able to move your applications and services between different cloud providers without substantial changes. But this is the real world, so if you want to adopt a multi-cloud strategy, you should understand the significant challenges that this brings forth.
The cultural mindset
The first challenge requires a cultural mindset change that needs to be communicated and discussed at all levels. from development to management. Going for a multi-cloud approach requires changes in how the current and future applications will be developed and deployed. A typical approach to reduce cost duplication at the outset is to start migrating your current applications as if they were running in a multi-cloud environment without changing providers. For this, the team will typically use and generate documentation related to how the application is architectured, which are the components, how they are interconnected, and which infrastructure requirements they have. Using this information, we can define a clear split between application and infrastructure. For the infrastructure, having an orchestration system such as Kubernetes and using infrastructure-as-code frameworks will simplify a lot down the road.
Define the application architecture
Next in line is to identify the multi-cloud needs of the target application. Is the motivation to have two or more cloud providers related to disaster recovery? Does the application as a whole need to be continually running on both providers? Is the full set of components replicated or divided among cloud providers?
Once the approach is clear, the next challenge is to define how data will be created, replicated, and managed on the new architecture. Pure stateless applications are rare, so describing how data will move among providers is a crucial decision. Some of the infrastructure layer options in this aspect are defining different processes for cloning and restoring data volumes if proper shutdowns are expected, active snapshotting of whole volumes, or partial replication of application-level data. From the application layer, some databases support replication policies that greatly simplify this process.
Open Application Model, the multi-cloud game changer
The process is complex, but with the appropriate tools, you can simplify it. The Open Application Model (OAM) is an app-centric specification that allows operators and developers to work together using an extensible and standard language. The objective of OAM is that developers and operators create reusable elements. While the developers focus on defining the application, the operators can define how elements are deployed in particular clouds.
With OAM, developers can describe their applications as a collection of components in a cloud-agnostic language. An application configuration entity defines which components and parameters are required to deploy an application. Components that share particular characteristics can be grouped using OAM scopes (e.g., monitoring application health, security considerations, etc.). OAM Traits provide a method to add extra functionality to components (e.g., exposing an ingress, having logs redirected to a centralized monitoring solution, etc.) Cloud-specific configurations are managed by the Operator, defining how particular requirements (e.g., load balancer) are satisfied on different cloud providers. The specification is extensible, so users can define new Traits to introduce new features or support new infrastructure. At Napptive we believe that multi-cloud approaches will become the new norm for cloud-native applications.
We encourage you to test our playground and see how you can accelerate your cloud-native development. It’s completely free, you simply need to sign up and get started!