Hybrid Cloud Migrate to the Cloud Scale on Demand

Cloud exit planning continued (part two of two)

In part one of this two-part series, I laid out the major reasons why organizations need to integrate cloud exit planning into their overall cloud strategies.  If you haven’t already read part one, you can find it here.  This blog picks up that thought and extends it by looking at the need to have a plan for any app that is important to the business and the complications of PaaS and SaaS.  I then switch gears a bit and look at the role a hybrid cloud strategy can play in mitigating the issues inherent with moving applications to the cloud.

Every important app needs a plan

As you would expect, the majority of organizations have a preference for one or more of the well-known cloud providers. The typical thinking is that established, well-funded clouds such as Amazon AWS, Microsoft Azure, Google Cloud Platform, IBM Cloud and Alibaba cloud are considered good investments, and more importantly, are highly likely to stay in business. In recent years Amazon, Microsoft, and Google have also all been leaders in Gartner’s Magic Quadrant for public cloud providers, and all are part of companies with huge market caps.

 

However, even for apps deployed on Azure, AWS or Google Cloud, for all the reasons outlined above, most organizations, should have a cloud exit strategy for any of the apps they deploy on these clouds. Moving an app to a specific cloud provider is one thing; the question of whether you are making a potentially irreversible decision, is something else altogether.

 

Most if not all organizations have application strategies that involve some or all of the 5Rs (see figure 1).  Most are moving forward at pace.  But many, if not most have not married each application in their 5R strategy with a corresponding cloud exit plan.  This means, for applications that are to be built net new or refactored in the cloud or simply re-platformed to the cloud; the organization risks ending up locked into a single public cloud vendor.

 

Figure 1: The 5 R’s of Application Migration Strategy

 

A cloud exit plan shouldn’t be an afterthought. A business should form a clear exit strategy during its initial cloud design and planning phases.  It should be considered holistically and should cover the entire application portfolio that is targeted for migration.

 

If this proactive approach has not been taken by your organization, then in most cases, each prior migration decision you have made will need to be revisited to ensure that a cloud exit plan exists and reflects the changing landscape of cloud services, as well as ever-evolving business requirements.

 

Stakeholder management is also key when constructing a cloud exit strategy. Different viewpoints, such as those from application owners, legal and data governance will provide additional considerations. For instance, where data is physically stored and how that choice impacts compliance requirements might be a cause for concern.

 

The cloud exit plan should be comprehensive and anticipate multiple scenarios which might occur at the end of a business relationship with a cloud provider. The plan should consider the role of third-parties, ISVs, solution integrators and might also include scenarios such as data breaches or migration to a competitor’s public cloud. We shouldn’t forget that we need to account for the cost and time required for sourcing new vendors.  A process which might include RFP phases, vendor relationships management and expenses associated with retraining cloud ops and app dev teams.

 

PaaS and SaaS add complexity

As highlighted previously, applications leveraging a cloud providers PaaS offering, will need a cloud exit plan that assesses the effort required to rebuild those services either within a different cloud provider environment or on-premises. In many cases, moving these apps will require significant levels of development work.

 

We haven’t yet focused on SaaS solutions in this blog, but they will also need an exit strategy.  SaaS solutions, when compared to IaaS and PasS, provide little to no visibility into the underlaying platform.  This lack of visibility creates additional challenges when it comes to the development of an exit strategy.

 

For example: SaaS data management and the question of where it resides, is a huge issue for many organizations. Stakeholders will need to define what data sets the business might need to extract or transfer, and how that might be converted and/or ported into a new SaaS or on-premises application. The relevant stakeholders will also need to understand what the SaaS vendor’s specific responsibilities are, when it comes to destroying data and erasing all metadata from their services.

 

Other items that need to be considered before committing to a new cloud vendor might include:

  • Cost to the business of any reduction in productivity due to the cloud exit
  • If returning workloads to on-premises (repatriation for IaaS, PaaS & SaaS):
    • Do we have the required hardware, skills and data center space?
    • Do we need co-location facilities?

 

Hybrid multi-cloud makes exit (and entry) strategies easier

Multi-cloud is a strategy or philosophy where an organization deliberately exploits the unique capabilities of different clouds, rather than going ‘all in’ with a single cloud provider. Multi-cloud is about being able to secure and operate the best mix of cloud services, ranging from IaaS to SaaS, to meet your specific business needs.   For instance, Google Cloud might be used for data analytics, Microsoft Azure might be used for data warehousing, and an on-premises private cloud might be used to host traditional line of business applications and databases (see figure 2).

 

Figure 2: Multi-Cloud Solution Example

 

Hybrid cloud refers to a single solution that spans two or more different cloud deployment environments. This is commonly where the on-premises private cloud environment is connected to one or more public cloud environments. Hybrid cloud is therefore a specialized type of multi-cloud.

 

Key to the hybrid cloud model is application and data portability, which is one of the most challenging issues when it comes to pairing private and public cloud solutions. Therefore, the first step in any hybrid cloud strategy should be the deployment of a model that will support this critical functionality.  By its very nature, the ability to seamlessly migrate workloads and their respective applications across public and private cloud is a key step that will support any cloud exit strategy.

 

VMware’s approach to hybrid multi-cloud

Let’s look at a common VMware hybrid cloud deployment model with a VMware Cloud Foundation based private cloud and an SDDC as a service using VMware Cloud on AWS (see figure 3). In this scenario, an application can be deployed to either the public cloud provider (AWS) or to an on-premises data center.  Either way, this application can be migrated with zero downtime, while maintaining consistent operational support.

 

Figure 3: Hybrid Cloud Approach

 

This application might also be deployed to another VMware SDDC on a different public cloud provider at the same time (see figure 4), such as Azure VMware Solution.  In this scenario, given that the necessary portability functionality is provided between clouds, the operators have complete control, across a single ubiquitous platform, shown in Figure 5.

Figure 4: Multi-Cloud Migration

 

This architectural model represents the ultimate cloud exit strategy. The ability to host applications that are ready to run on any major public cloud, Azure, AWS, Google Cloud, Oracle Cloud, IBM Cloud, AliCloud, supports a rich set of exit strategies. This architecture allows data and applications to be truly portable, allowing the organization to leverage a common administrative skillset and operational toolset across all the cloud environments involved.

 

In this multi-cloud world, each public cloud provider remains unique and proprietary above the IaaS layer. At the IaaS layer, VMWare’s ‘Any Cloud, One Platform’ solution provides a consistent VMware Software Defined Data Center (SDDC) platform that can run across all of the major public cloud providers (see figure 5). This scenario illustrates the foundation of a tested and validated cloud exit strategy, in a ‘well architected’ and deployed hybrid multi-cloud model.

 

For net new applications, the deployment model should address developing, testing and running production applications on a single common framework that can work across all of the major cloud providers in scope. VMware Tanzu delivers just such a framework.  Using Tanzu, businesses will not have to worry about building applications in a cloud-agnostic way.  Instead, they can build them to run on a single common framework that in turn runs on any cloud provider that is selected. This approach simplifies application transformation strategies and again provides complete flexibility to businesses to build, run and monitor applications on any selected cloud provider.

 

Figure 5: An Application Development Across Multiple Public Cloud

 

For mature, critical revenue-generating applications, organizations also have the option of running them across two different public cloud providers in production, on a single common VMware SDDC platform. This can be looked at as taking designing for high availability to the next level. Architecting an active-active, active-passive or a disaster recovery solution across two different public providers, with hybrid and multi-cloud strategies in mind, can be a mechanism for offering unprecedented levels of availability (see figure 6).

 

Figure 6: Application High Availability Across Public Clouds

 

Summing Up

I have explored in this two part blog series, how leveraging a consistent hybrid multi-cloud environment can provide a great vehicle for supporting workload portability, and consequently, a well-tested and validated cloud exit strategy straight out-of-the-box. Businesses also gain other benefits from this approach, including increased capabilities for high availability, business continuity,  disaster recovery and a reduction in risk associated with potential vendor lock-in.

 

In my previous blog series, I also addressed the close integration between the VMware SDDC platform and native public cloud services, and how that integration can be leveraged to build and extend applications. When it comes to designing applications that integrate across a VMware SDDC running in a public cloud and that public clouds native cloud services; from a cloud exit viewpoint, the key is to make the core application architecturally cloud agnostic, and to only use native public cloud PaaS services as supporting services.  Think loosely coupled.

 

While every cloud vendor references their ability to migrate workloads into their platform, as you would expect, there are very few references to the viability of cloud exit strategies. We also must consider that in many organizations, IT teams are so stretched simply maintaining existing systems, that a cloud exit strategy can get left out of their cloud migration planning process.  Simplifying the cloud entry process by leveraging VMware’s unique approach to multi-cloud architecture helps reduce the burden related to cloud exit strategies by providing a cloud entry strategy that also provides an out-of-the-box cloud exit strategy as well.

 

Learn More

Interested in learning more about how VMware can help you architect a multi-cloud solution for your organization.  Check out these two resources:

  • Looking to better understand VMware’s unique approach to multi-cloud architecture? Get the definitive guide
  • VMware Multi-Cloud Podcast: This Podcast series on SoundCloud interviews VMware technical leaders and explores how VMware Cloud offerings can help you architect a multi-cloud environment that accelerates application modernization across a multi-cloud landscape.
  • VMware Cloud on AWS Reference Architectures: This collection of reference architectures details how to deploy various application and hardware stacks in a hybrid cloud model that includes VMware and AWS technologies.

 

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *