by VMware SaaS Engineer, Business IT, Souvik Mondal
In the IT workload world, everything seems perfect when applications are deployed, made accessible, and running as intended. But how do you migrate workloads when you need to provision a new instance in a new data center with the current workloads running in respective environments?
What we found is that VMware Tanzu™ Application Service™ for virtual machines (VMs) makes it faster and easier to build, test, deploy, and scale applications. Tanzu Application Service is based on Cloud Foundry, an open-source cloud application platform that provides a choice of clouds, developer frameworks, and application services.
The challenge
VMware IT experienced the challenge of setting up a new Tanzu Application Service for VMs foundation, with workloads transitioning to new a data center, by creating new spaces and deploying applications on new infrastructure.
We looked for built-in solutions within the Tanzu Application Service foundation, which can assist in swapping the applications and workloads. Looking for answers led us to some possibilities, but they didn’t meet the requirements of migrating the workloads by keeping the applications intact in the source data center.
Ready-to-use workload transition tools
While searching for a solution to migrate the deployed code of hundreds of Spring Boot applications from the old to the new platform, we thought of using Cloud Foundry local combined with pushing droplets of the applications.
Cloud Foundry local is a plugin used by developers to push Cloud Foundry applications running in a developer’s own machine. A droplet is the result of an application deployed to Cloud Foundry using a build pack, which acts as a layer of abstraction to the application metadata. This approach allowed us to deploy the droplet. However, limitations continued on the application restage.
Another option was the Cloud Foundry command “cf copy-source,” used to copy the source code of an application to another existing application. Unfortunately, we did not have an existing application in a new foundation.
Figure 1. Spring Boot Service migration across Tanzu Application Service platform
The path taken
Ultimately, we classified what was needed for our applications to run in a new foundation. Our requirements included:
- Application source code
- Application manifest, which contains a description of the deployment
- Droplets to be created after executing the Cloud Foundry push.
We began by exploring the best mechanisms for retrieving this data, such as:
- Source code: this is present in the Source Code Management (SCM) tool, but we did not want to rebuild an application considering the volume of applications we needed to migrate. VMware IT applications run different versions of code across development, testing, staging, and production environments. This limits the extent to which the SCM tool can identify artifacts.
- Application manifest: this is the approach we adopted of creating manifests per instance. For example, development, staging, and production have separate manifest files.
We also explored the Cloud Foundry application programming interface (API) and began our proof of concept to migrate the required elements we were extracting from the source of the current platform and deploying to the new platform. We did this via
- Extraction of droplets: this process uses Cloud Foundry local plugin to extract the current droplet from the source foundation. The droplet can also be downloaded using Cloud Foundry commands.
- Extraction of manifests: this is performed using the Cloud Foundry command to create a manifest from a running application.
- Extraction of BITS for an app: This is performed using the Cloud Foundry command. When an application is pushed to Cloud Foundry, it is stored in a blobstore, where it is associated with the contents of application bits, application droplets, and application metadata.
Uploading droplets to new the destination foundation, with a modified manifest. This includes using the Cloud Foundry push command specifying which droplet to be pushed along with the modified manifest. Note: modified manifest refers to a scenario in which VMware IT applications have an instance-specified manifest.
Now, we had an application running in our destination that did not have the bits, meaning the content in blobstore was empty. We cannot restage (an operation in cloud foundry) applications.
The solution
We uploaded the bits extracted in the earlier step using Cloud Foundry APIs that allow the content of the applications in blobstore. This means that all operations in an application can be performed.
Conclusion
Using this process, in conjunction with Tanzu Application Service for VMs, we developed a ready-to-use solution that can transition workloads to a new infrastructure and/or data center. It can also assist in provisioning new space and deploying applications within the same data center.
Tanzu Application Service for VMs is available through a variety of private cloud distributions and public cloud instances.
VMware on VMware blogs are written by IT subject matter experts sharing stories about our digital transformation using VMware products and services in a global production environment. Contact your sales rep or [email protected] to schedule a briefing on this topic. Visit the VMware on VMware microsite and follow us on Twitter.
