One of the recurring themes with our clients is the desire to use the cloud to achieve portability. This is natural given that one of the attractions of moving to the cloud is the apparent ease with which workloads can be moved around to achieve a balance. In this article, we will examine: common goals with workload portability; the potential challenges faced when moving workloads; and a few options for approaching workload portability.
There are two basic types of portability when it comes to the cloud – stack and component. Each has its own requirements and obstacles, but both provide the same outcome: moving applications and data between cloud environments with minimal disruption to operations. Most organizations use a combination of approaches specific to their needs, and this combination evolves over time with the organization’s cloud maturity.
Stack portability is the ability to move a complete technology stack from one execution environment to another. One example of this type of portability is moving complete systems based on virtual machines (VMs) from one public cloud to another. The entire system is moved between clouds as a complete unit, in order to maintain the same operating footprint. Traditional n-tier applications which are already virtualized are good candidates for this approach.
When we talk with our customers, there are usually numerous organizational goals or incentives for portability. However, they generally fall into a few basic categories.
Avoiding Vendor Lock-In
Most organizations try to keep their options open when it comes to suppliers, and the cloud is no different than something as mundane as office supplies or janitorial services. Maintaining an available source of substitute (similar and readily consumable) capabilities with multiple cloud providers theoretically increases one’s negotiating power with those providers. This economic principle of substitution is well understood by business leaders and is the major driving force behind most multi-cloud strategies.
Closely associated with avoiding lock-in is the desire to minimize the risk associated with operating critical IT workloads with a single provider. With every publicized account of a public cloud outage or other similar event, there is renewed interest in portability between vendors. In fact, even with a single vendor, this portability goal is desirable across multiple logical or physical locations.
Satisfying Vendor Preference
Organizations are increasingly finding that their customers and business partners have preferences when it comes to cloud vendors. The ability to provide application services across major cloud platforms makes it more likely you can serve users on their platform of choice, so you become more attractive to customers and business partners. This is especially true in situations where the customer or partner has a significant need to integrate with data or other applications already present in a specific cloud platform.
Providing Location Adjacency
Cloud providers operate in different geographies. It is not unusual for an underserved company location to find that they only have one realistic cloud available to them. By having the ability to move or replicate workloads across cloud provider platforms, it is often possible to provide business capability closer to the point of need to address issues such as performance and availability.
Although the industry has made it seem that cloud portability is easy, there are some significant challenges to either overcome or accept.
Security / Compliance Concerns
The major cloud providers deliver solid coverage of the common compliance frameworks and standards. However, there are still variations in the types and levels of coverage among providers, and these differences are sometimes critical when considering how to move workloads between provider platforms. If a specific security or compliance control is not present in a provider platform, that could eliminate that platform from portability consideration unless an alternative is found.
Because portability is usually concerned with ensuring the movement of applications and data, having access to the appropriate data in all provider platforms is important. In environments with a significant amount of data, moving that data back and forth between provider platforms is often not desirable. And while it is usually technically possible to access data in one provider platform from workloads located in another, there can be significant cost- and security-related concerns in doing so.
Commoditized cloud platform services, such as standard compute, network and storage features, are essentially a race to the bottom in terms of revenue for a cloud provider. In order to achieve a certain level of “stickiness,” cloud providers offer numerous proprietary features to attract and retain customers. These features, such as certain types of machine learning technology or data manipulation and analytics, can provide powerful capabilities to an organization’s business processes. However, these features are the antithesis of the avoiding vendor lock-in goal covered above.
The absence of a needed dependency, such as a particular type of database technology or programming language support, can be an added problem. Obviously, platform portability can mitigate this to a large degree, allowing the organization to use specific technology components that may not be natively offered by the cloud provider. Yet even a basic feature, such as operating system version support (e.g., Windows Server 2003 is still a common requirement), can become problematic if migrating to a more recent version or a different operating system is not practical or even possible.
Connectivity to multiple changing cloud provider environments can be a particular challenge both technically and economically. This is especially true when the connectivity approach requires any sort of lead time to procure and configure, as is often the case with high-speed solutions such as Azure ExpressRoute and AWS Direct Connect. Maintaining multiple connectivity options that may lay dormant for long periods of time may be inefficient and costly over time.
Dealing with issues such as differences in network security, domain name services (DNS) resolution and other common network needs can be equally challenging. Depending on the cloud provider platform, it is likely that multiple tools, processes and technologies, all different, will need to be managed in order to provide similar capabilities across provider platforms.
Required Skill Sets
Using a single platform of any kind reduces the number and types of skills required to support it. Consider Southwest Airlines’ almost exclusive use of the Boeing 737 in its fleet. This single-platform approach simplifies operations management and delivers significant cost savings. Adding even one additional jetliner model would double the requirement for mechanic skills and parts inventory, not to mention processes, procedures and, potentially, vendor management.
The same is true of using multiple cloud providers. Although there are some solutions that provide a level of homogenized access and operational control over disparate cloud platforms, none of them are able to keep pace with the introduction of new features and capabilities. This inevitably means that an organization will have to either maintain or contract expertise for each of the cloud platforms it uses. Cost notwithstanding, the added complexity of managing multiple providers in order to provide portability could be significant.
Guidelines for Achieving Portability
Despite the seeming conflict between portability goals and the challenges facing organizations, there are a few options currently available for pursuing workload portability.
Minimize Vendor Dependencies
There are some organizations that live on the cutting edge of application development and technological advancement. These organizations are often early adopters of new cloud platform features and, as a result, have the harder job of creating and maintaining workloads that can operate on any provider platform.
Fortunately, the vast majority of existing and even new line-of-business applications are fairly straightforward and do not rely on new or advanced features in the provider platforms. By confining these workloads to standard compute, network and storage capabilities, moving between providers can be relatively achievable. Using common monitoring and event management, security and even data manipulation features reduces the amount of variance between platform operations. While this does result in a “lowest common denominator” effect and may stifle some innovation, this is an acceptable trade-off for many organizations.
Use Virtualized Environments
Many industry observers consider the use of IaaS services, such as virtual machines, outdated and undesirable. In reality, using these virtualized environments can make moving workloads between providers easy, especially if coupled with appropriate automation capabilities. A key factor in the effective use of virtualized environments for portability is how you are treating resources. The focus should be on recreating the required resources in the specific provider platform, rather than attempting to move virtualized environments en masse between platforms.
Consider a tiered environment consisting of multiple web, application and database servers. Rather than treating these servers as static resources that must be copied or transformed to other platforms, consider automating the creation of the servers in every platform in which you may want to operate. While it is possible to create the environments in each provider platform and leave them in place, this eliminates the ability to take advantage of immutable infrastructure.
Even if you have a continuous integration/continuous delivery (CI/CD) pipeline in place to deploy applications to static server environments, consider retooling that pipeline to actually deploy the servers along with the application components. This enables nimble deployment while still maintaining control over the application components, such as a specific database version or other custom requirements at the infrastructure level.
Rethink Application Architectures
As you assess your application portfolio, it is important to analyze how the application is currently deployed and operated. Monolithic applications can make portability more challenging by requiring all aspects of the application to be moved at the same time, rather than being able to rely on discrete component movement to achieve portability. Although the term “microservices” is frequently overused and abused, the concepts it represents are still valid and absolutely essential to achieve complete portability.
Technologies such as containerization and serverless computing play an important role in this space. Being able to move smaller atomic units of a workload provides the ultimate in portability and flexibility. Networking costs and complexities aside, the ability to quickly choose where a specific service feature operates can be very powerful. And it is conceivable that the traditional multi-tiered application mentioned above becomes hundreds of components that are deployed and managed across multiple cloud providers.
Workload portability between cloud platforms is challenging but achievable. While the ability to move workloads between providers is hardly automatic, with careful analysis, planning and operational effort, a portability strategy that makes sense for your organization is within reach.
Cloud Technology Partners has been working in the cloud space for years, across numerous industries and with hundreds of diverse clients. Our experience has shown that achieving portability, especially when it requires rethinking application architectures, is not only a technological change but potentially an organizational and a philosophical one as well. And it doesn’t happen overnight.
If you are considering a workload portability strategy, or want to understand the challenges and opportunities of portability, shoot us a note. We can help you with your strategy and ensure success along the way.