Cloud portability is a strategy for building scalable, resilient cloud-native applications. When talking about cloud-native, cloud portability is often implied. Cloud-native is an architectural approach of application development and deployment that maximizes the elasticity and agility of cloud computing resources. However, as teams get started with a single cloud provider and build around tools and managed services specific to that initial provider, they can quickly become vendor locked.
A portable workload is one that can be easily migrated, deployed, and managed across different computing environments and infrastructure platforms. It enables organizations to avoid vendor lock-in and retain flexibility in their cloud strategies.
When you begin with a cloud agnostic approach and leverage tools that can be used with any cloud provider, you will have the flexibility to make changes as your needs change. A portable strategy also gives you more insight into how you are using your resources and why, and gives you agency to diversify your cloud resources or switch providers based on application and business needs.
Designing Your Cloud Portability Strategy
If you are getting started, or reconsidering your cloud application architecture, here are five steps to designing a successful portable workload.
Identify the Requirements
The first step to achieving a portable workload is to objectively identify the requirements of the workload. I’ve seen it happen too often where this process is tainted by subjectivity, because eyes land on attractive services of a cloud provider before this initial step is complete. Therefore the emphasis here is to scope your requirements before consideration of your cloud provider(s).
Think of it as taking a bare bones approach to understanding the functionality and features required to meet all deliverables, onward to identifying the software stacks and dependencies, and other components to meet those needs. Having an objective and more bare bones perspective like this, is like viewing the cloud through a wide-angle lens. It highlights a bulk of functionality that can run on core cloud infrastructure primitives that exist on any provider.
Identify Points of Lock-In
Whether the application is still in the construction or planning phase, or if it has already been developed and deployed on a cloud platform, assess the current architecture design to identify components and services that are specific to that platform.
If you have identified points of vendor lock-in, spend time to evaluate why. Start by answering the following questions.
- Was a solution selected, or at least considered, for faster rollout or time-to-market?
- Was the solution based on consultation, or for support/interoperability with other services on that platform?
- What were your costs at the time of selecting that solution versus now?
After answering these questions you can begin to map the ideal open source or other alternate solutions that provide the same or similar functionality, evaluate the efforts involved with implementation, and develop a plan for execution. If after all evaluation, you still choose to stick with a platform specific service, ensure that you have an exit strategy. Cloud vendor lock-in comes in two forms: architectural and operational. A well thought out exit strategy from a proprietary cloud service can alleviate both concerns.
Build for Scalability and Uptime
Horizontal scalability and distribution can be achieved by utilizing load balancing technologies in conjunction with containerization, compute images, configuration management, and separation of stateful and stateless components. The state should be declarative where possible, maintained and managed by a single source of truth, and automatically replicated and synchronized.
Design for Modularity
Monolithic architectures can become cumbersome and near impossible to manage, which detracts from the flexibility required to make changes in a portable manner. Therefore workloads should be designed with modularity, with clearly defined disparate components, and that work together as a loosely coupled system. A cloud-native design provides an efficient process of updating or replacing individual components without affecting the entire workload, which ultimately promotes maintainability, adaptability, and…portability!
Everything as Code
If you are developing cloud-native applications, then you should be familiar with a declarative approach to deployment. Look to codify every part of your workload: application, infrastructure, and configuration management. With this approach you can automate the deployment of new environments (i.e. dev, staging, test) or replicate existing environments. This will ease the process of blue/green deployments, and help you quickly recover in the event of a disaster.
A GitOps approach gives you a single pane of glass to achieve portability, with the reliability benefits of automation pipelines to standardize your deployments, increased visibility for compliance/auditing, and policy enforcement as code. Learn more with our free GitOps for Cloud Portability guide.
Looking for help designing a portability strategy on Akamai cloud computing? Contact our cloud experts for a consultation.
Comments (1)
Thanks for info!