Cloud Migration Blog
Cloud Migration: Multi Vendor Cloud Strategy and Avoiding Cloud Lock-inBy Johanna Shirman on May 12, 2016 2:16:34 PM
Back in the late 80's, Cisco, IBM, universities and others started working out the complexities of how to support availability to utilize multiple network paths and vendors with the Border Gateway Protocol.
Cloud providers themselves, like enterprise data center managers, don't rely on just one carrier for network availability. Who would select a provider with just one network carrier in today's market, or even a dozen years ago? In spite of 'carrier' grade equipment and investments in numerous redundancies these providers have in place, experience has shown you need more than one vendor to rely on. The norm is to utilize at least three different vendors for network connectivity. The network is just one of many critical ingredients that must be available for Cloud providers to maintain their Infrastructure as a Service (IaaS).
So why should cloud customers act any differently? Like network carriers, a multi-vendor plan affords better management of services as well as costs. We expect customers of cloud providers will require multiple providers to support the promise of availability of their services regardless of how much a single provider invests in redundancies. Again just like customers of network services.
Not unlike moving from your current home to a new one, migrating from one Cloud to another can be disruptive, costly and challenging. In fact, to achieve your current Cloud configuration, you had to develop processes, ensure proper personal were in place, implemented the correct set of tools, and contracted with a particular Cloud vendor. Moving your workload and assets to another Cloud provider will necessitate revisiting all of these steps, along with their associated costs. The overwhelming challenge of making such changes can leave many organizations feeling painted into a corner with few palatable choices, essentially locked-in to their existing Cloud vendor.
Migration Hurdles: How Technology Requirements Can Lock You In
There are several important considerations when preparing to migrate from one Cloud to another. Vendor lock-in can occur when a specific technology is offered by a Cloud model, such as a proprietary operating system. And not all Clouds are created equal. Providers may build certain features and functions into the Cloud that go beyond simply infrastructure of the service component. The technical benefits that exist in a particular Cloud environment, along with cost considerations all contribute to being tied to one Cloud vendor.
Approaches for Escaping Cloud Vendor Lock-in
If your technology needs can only be met by your existing Cloud provider, then obviously, your options are limited. But in many cases, migration is not only possible, but feasible. Overcoming the challenges of vendor lock-in starts by automating the way data is ported between Clouds. If this automation can be achieved for a low enough price point, then the other costs associated with migration can be mitigated.
Subtle nuances between Cloud vendors can also be dealt with by finding a solution that bridges gaps, mapping the differences between providers, then helping to transpose or transform workloads for seamless migration. Another consideration is finding a solution that offers live migrations. In this way, you can effectively reduce risk on your source machine, ensuing up-time and eliminating customer impact. A solution that doesn’t require install agents further reduces install risk.
Repeatable Process Key to Success
The key to successfully implementing a multivendor cloud deployment and escaping vendor lock-in is to use a migration automation solution like RiverMeadow SaaS that offers a defined, repeatable process. Such a process makes it possible to achieve cost efficiency, while lowering risk. RiverMeadow can expedite a multivendor cloud deployment and management strategy across cloud and virtualization stacks giving customers much greater choice in the numerous cloud offerings available.