There are multiple cloud deployment options for provisioning IT infrastructure and deploying applications to the cloud. Choosing the right deployment model requires you to understand your source environment, where you want to move it, and how you would like to implement the actual migration. Whether you want to deploy it in a private, public, or hybrid cloud, you need to plan it thoroughly and execute it with great precision. Else, you're at risk of performance instability, corrupting an entire database, and altogether losing customer trust.
Cloud providers offer different deployment services to migrate applications of various workloads. AWS, for instance, offers several sizing options to roll out an application on different building blocks such as Amazon EC2, Amazon EBS, Amazon S3, and Amazon RDS. Virtual machines in Microsoft Azure are categorized similarly but RAM, CPU, and storage capabilities may vary. While cloud providers offer organizations a wide range of options, we’re still seeing a gap in integrating all the bits and pieces in cloud migration projects, from the application discovery up to monitoring the migrated workloads in the cloud.
Review of 5D Migration Strategy
In the last few weeks, we’ve published a series of blog posts talking about how we approach cloud migration in IT-Conductor. We’ve also discussed the importance of establishing your business objectives and KPIs in measuring cloud migration success.
Now, we’re on our last installment as we focus on the deployment stage or the Deploy stage as defined in the 5Ds of IT-Conductor’s Cloud Migration Strategy. If it happens that you missed out on reading the other four stages, please read the following first and come back here when you’re done.
Deploy Stage in Focus
By this stage, you should already have a grasp of how we approach cloud migration because, in this article, we wanted to focus on how the actual migration activity is executed.
The deployment stage is where the application components will be deployed in the target environment. At this time, containerization is typically not supported by application vendors (i.e. SAP). Thus, a full installation process is required.
Yet again, depending on the level of automation maturity, the following scenarios are entertained:
Standard installation templates (Ansible, Cloud-formation, etc.) are used with minor modifications to account for the specific environment. Pre-defined workflows defined at the prior stages are executed by an administrator.
The customized installation templates are executed by the orchestration tool with monitoring and management of the execution process. The logs are stored for future audits. The administrator can also get alerted when an issue occurs.
The components are deployed based on the design blueprint generated at the prior stages, replicating the source application landscape. The components are also automatically incorporated into the target APM configuration. All actions are logged. We are also looking at initiating the monitoring of the new environment seamlessly following the deployment of the components. Right now, you can manually register it to the platform for monitoring without problems.
Cloud Migration in Action
Starting the migration can either be done by scheduling the activity to a specific date and time or directly running the process definition developed in the previous stage. Figure 1 is an example of a process definition that has not been started yet, for a HANA system deployment and migration using HANA System Replication (HSR).
Figure 1: Replicate HANA to Azure Process Definition
Upon instantiating the process, the color of the activity will change from violet to light blue, indicating that the process is preparing for execution.
Figure 2: Activity Preparing for Execution
This color changes in real time as the process executes. The activity color will then turn to orange, signifying that the execution of the activity has already started.
Figure 3: Activity Started
As it completes, the activity color will turn green and the next activity starts automatically.
Figure 4: Activity Completion
You can also see execution logs that refresh by themselves, so you don’t need to refresh the platform just to see the updates.
Figure 5: Self-refreshing Execution Logs
Start Your Migration POC with IT-Conductor
There are several migration scenarios we’re currently working on with our customers, including both homogenous and heterogenous migration activities.
To give you a glimpse of what we have worked on so far, you may check the following:
Deploying applications to the cloud can be a complex and time-consuming process. There are several different components that need to be integrated together in order for application deployment to succeed. With IT-Conductor, you will be able to close the gap in having all of those components orchestrated in one platform, allowing your migration projects to be executed end-to-end.