Cloud migration may sound as simple as migrating resources from a physical to a virtual infrastructure. However, migrating to the cloud means a lot of different things. While it's true, in concept, that you move resources from on-premises to a virtualized environment, it is not as straightforward as it looks. It can mean migrating resources to a private or a public cloud. Moreover, virtualization can exist without cloud computing, but not the other way around.
With virtualization and cloud computing often used interchangeably, it can be confusing to understand cloud migration without understanding the difference between the two. To make things easier, let's focus on migrating to the public cloud where the infrastructure is managed by cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.
5Ds of IT-Conductor's Cloud Migration Strategy
Migrating to the cloud involves moving applications, data workloads, and other digital assets required to run your business operations, which means that you have to properly strategize on how you will approach your journey to the cloud. Last year, we've recommended developing your cloud-first strategy. In this post, we will focus more on the technical side of things, highlighting what the 5Ds are all about and how you can utilize them in your cloud migration journey.
IT-Conductor Migration Process
Migrating applications and databases to the cloud require understanding the source environment, generating a baseline for its configuration and performance, designing and developing the target infrastructure in the cloud, deploying application components in that target environment, and finally validating the cloud migration success.
Discover Source Application Environment
Understanding the source application environment is not as simple as determining the source in client-server networks. It requires a deep understanding of specific application domains. Unlike in client-server network topology, understanding the source application environment could mean discovering multiple related applications, how they integrate with each other and even taking into consideration the security controls that support various application connections and end-users accessing your systems.
The rise of multi-tenant database management systems further adds complexity to application discovery. The existence of systems capable of supporting multiple isolated databases makes it trickier to understand the nature of the source application environment as resources are shared. For instance, SAP HANA can have multiple servers equivalent to services (i.e. nameservers, index servers, etc.) and databases in a multi-container system run different instances of these servers. It would be a challenge to discover system components without a tool capable of linking the bits and pieces of your entire system landscape.
As an application performance management (APM) platform, application discovery in IT-Conductor leverages a multi-layer approach to automatically discover deep dependency chains among components. So, even with the complex and dynamic nature of source application environments, the platform is capable of discovering components and displaying them in a hierarchical view.
Distill Source Application Environment
The determination of performance and configuration baselines follows the understanding and discovery of the source application environment. By performance, we mean the different metrics that can be measured to satisfy specific business goals. For instance, if your main concern when migrating to the cloud has something to do with upgrading the end-user experience for your customers, then you should generate performance baselines related to user experience like—what are the usual response times when users access the application? Other common baselines related to performance are resource utilization such as CPU/Memory, storage, and network.
Aside from these performance metrics, you also need snapshots of the last working configuration state of your source application environment. This way, it will be easier for you to revert back to its last-known good state should you encounter issues in the deployment stage.
It is also important to note the distinction between discovering the "true" state of resources based on performance and configuration baselines. It doesn’t mean that when a specific component is unavailable, the system is no longer healthy. There can be redundancies in place, or perhaps, there’s an issue with the heartbeat configurations.
As opposed to registry-based discovery which has limited depth in terms of monitoring and managing performance, not to mention the need to be kept up-to-date continuously, APM-based discovery can dynamically reflect these sudden changes (i.e. status and configuration) in the infrastructure. This is extremely helpful in migration activities so you can spot problems head-on and during the actual execution. If in case you encounter unexpected issues, these baselines can serve as your starting point for comparison so you can quickly perform targeted tuning or revert back if necessary.
Design the Target Infrastructure in the Cloud
There are several scenarios when migrating resources to the cloud. As a matter of fact, cloud service providers have different migration strategies. In November 2016, Stephen Orban published an article about how AWS leverages the 6Rs model mainly Rehosting, Replatforming, Repurchasing, Refactoring, and Retire. Five years later, the AWS Services Team have dozens of new additions which then improved the existing 6Rs model. Now, they have seven strategies for migrating applications to the cloud. Azure approaches cloud migration differently, focusing on three stages, mainly planning, implementation, and operations. Google Cloud also approaches migration in a different manner from workload discovery and assessments up to optimizing the environment in the cloud.
Regardless of what approach you use in migrating to the cloud, these three scenarios would define the complexity of the migration deployment implementation.
| Migration Scenarios |
How migration would be handled in the Design stage |
|---|---|
|
Manual |
|
|
Assisted |
|
|
Full Automation |
|
Choosing to perform cloud migration manually isn’t really a bad thing. Oftentimes, it’s the scenario that would best fit your needs. At this stage, if you’ve already decided to migrate to the cloud without the use of automation and/or orchestration tools, it would not help to proceed to the next stages we’re recommending in this post. However, if there’s still that 1% doubt about performing it manually, the next stages would show you what other options you may consider.
Develop the Target Infrastructure in the Cloud
The rollout of the target infrastructure is fed by the design stage. After defining what approach to follow—whether it be manual, assisted, or automated—the actual build-out should come next. The following migration scenarios, though, are focused only on developing the target infrastructure using automation.
|
Migration Scenarios |
How migration would be handled in the Develop stage |
|---|---|
|
Assisted |
|
|
Managed |
|
|
Full Automation |
|
The complexity involved in building the target infrastructure varies depending on whether you will perform it manually or with the use of automation. The existence of an orchestration tool, as mentioned above, helps you monitor the execution without actually doing anything and just get alerted when an issue is encountered midway.
Deploy the Application Components in the Target Environment
By this point, you should already be able to deploy application components in the cloud infrastructure rolled out in the prior stage.
| Migration Scenarios |
How migration would be handled in the Deploy stage |
|---|---|
|
Assisted |
|
|
Managed |
|
|
Full Automation |
|
Depending on your requirements, you can choose to use an orchestration tool (assisted, managed, or full automation) to execute the migration seamlessly without any impact on end-users.
Validate Performance Assessment
The validation stage takes place upon the completion of the migration activity. It’s crucial to execute a performance assessment because it helps you evaluate the readiness of your systems in the cloud. To fully assess the success of cloud migration from the performance perspective, you should perform the following:
Load Testing
Load testing is a subtype of performance testing that measures system response under extreme load conditions. It is performed to simulate multiple users accessing the system and test its limits to evaluate if the system is capable of handling real-world scenarios.
Analyze SLOs
Service Level Objectives (SLOs) also help define migration success as it helps you measure what is expected from your systems after the migration activity.
Compare Baselines
Measure performance metrics in the new environment over a period of time. Then analyze and compare with baselines defined at the prior stages. Make sure they are behaving in accordance with the defined SLOs.
IT-Conductor as Your Cloud Migration Solution of Choice
Cloud migration is shaped entirely based on the following questions:
-
Why are you moving to the cloud?
-
What are you trying to accomplish?
-
How are you going to do it?
-
How will you measure your success?
Depending on your business objectives and what strategy to implement, it is at your disposal to choose a tool that will help you achieve your goals. While cloud service providers throw in several tools your way just to make migrations as easy as possible, it is not the reality we’re seeing. With the different tools doing different things, migrating to the cloud is still seen as a burden, not to mention the accrued cost of using them all. So, what is there to lose using third-party tools to migrate your environment to the cloud? Nothing. In fact, you could save more using an integrated platform that is capable of not just moving your resources to the cloud but also managing them with more ease using its advanced performance management capabilities.
IT-Conductor has helped partners and customer organizations move seamlessly to the cloud while keeping the monitoring intact through the agentless technology of the platform. The next phase following migrations is to utilize IT-Conductor Workflow Automation capabilities to orchestrate IT operation processes end-to-end.
To help you get started, we've published a series of blog posts that talks about the 5 stages of our cloud migration strategy in more detail: