The main idea of cloud portability revolves around the quick and easy migration of entire cloud environments from one vendor to the other. Discover why cloud portability is one of the biggest cloud myths.
Explore how we helped an educational technology company migrate from Microsoft Azure to AWS, consolidating their applications, databases, search functionality, and virtual machines into a unified cloud infrastructure.
Learn how we helped our customer consolidate their IT infrastructure by migrating 25 Virtual Machines from Microsoft Azure to AWS.
Considering a move to the cloud? Explore the essentials of cloud migration and gain insights to ensure a smooth and cost-effective transition to the cloud.
A majority of the cloud experts would agree that cloud portability is practically impossible and is a contemporary myth in today’s cloud industry, as per Barry Silic’s explanation on the subject of cloud portability. Yet, many organizations still trust the multi-cloud environment model for various competitive reasons.
Although it is challenging to shift workloads from cloud to cloud instantly, developers can still transfer workloads by optimizing a robust migration strategy. Also, there are many workarounds for cloud portability to allow mobility without any barriers.
The core concept of cloud portability revolves around migrating entire cloud environments from one vendor to the other. As a result, cloud portability demands almost no disruption during the migration of workloads between the multi-cloud environments involved in the process, such as Amazon Web Services, Microsoft Azure, or Google Cloud. These environments require using the same codebase to support swift portability.
Organizations can reap many benefits from leveraging multi-cloud, including agility, competitive pricing, bolstered resilience, customer demands, network performance, flexibility and scalability, and robust security. Sometimes, these reasons are also directly linked to the required functionalities, tools, and technologies that a single cloud vendor does not provide.
As James Adams, the Vice President of Service Delivery at Caylent, explains, “Organizations do not want to be locked into a vendor. But, unfortunately, there’s a history around significant vendors like Oracle and Microsoft where people went all in and were on the receiving end of unhappy surprises at contract renewal time.
We’re still suffering from the fact that you basically can’t work in this world without the Microsoft Office Suite and all the tools that go along with that, although Google’s finally getting there with some comparable tooling. I think some IT leaders have learned their lessons, and now in the cloud world, they don’t want to get locked in with any one single vendor.”
Caylent’s Customer Solution Architecture Director Mark Olson further expands on this point, “Leaders believe they’re getting leverage over the cloud providers by adopting portability over provider-specific services. Additionally, organizational leadership thinks they have the ability to enter into an arbitrage situation and bid GCP against Azure against AWS or all three and compete for the workloads.
The truth of the matter is that these hyper scalers are all large enough that they’re not going to be influenced by competition for one customer’s workload more than they would by the workload size itself. So, the threat of leaving a given provider has less negotiating value than the costs of engineering investment and operations required to adopt the lowest common denominator capabilities and avoid the use of platform services.”
In summary, organizations may want to play on the safer side of cloud portability and avoid diversifying their workloads across multi-cloud services. While they might cut down their overall costs marginally, doing so won’t necessarily put them into a strong negotiation position to pit hyper scalers against each other from any other leverage. However, buying into a single cloud vendor is inconvenient for some businesses, and scaling companies cannot entirely constrict their reliance on a single vendor to handle their workload. Thus, a multi-cloud environment is the only fair option for that use case.
Organizations do not always intend to indulge in a multi-cloud environment, preferring to expand workloads within one platform and reduce security risks across vendors. However, some companies need to operate in a multi-cloud setting because their encounter teams are scattered across multiple vendors. As a result, it is challenging to engage them for a single vendor.
Mark Olson puts it this way, “So the two reasons that we commonly see clients with multiple cloud footprints are larger clients and even some funded startups growing through acquisition and “best of breed” service adoption. As you grow a company through acquisition, you’re naturally going to encounter teams that use a different platform because they have each made different design choices along the way.
From that perspective, multi-cloud is a real thing that clients need to manage through to maintain productivity. Whether “best of breed” is an intentional strategy and something that clients want to engage in deliberately, without already having that portfolio in place, has a much less obvious value proposition.
Tools like Terraform and primitives like containers are used to create skill sets that are broadly portable across that future vision. But as you’re building up your product and as you’re building your capability, focusing on one hyper scaler, AWS, in our case, allows you to concentrate your fire, concentrate your skill sets. You’re in a position to pay attention to what you’re trying to deliver to market rather than trying to abstract and create layers of portability that you don’t need until you have a very compelling reason to be multi-cloud.”
If a company can somehow move its workload from a single vendor, it will ultimately be unable to move to cloud-native services. These cloud services are necessary, especially when moving to a public cloud. There is no point in setting up a multi-cloud environment if cloud-native services are compromised during the process.
James Adams considers cloud portability a myth because while the concept is theoretically possible, it is practically impossible to execute in the real world. As he reasons here, “Companies want to be able to move between clouds, or in some cases, they want to do arbitrage between the prices of similar services between different cloud vendors. The reason I find this whole topic amusing is because, as I said, portability is a bit of a myth. If you look across Amazon, if you look across Azure and GCP and AWS, all three of them use different underlying hypervisors.
Each platform also uses different effective runtimes at the chipset and command set level, and so you cannot, for example, compile a container. Everybody loves containers because they think they’re portable. They’re not. If you compile a container for Amazon and try to take that same container and run it on GCP, it will crash. It will not run. Same thing if you try to run it on Azure.”
The first workaround is by using an application environment, a Platform-as-a-Service, that is not tied to any particular cloud platform. It is common for PaaS companies to provide all the services necessary for an application to run. In addition, the PaaS can support and facilitate mobility if migrating the entire environment from one cloud to another.
James Adams also proposes another workaround, “So what people end up doing when they really want to be portable instead out of that is they’ll use a tool to build three copies of a container, one for each cloud environment, and then spin up whatever is the correct one when they try to redeploy to a different cloud.
Today’s most portable thing across cloud providers in the universe are Functions-as-a-Service such as AWS Lambda or the Google functions or Microsoft Reference functions. The only difference between the code is really in the context object, and some frameworks will let you truly make that portable between them by swapping out and doing polyfills of what that thing looks like. However, at a core level, portability remains a bit of a myth. Plus, if you try to be truly cloud-agnostic, you can’t take advantage of some pricing discounts you can get by going all-in on one cloud vendor.”
There are multiple reasons why cloud experts always recommend a single cloud rather than a multi-cloud environment under normal circumstances. Let’s discuss a few of these reasons below:
Easier Management
In a single cloud environment, teams can collaboratively work together on a lone problem or task without any barriers or distractions as otherwise seen in multi-cloud environments, where teams cannot effectively manage and operate their solutions.
Collaborative Tooling
All available tools in a native-cloud environment are much easier to operate for anyone working on the same team inside the same cloud environment. In addition, the same tools and solutions are accessible to different teams working inside the environment. Therefore, there are more chances for multi-disciplinary teams and projects to collaborate without any further hindrance.
Multi-Cloud is Expensive
Multi-cloud requires you to set up multiple cloud environments using various vendors, and each environment will have very different demands, infrastructure setups, services, and foundational languages. Such demands also include solutions, tools, management, team, and maintenance expenses that collectively cost a lot. However, a single cloud will also work out more cost-effectively across the board for a collective environment setup and use of resources.
Single Cloud Discounts
Each vendor demands a different cost in a multi-cloud environment, and it becomes difficult to negotiate with each cloud vendor separately. On the brighter side, a single cloud environment will allow financial teams to negotiate resourcing costs flexibly to get the best-discounted rates as demand requires.
While cloud portability might be a myth, cloud optionality exists. Suppose an organization doesn’t have a solid use case for a multi-cloud environment. In that case, it is wiser to stick with a single hyper scaler vendor that more effectively fulfills all your requirements. Businesses can take an extended time to opt for the right vendor to avoid lock-in with the wrong cloud platform. However, if a company opts for the myth of portability using multi-cloud vendors, they will likely find their setup will eventually become difficult to manage.
Caylent is a cloud-native services company that helps organizations bring the best out of their people and technology using AWS. We are living in a software-defined world where technology is at the core of every business. To thrive in this paradigm, organizations need to empower their people and processes through technology. Caylent is uniquely positioned to fuel that engine of innovation by bringing ambitious ideas to life for our customers.
Caylent works with customers to build, scale and optimize sophisticated cloud solutions using deep subject matter expertise to deliver world-class outcomes through an agile co-delivery model.
Caylent Team
