On Prem To The Cloud: Getting Started (Ep 1)
Welcome to the first in a series on moving your applications to the cloud. Together, with Abel Wang and the rest of the Cloud Advocacy DevOps team, we’ll embark on a journey to show you the possibilities available to migrate your application to the cloud. I was lucky enough to start the series off with Abel, where we introduce the application environment and start to tackle the challenge of moving to the cloud.
Our team was called in to help the Mercury Health team migrate their application into Azure. The application environment consists of a ASP.NET website hosted in IIS, a Windows service, and a database in a SQL Server. The team isn’t quite sure where to start. They’ve looked at Azure’s Cloud Adoption Framework and tools like Azure Migrate. While those resources look promising (and have lots of great information and features), I recommended a slightly different starting point.
Keys to Migration
When it comes to moving to the cloud, there are a lot of moving parts. I find that there are two keys to successful cloud migrations. First, start small – find the smallest thing to move and change the fewest things about it. Second, understand what success looks like for you, your team, and your organization. The steps you take now can set the stage for future success.
Starting small means focusing on one simple application environment. As we move to the cloud, we are going to be adopting new tools and running our application in a new environment. These changes can make it hard to determine whether or not you’ve moved an application successfully. The more we understand about the application or service(s) we are moving, the greater our chance for success. As we migrate, we are going to be learning – increasing our familiarity with Azure which will make future projects more successful.
Understand What Success Looks Like
The second tenant to successful migration is a clear understanding of success. Migrating to the cloud is a fuzzy concept and can be done for a number of reasons. Some of those reasons will influence how much change you are willing to endure in the process of moving to the cloud.
In addition to the broader goal of why you are moving to the cloud, you’ll want to understand what running well looks like (or at least what current performance levels are). Since you’ll be running on hardware that’s not directly under your control, you’ll need clear expectations of how your application performs to help allocate the correct amount of resources. Without this information, you could be paying too much for your infrastructure or be under-performing compared to your on-premises experience. Unless you already know that you need to improve performance or that you have capacity to spare, you’ll likely want to achieve a similar level of performance to what you currently enjoy.
Identifying Your (Inter)Dependencies
I like to start my migration efforts by developing a strong understanding of to what my application connects. When we move into the cloud, some services or data may need to stay on premises and we’ll need to ensure that they can be accessed by our application. Some will need to move to the cloud and stay close (network-wise) to the application. Until we understand to what our application connects, we run the risk of breaking our application behavior in the move.
One tool that’s very useful in this process is Application Insights. While its primary function is application performance monitoring, our discovery process can use Application Insights to help develop an awareness of the services to which our application connects. There are two primary methods of integrating Application Insights that we’ll explore – Codeless Attach and by using the SDK.
Even though Application Insights is a service that runs in Azure, you are not limited applications running in Azure to use it. Application Insights also offers easy access to workloads running in IIS via the IIS agent (or Status Monitor V2)
The Application Insights Application Map is there to help you visualize and trace problems across distributed applications.
Guess what… Most applications have some external dependencies. Applications without dependencies are typically called appliances or virtual appliances. Those are typically self-contained ecosystems where you don’t have much control.
Almost everything else has some sort of interaction and the Application Map helps us discover them. This is especially useful for applications with no team assigned to maintain them or that may have been provided by contractors or consultants.
This brings us to how we start capturing data with Application Insights. The first method we’ll explore is Codeless Attach. Codeless Attach allows Application Insights to monitor your application without changing your code. Configuring it on Windows Server is very easy.
Install-Module -Name Az.ApplicationMonitor -AllowPrerelease -AcceptLicense
Once we have that module, we need to enable monitoring on IIS. You’ll need the connection string from your Application Insights resource.
Enable-ApplicationInsightsMonitoring -ConnectionString xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Once that’s done, any application that does not already reference the Application Insights SDK will be automatically instrumented.
That point is important – if the application already has the SDK, then you’ll need to configure that application through code or configuration file to report to Application Insights. It also means you won’t disturb any existing Application Insights monitoring by enabling this for other un-instrumented applications.
You can check on the status of each website in IIS with the
Instrumenting your Application
The other option would be to include the Application Insights SDK with your application. Many recent .NET application templates already include the Application Insights SDK, so it is merely a matter of configuring the instrumentation key or connection string.
There’s a ton more that you can do, including customizing how your application shows up on the Application Map by setting the
cloud role name and/or
cloud instance name. Despite the property names, they can be used regardless of where the application is running. They help identify the application and server (or service instance) it is running.
public class MyTelemetryInitializer : ITelemetryInitializer
public void Initialize(ITelemetry telemetry)
//set custom role name here
telemetry.Context.Cloud.RoleName = "Mercury Health Web";
telemetry.Context.Cloud.RoleInstance = Environment.GetEnvironmentVariable("computername")";
Gather Your Data
Once you’ve got the application instrumented (either via Codeless Attach or by including the Application Insights SDK with your application), you’ll need to let it run for a while. Some dependencies may not be accessed very often, so letting the discovery period extend for a while – days, weeks, or even a month – can help surface more seldomly accessed resources (maybe there’s a batch job that only happens at night or over the weekend).
Now that the Mercury Health team has their application instrumented and collecting data, they can see that the web application depends on access to two databases running in SQL Server. This is a pretty straight-forward application and is a great candidate for us to try moving to the cloud.
Bonus Data: Performance Baseline
While Application Insights has been running to gather your Application Map details, you have also been capturing performance data. This can become your baseline for how your application is expected to perform in the cloud. You’ll see the impact of calls from the application to dependencies, to help you evaluate if that dependency needs to move to the cloud as well – or if it can be left on-premises for the time being. It can help you gauge the effectiveness of the service SKU you are running upon and whether you need to scale it up or if you have room to scale it down and save some money.
Start Planning Your Move
What Should We Move?
Now that you have some data about the application and its dependencies, you can start to plan your move. We’ve seen that the application has minimal external connections and we have some baseline performance data.
Moving the application and database together would seem to make sense given the tight coupling and how page performance is dependent on results from the database.
And Now What?
And then, watch for the next in this series – coming soon!