Cloud portability is a strategy for building scalable, resilient cloud-native applications. When we talk about cloud-native, cloud portability is often implied. Cloud-native is an architectural approach to application development and deployment that maximizes the elasticity and flexibility of cloud computing resources. However, as teams start with a single cloud provider and develop tools and managed services specific to that initial provider, they can quickly become vendor-locked.
A portable workload is one that can be easily transported, deployed, and managed across different computing environments and infrastructure platforms. It allows organizations to avoid vendor lock-in and maintain flexibility in their cloud strategies.
When you start with a cloud-agnostic approach and leverage tools that can be used with any cloud provider, you’ll have the flexibility to make changes as your needs change. A mobility strategy also gives you more insight into how you’re using your resources and why, and enables you to diversify your cloud resources or switch providers based on your applications and business needs.
Planning your cloud mobility strategy
If you’re starting or revising your cloud application architecture, here are five steps to planning a successful mobile workload.
Determine the Requirements
The first step to achieving a portable workload is to objectively determine the workload requirements. I’ve seen this happen all too often where this process is tainted by subjectivity because eyes are attracted to a cloud provider’s attractive services before this initial step is complete. So the emphasis here is to meet your requirements before considering your cloud providers.
Think of it as a simple approach to understanding the functionality and features needed to meet all deliverables, after identifying the stacks and software dependencies and other elements to meet those needs. Having an objective and more naked perspective like this is like looking at the cloud through a wide-angle lens. It highlights a greater portion of the functionality that can be run on basic cloud infrastructures that exist in any provider.
Identify lock points
Whether the application is still in the construction or design phase, or has already been developed and deployed on a cloud platform, evaluate the current architectural design to identify components and services that are specific to this platform.
If you’ve identified points of vendor lock-in, take the time to assess why. Start by answering the questions below.
- Was a solution chosen or at least considered for faster availability or time to market?
- Was the solution based on consultation or for support/interoperability with other services on this platform?
- What was your cost when you chose this solution versus now?
After answering these questions, you can begin to map out the ideal open source or other alternatives that provide the same or similar functionality, assess the efforts required to implement, and develop a plan for execution. If after all the evaluation, you still choose to stay with a particular platform service, make sure you have an exit strategy. Cloud vendor lock-in comes in two forms: architectural and operational. A well-thought-out exit strategy from a dedicated cloud service can mitigate both concerns.
Build for scalability and uptime
Horizontal scalability and distribution can be achieved using load balancing technologies combined with containerization, compute images, configuration management, and separation of stateful and stateless components. 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 unwieldy and nearly impossible to manage, which reduces the flexibility needed to make changes in a portable manner. Therefore, workloads should be designed with modularity, with disparate components clearly defined and working together as a loosely coupled system. A cloud-native design provides an efficient process for updating or replacing individual components without affecting the entire workload, which ultimately promotes maintainability, adaptability and…portability!
Everything as Code
If you develop cloud-native applications, then you should be familiar with a declarative approach to development. Look to code every part of your workload: application, infrastructure and configuration management. With this approach you can automate the development of new environments (eg dev, staging, test) or replicate existing environments. This will ease the blue/green development process and help you recover quickly in the event of a disaster.
A GitOps approach gives you a single window to achieve portability, with the reliability benefits of automation pipelines to standardize your deployments, increased visibility for compliance/auditing, and policy-as-code enforcement. Learn more with our free GitOps for Cloud portability guide.
Looking for help planning a mobility strategy in Akamai cloud computing? Contact our cloud experts for a consultation.
