Finding the right balance between public and private clouds

The inventory and complexity of applications can make it hard to determine how and where to start your cloud migration process.

To take advantage of cloud capabilities and prepare your business to transform digitally, you need to have a good assessment in place for your workloads and come up with a decision matrix to decide the future of the workloads.

Having a framework can help you navigate through the complexities and come up with a blueprint for guidelines that your organization needs to follow.

Having a framework and migration factory, as depicted in the following figure, helps to realize a hybrid cloud in an accelerated way:

Figure 1.5 – Accelerate to a hybrid cloud by setting a migration factory

Using the 6-R framework is a very effective way to determine the initial steps for cloud migration. Let’s look at what each R means and stands for. The first two Rs are for Retire and Retain. These two strategies are for applications that may not be as strategic to the future of your organization. Let’s look at these in a bit more detail:

• Retire: This is about retiring or decommissioning applications that are not needed, either now or in the near future. This can be looked upon as a great opportunity to identify and turn off certain applications that do not produce enough Return on Investment (ROI) for business. By retiring such applications, you can focus on services that are more needed and produce value.
• Retain: This is about maintaining the current footprint. It may be because you cannot get rid of it but also do not see any huge benefit by migrating such applications to the cloud. A certain portion of your portfolio will fall in this category because of security, ROI, or technical stack usage reasons.

Now that we have talked about two of the Rs that may address your non-strategic applications, let’s look at the other four Rs and understand them in a bit more detail:

• Rehost/Relocate: The most commonly used strategy in organizations is rehosting. Even prior to the cloud, application owners and IT teams face certain roadblocks with current platforms because of cost or technical gaps and thus end up rehosting. This can be considered a simple migration that can bring significant benefits. It is also known as lift and shift. As the name implies, you lift/export your application from the current platform and deploy it on a new platform and make an immediate impact, and get ROIs.

A few examples could be migrating your on-premises virtual machine to VMware on Cloud or to KubeVirt (KubeVirt makes it possible to run a virtual machine in a Kubernetes-managed container platform).

Rehosting may not turn your applications cloud-native or provide benefits as replatforming/refactoring does, but given less resistance and friction, the cost is less and returns are realized quickly.

Also, relocating (also known as hypervisor-level lift and shift) refers to the process of moving infrastructure to the cloud without the need to purchase new hardware, rewrite apps, or modify existing operations. This term is commonly used in the context of the VMware Cloud on AWS offering.

• Replatform: This can be looked upon as a further add-on to rehosting. For some applications, it is important to make additional optimizations and perform some tweaking and coding to get benefits from cloud capabilities such as elasticity, scale, self-healing, and so on.
• Refactor: This strategy is more fitting when certain applications are in need of extensive improvements to serve performance, availability, and reliability. Application teams have to do extensive design thinking and come up with an architecture that adheres to new non-functional requirements. This can be a time-consuming task and yet the most beneficial strategy, and it needs skill sets and expertise to take advantage of cloud-native capabilities.
• Repurchase: The last strategy is about moving on from existing vendors or technology and adopting new vendors. It means terminating your existing subscriptions and licenses for cost, security, or technical reasons – for example, giving up your on-premises Customer Relationship Manager (CRM) system to adopt a cloud-based SaaS from Salesforce or Workday. Another example is moving or reducing the usage of proprietary databases and adopting cloud-based databases.

The following table is a quick summary of the 6-R framework and how each strategy impacts time and costs and brings business benefits:

Figure 1.6 – 6-R framework and benefits

We talked about the 6-R framework, which could be very handy to determine the fate of your applications and your approach toward them. It is not meant to be mutually exclusive and you can use or customize this framework as your circumstances demand. Let’s look at different tools and technologies that could help in implementing the 6-R framework.