5 Steps to Accelerate your Cloud Migration with Dynatrace

How can Dynatrace help me reduce risk, move faster and achieve a better business outcome for my cloud migration project? Here are 5 recommendations for a better migration process.

I wear many hats in my job and while I officially call myself a “DevOps Activist“, my official title at Dynatrace is Director of Strategic Partners. In this role, I am leading a global team that works closely with our strategic partners such as AWS, Microsoft, Google, Pivotal, Red Hat and others. Across the board, the topics cloud migration, application modernization, breaking the monolith or hybrid cloud re-platforming have been a center point in many of our discussions with our joint enterprise customers. The key question we keep getting from our customers is: How can Dynatrace help me reduce risk, move faster and achieve a better business outcome for my cloud migration project?

For a recent technical workshop I did with one of our strategic cloud partners, I created a deck that aims to answer exactly this question. It discusses the top use cases on how Dynatrace can help in better planning, executing and optimizing cloud transformation projects. In this blog, I want to give you a quick overview of what I put in this deck and hope it gives you enough ideas for your own migration project in order to complete it successfully!

Before we talk about migrations, we must talk about how we gather the data to make better migration decisions – this is where our OneAgent differentiates itself from other approaches!

Secret Sauce #1: Dynatrace OneAgent

Many migration tools follow an agent-less approach. That clearly is easy to deploy – but – as you will read from my experience with our customers – only allows you to answer a small fraction of migration questions which is why enterprises that plan migrations, bring in Dynatrace.

With Dynatrace, we follow a combination of agent and agent-less approach where the “secret sauce” lies in our Dynatrace OneAgent (watch my Performance Clinic YouTube tutorial with our Chief Software Architect Helmut Spiegl). It really is – as advertised – a single agent you install on your physical or virtual hosts, roll them out as an Operator on Kubernetes or OpenShift, deploy them via Bosh, Ansible, Puppet, Chef, … Once deployed it feeds the Dynatrace Smartscape API with dependency information, does end-2-end transactional traces, captures logs and collects granular performance and system metrics:

For our migration projects, we simply roll out Dynatrace OneAgents on the existing infrastructure. There is no code or configuration change necessary to capture data and detect existing services. We let the OneAgent run and then leverage the data for the following key use cases. In addition to the OneAgent data, we pull in “agent-less” data by accessing APIs from endpoints such as VMWare’s vCenter, F5 Load Balancers, Data Power, WMI, JMX, … to give you a complete picture of your current environment!

My 5 Steps for a better migration project

In my migration deck, I have more use cases, but I think the following 5 are the essential ones everyone should be familiar with. It covers these key areas:

• Technology & Dependency Analysis
• Resource consumption & traffic analysis
• Database & functional migration

Step 1: Get to Know your Technology & Service Stack

“What’s in your stack?”

A question that many think they can answer, but most don’t answer correctly when compared with the facts. Before starting any migration project, you must have a good overview of all your hosts, processes, services and technologies. In Dynatrace, I have a couple of screens – or I use the Dynatrace API – to access all this data. An eye-opener for many – and that’s why I am showing you the following screen. We call it the Technology Overview, which gets automatically populated by what the Dynatrace OneAgent fully and automatically detects in your environment:

This screen is a great way to start answering a couple of key migration questions:

• Which technologies do we have in our organization? Where do they run?
• Which technologies are candidates to be moved?
• Which technologies are legacy and can’t be moved because not supported?
• For which technologies do we have alternative offerings?
• Who is responsible for each technology stack that needs to be included in the discussion?

If you can answer all these questions fine – if not: get your own Dynatrace Trial and start installing OneAgents.

Step 2: Understand your Dependencies: No Host or Process left alone!

While most of our cloud & platform partners have their own dependency analysis tooling, most of them focus on basic dependency detection based on network connection analysis between hosts. While this is a good start it only provides actionable data for the very classical lift & shift migration. Lift & Shift is where you basically just move physical or virtual hosts to the cloud – essentially you just run your host on somebody else’s hardware. For that, it is sufficient to only know host-2-host dependencies.

In my experience with customers that modernize applications though, a classical lift & shift rarely ever happens. We typically see a combination of re-architect, re-platform, re-purchase and where it makes sense a re-host (lift & shift). If you want to read up on migration strategies check out my blog on 6-R Migration Strategies.

In order to support these modernization strategies, it takes a more granular approach to dependency analysis as we have a more specific set of questions to answer:

• Which services do we actually have?
• What services can be migrated in isolation and which ones have a tight dependency?
• What is the network traffic going to be between services we migrate and those that have to stay in the current data center?
• What are the current usage and resource consumption patterns of services and what will it cost us when running in the cloud?

Dynatrace OneAgent gives you all the answers to these questions as we detect all services automatically, their dependencies and the resource consumption. This data is available both in the Dynatrace UI as well as through the Dynatrace Smartscape and Timeseries API:

All of this works for those hosts where you have installed a Dynatrace OneAgent. But – how do you know you have all hosts covered? Do you even know which hosts are actually part of the environment that you want to migrate? Dynatrace also has an answer for this question as we show you those hosts we are aware of, but that aren’t currently monitored:

Remember: This is a critical aspect as you do not want to migrate a service and suddenly introduce high latency or costs to a system that you forgot about having a dependency with!

Step 3: Detailed Traffic Dependency Analysis

If you want to lift & shift certain hosts, you need to know the network usage between these hosts that you intend to move and those hosts that will remain where they are. Knowing this data allows you to better calculate your future costs (as you have to pay for incoming & outgoing network traffic) but also allow you to make a better decision on

• Where to reduce data transfer in general?
• Which hosts not to migrate because of too much network traffic?
• Where to invest in data compression?

The following shows one of the slides I use to answer the question: What happens if I move this group of servers?

To answer this question simply put a Dynatrace tag on those hosts you want to migrate and then extract the network usage information from these hosts to those hosts that don’t have that tag. Dynatrace allows you to define manual or automated tags where automated ones could be extracted from existing metadata, e.g: part of the hostname or any environmental data, e.g: VMWare host groups. The data extraction can also be fully automated through the Dynatrace Smartscape & Timeseries API:

This data is also available on a process level as shown in the following screenshot – both live and historical:

Step 4: Smart Database Migration

Database migration would deserve a blog post on its own as there are so many questions we can answer with Dynatrace data to ensure a successful migration. Let me list a few questions I hear all the time and show you some screenshots of how Dynatrace answers these questions:

• What databases do we have, and which ones are candidates for moving?
• What’s the resource consumption of our database servers right now and how much do we need to provision if we do a lift & shift?
• Which applications and services are depending on a database that might be impacted by a migration? Which ones should remain co-located?
• What’s the current performance of key database queries and stored procedures? What tables and data are candidates to extract into a cheaper database system?

Which Database to migrate?

Dynatrace automatically detects and monitors all your databases used by your applications and services once the OneAgent is installed. This data allows you to decide which databases are good candidates to migrate or which ones are candidates to replace with a different database service in the cloud:

Right-Sizing your database instances!

If you lift & shift, it’s a great opportunity to right-size your database instances. Dynatrace tells you what the current resource consumption is during regular business hours, peak loads and low loads. This data allows you to save costs while still ensuring perfect database performance by choosing the optimal instance size on your target system:

Co-locate depending services & apps

If you move a database – which applications and services that have a tight dependency on this database need to be migrated as well in order to be co-located? Which services are actually using these databases? And what type of queries or stored procedures are used?

Dynatrace tells you exactly which query or stored procedure is called from which service or application at which time. This allows you to reduce the risk of migrating a database, a table or a stored procedure away from a critical service that should better be co-located with the database:

Optimize Query Performance and Data Storage Cost

If you have a large relational database that costs you a lot of money (hardware & license) and you plan to lift & shift it – why not take the chance and do two things

• Optimize the performance of key queries
• Extract less critical data into a cheaper database storage option

Dynatrace tells you exactly which queries are executed by which application, what the performance is and how it impacts the overall end-user transaction performance. With this data, you can optimize those queries that are business-critical when migrating them to the cloud. On the other hand, you can migrate some of the data for less critical transactions, e.g: read-only reports to cheaper storage which will save you operational costs as you can potentially scale down your existing RDBMS licenses.

Step 5: Functional Migration vs Resource Migration

When we think of migration or application modernization, we typically think about migrating a complete application or service. There is an alternative approach to this which I would call: Functional migration!

With functional migration, we only migrate functionality where we gain a business benefit from the actual migration. To give you two examples:

• if you top revenue-generating feature is used by users far away from your data center you may want to select this feature, move it to a cloud region that is closer to your end-users, and with that make this feature even better as you improve end-user experience.
• if you have a feature that relies on dedicated hardware and that users only execute once per week (e.g: weekly report) then you are wasting a lot of resources while this feature is not used. Moving this to an on-demand scalable cloud infrastructure will reduce cost while maintaining the same user experience level.

Dynatrace gives us usage information on both backend services, frontend API services or user-facing features through Dynatrace Real User Monitoring. This allows you to better understand whether you have any seasonality in your feature or API usage or whether you have any geographical usage hotspots. Take this data to make decision on whether migrating individual features might be better than migrating complete applications, hosts or data centers:

Secret Sauce #2: Dynatrace API

While the OneAgent is the secret sauce #1 when it comes to data capturing, it is the Dynatrace API which is the secret sauce to efficiently and automatically use this data for use cases such as speeding up your migrating planning by feeding Dynatrace data into your migrating tools.

There is a lot of documentation on the Dynatrace website and there are a handful of examples on the Dynatrace GitHub repo: https://github.com/Dynatrace/dynatrace-api. These examples include e.g: how to extract Smartscape & Timeseries data into an Excel Sheet or how to generate your own dependency graph visualization based on the Smartscape API.

I also wrote my own little project to show the power of the Dynatrace API – it is the Dynatrace CLI which allows you to conveniently query dependency and timeseries data: https://github.com/Dynatrace/dynatrace-cli

Get Started and Migrate Better with Dynatrace

I hope this blog gave you the answers to the questions I paraphrased in the beginning: How can Dynatrace help me reduce risk, move faster and achieve a better business outcome for my cloud migration project?

The best way to get started is either signing up for a Dynatrace Trial or reach out to your Dynatrace team in case you are already a customer. Once you still the OneAgent you can get started. In case you have questions feel free to reach out us – we have experts that can help you with your migration project.