Migrating to Oracle Cloud with Confidence

Written by Pascal Joly, Quali

As part of their digital transformation efforts, businesses are overwhelmingly moving towards a multi-cloud approach. Modernizing applications involves taking advantage of the scalability and rich set of services available in the public Cloud. The Oracle Cloud Infrastructure (OCI) provides many of these services such as Database, Load Balancing, Content Caching…

However, when it comes to validating these complex application architectures before releasing to production, there are many challenges the QA engineer/Release Manager faces.

- How do you guarantee that your application will perform as well once you migrate it into the Oracle public Cloud?

- How do you guarantee that your application and its data will meet all regulatory and security requirements once you migrate it into the OCI?

- How do you make sure that your application environment gets properly terminated after the test has been completed?

- How can you scale these efforts across your entire organization?

Let’s consider a retail company, Acme inc., who needs to modernize their Sylus e-commerce web application as part of an overall business transformation initiative. Their current legacy workload is hosted on a vCenter private cloud and contains the typical component you would expect: namely a backend Oracle Database RAC cluster, an application server tier and a set of load balanced Apache web servers front-ended by HA Proxy. The business unit has decided to migrate it to the Oracle public cloud and validate its performance using Quali’s CloudShell Platform. They want to make sure that not only it will perform as well or better, but also it will meet all the regulatory and security requirements before they release to production.

The first step is for the application designer to model all the architecture of the target application. To that end, the Cloudshell blueprint provides a simple way to describe precisely all the necessary components in a template format, with parameters that can be injected dynamically at runtime such as build number and dataset. For the sake of this example, the designer considers 2 blueprints: the first one represent the legacy application architecture with Jmeter as a tool to generate traffic, the second one represents the OCI architecture with Blazemeter as a traffic generator service and Oracle Load Balancing service in front of the web front end.

Once this step is complete, the blueprint is published to the self-service catalog and becomes available to specific teams of users defined by access policies (also called “user Domains”). This process removes the barriers between the application testers and IT Operations and enables the entire organization to scale their DevOps efforts.

From the Cloudshell portal, an authorized end user can now select the Sylus blueprint and deploy an application instance in the vCenter private cloud to validate its performance with Jmeter. This is a simple task: all the user needs is to select input parameters and duration.

Built-in set up orchestration handles the deployment of all the virtual machines, as well as their connectivity and configuration to meet the blueprint definition. In this case, the latest build of the Sylus application is loaded from a source repository on the application server, and the corresponding dataset is loaded on the database cluster.

Once the Sandbox is active, the tester can run a JMeter load test from the automation available through the JMeter resource and directly view the test results for post analysis.

Once the test is complete, the Sandbox is automatically terminated and all the VMs deleted. This built-in teardown process ensures that the resource consumption is under control.

Then the test user deploys the same application in the Oracle Cloud Infrastructure from the OCI blueprint, and validate its performance with Blazemeter using the same test as in the previous blueprint. In such case, a link is provided to the live reports and from a quick glance: thankfully, the results show that there is no performance degradation so the team can proceed with confidence to the next stage. Since all the VMs in the Sandbox are deleted at the end of each test case, there is no cost overrun from remaining “ghost” VMs.

The same process can be repeated for validating security and compliance, all the way to staging.

Note that this can also be 100% API driven triggered by a tool like Jenkins Pipeline or JetBrain’s TeamCity using the Sandbox REST API.

Using the CloudShell platform and dynamic self-service environments, the Acme company can now release their modernized Sylus e-commerce application in production in the Oracle Cloud with confidence and repeat this process for their entire portfolio of applications for each new version.

Related posts:

Does Cambridge Analytica sound familiar? We’ll give you a hint, it has a little something to do with data mining and Facebook profiles. Cambridge Analytica, a London-based elections consultancy, has…

3 key takeaways on what TikTok's For You page wants from you. This post walks you through a multi-million-view video's analytics on TikTok.

The NFT industry is experiencing enormous growth right now. There are $10-$20 million worth of NFT sold in the blockchain every week. BullPerks is happy to bring a new incredible NFT gaming project…