Most organizations understand the importance of having a concrete plan and strategy when migrating to the cloud. In the article we've published recently, we've recommended starting your cloud migration journey by setting business objectives and establishing key performance indicators (KPIs). These two play a significant role in defining your cloud migration success. However, establishing KPIs and benchmarking metrics will be an uphill task if you don't have a complete understanding of all of your IT assets, applications, services, and the interdependencies among all of them. For this very reason, we've introduced the Discover stage as part of the cloud migration strategy we've been utilizing in IT-Conductor.
Oftentimes, organizations pay little attention to this aspect of planning where you need to take into account all the resources you have in your environment and how components relate to each other. Especially in large organizations where workloads are often interdependent, understanding the source application environment is becoming an indispensable part of your cloud migration strategy.
Before we dive deep into discussing what transpires in the Discover stage of the 5D's of IT-Conductor's Cloud Migration Strategy, let us first define application discovery.
Table of Contents
What is Application Discovery?
Application Discovery is the process of understanding the entirety of an enterprise environment where all of its components and interdependencies are being discovered and mapped for better comprehension. Typically, enterprise environments comprise multiple and related applications from different vendors which makes discovery more complex than client-server network topologies—requiring a more in-depth understanding of application domains as well as mastery of vendor-specific API toolsets.
The rise of multi-tenant database management systems further adds complexity to application discovery. With systems supporting multiple isolated databases, understanding the nature of an application environment becomes a challenge as resources are shared. Without a tool capable of expressing the diverse components and their complex relationships, it would be difficult to map out the dependencies among the different components and their underlying infrastructure.
What is the Importance of Application Discovery in Cloud Migration?
Understanding the source application environment precedes all other activities required in your cloud migration journey. Without it, you won't be able to generate baselines, design your target infrastructure in the cloud, develop your deployment plan, provision resources, and perform the actual migration activity because you don't have a blueprint of what is currently existing in your environment—which is important before you can define where you want to go.
Migrating to the cloud without application discovery is like walking blindly without knowing where you're going. While that sounds like a motivational quote with the promise of getting somewhere interesting on your way, it doesn't work like that when it comes to migrating workloads to the cloud. Especially in enterprise environments where business operations depend on critical applications, you need to ensure that what is working in the existing environment is working the same way in the target environment, or even better.
Moreover, simply moving workloads without considering the impact of migration to the interdependencies among the different components in your environment would most likely result in issues in production. Let's face it. No systems are 100% reliable. Your systems are always on the brink of failing, even more so if you don't take extra precautions. Systems in production are always changing. Unless you've been thoroughly documenting every change in your systems, moving workloads without careful planning would risk the availability and reliability of your applications and the data they contain. In distributed systems where resources are shared, moving data from different sources demands proper sizing and architectural design.
Discovering Source Application Environment in IT-Conductor
Application discovery in IT-Conductor leverages a multi-layer approach to automatically discover deep dependency chains among components in an application environment. The platform is capable of displaying components in a hierarchical view where you can drill up and down the components making up your entire system landscape.
Figure 1: Service Grid in IT-Conductor
When a system is first added to IT-Conductor for monitoring, all components related to that system are automatically discovered.
Figure 2: SAP System in IT-Conductor Service Grid
For instance, when you add an SAP system, the app servers up to the services are mapped automatically after configuring IT-Conductor to monitor that particular system. In cases where a new host is to be added to a system already being monitored, or when enabling a new option or feature, IT-Conductor will automatically discover the changes and starts monitoring them in real-time.
For the most part, we have been discussing how discovery takes place when you first configure monitoring for an application or a system. Let’s call this the APM-based Discovery. Registering a system in IT-Conductor follows the performance & availability requirements of IT operations, particularly setting thresholds and overrides.
APM-based Discovery lets you discover the true state of a system based on monitoring instrumentation. This discovery path provides you with the baselining capability where you can see the performance of your systems before migration—which you can then compare with the metrics you will measure after moving them to the cloud.
Discovery using the Landscape Management Database (LMDB) heavily relies on the application domain configuration repository. As opposed to APM-based discovery, LMDB discovery has limited depth. Normally, configuration repositories don’t contain deep component relationships. Despite these limitations, however, we still recommend going for LMDB discovery because it is much faster to implement as it requires minimal configuration effort. The only downside to this is the inability to generate performance and configuration baselines.
As a recommendation, after performing the LMDB discovery, add the discovered systems for monitoring prior to migration. Adding systems for monitoring will be so much easier now since data is already pre-populated from the LMDB. From there, you can easily generate baselines and design blueprints from monitored systems using IT-Conductor.
Figure 3: SAP Landscape Discovery
LMDB discovery in IT-Conductor uses a 1-click configuration and integration tool to discover all customer SAP system landscape components and optionally lets you create placeholders for IT-Conductor monitoring systems. You can then use it to export landscape inventory data and for migration assessments (compute, storage, and networking profiles).
Figure 4: SAP Landscape Report
The use of both landscape discovery information and the baselines (performance and configuration) can help you expedite the cloud migration OpEx estimate for your cloud resources as well as your migration efforts, further accelerating your timeline toward achieving your objectives as you transform your business to the cloud.
In the next parts of this series, we will go over the remaining stages as defined in the 5D's of IT-Conductor's Cloud Migration Strategy. Stay tuned!