On Prem To The Cloud: Getting Started (Ep 1)
>> Hey man. You-all got a bunch of those old school apps still running in your datacenter and you want to modernize them and get them into the Cloud, but you don't know how or where to get started. Well, join me and Steven Murawski as we kick off a new series on the DevOps Lab called On-Prem to the Cloud. [MUSIC] >> Welcome to the DevOps Lab.
Today, we're going to be kicking off a brand new series called On-Prem to the Cloud. Look man, we're constantly showing the latest and greatest technologies in Azure. As cool as that is, you viewers have told me you wanted to take a step back because you-all still have apps running on machines in your datacenter and they'd been running for the past, I don't know, 10, 15 years and they're still vital. But how do you get those apps into the Cloud to get all the goodness from the Cloud? Today, we have a very special guest with us, Steven Murawski, and he's going to dive in and show us how do we get started, how do we plan for this migration, what will this migration look like, things like this. Welcome to the show Steven. What's up?
>> Abel, awesome to be here, awesome to be talking to you about this particular topic. Over the course of my career, I have administered many, many Windows apps and services and things and worked in configuration management space and how we move things, whether we're moving them inside of a datacenter, whether we're moving them into the Cloud, there are some idiosyncrasies, there's some weird stuff that can happen, so I love that we're talking about this. >> This is awesome. You know the story. We've got apps. If you're in any type of enterprise, you've got those enterprise back-office apps that they've been running for like 20 years. They're still vital, we still need them. They're sitting underneath some developers desk but we need to get them into the Cloud.
But where do you even begin? How did you even get started with something like that? >> Well, there's a lot of ways that you can approach this. But I found a couple of key things. Number 1, the first thing, absolutely start small.
There's a whole lot of people who, I've got a seven-year plan to get to the Cloud or you know what? We're gong to move our entire enterprise estate into the Cloud. Those are great long-term goals, those are great efforts, those are great directions. But when we really start, we really want to make sure that we're getting a handle on what we actually have to move and where we're going to go because there going to be unexpected things.
There's that app that is running that we forget that depends on the FileShare. There is the app that it's talking to, it mostly talks to one database server. There's a lookup every now and again over to this other thing over here or calls this other backend service for batch processing. Or the batch processing job needs the database that the app relies on, but we don't necessarily see that.
The very first step, we start small and we start with discovery. When you start researching how I want to get started in this whole process of migrating to the Cloud, you may go out and we got some great documentation out there. We've got the Cloud Adoption Framework for Azure, that's got pages and pages and pages of excellent guidance and documentation about how we can make this process happen. We also have tools, things like Azure Migrate, where it builds in these processes and gives you a step-by-step on how to go and discover and make these huge efforts to get yourself into the Cloud. I like to take a little bit slower approach or smaller approach, but also a little bit more generic approach in terms of the tools that I want to use or the tools that I want to just understand my environment to begin with. We're going to take a look at this Mercury Health application.
We're going to use Application Insights, which we would often use to discover performance or trace errors and things like that. We're going to use it in our on-prem server to help build an understanding of how it connects to other things in my environment. This is a lesser known capability of Application Insights. It's Mercury Health app. On this machine, there's a website, there is a backend service.
We're going to focus on the website story, but I'll talk a little bit about the service part of it and things as well. Now I have this app running in a couple of ways. We're just going to take a look at IIS Manager here. You can see we've got our default website.
I've got one version is Mercury Health app stopped and I've got Mercury Health instance with no App Insights. If you built a newer ASP.NET application, chances are App Insights bindings are there for you. It's part of the new templates. But when we talk about an application that's 10, 12 years old, might not be there. An Application Insights gives us a great way that we can wire up IIS to instrument those applications that don't already have Application Insights.
We don't have to make any code changes at all and we can start taking advantage of these capabilities to start gathering that information for this migration. Because before I can migrate, I got to know what I need to migrate. >> Hold up at that. Just one second because I think you just made my brain explode a little bit because I understand Application Insight, we instrument out the code and then it gathers a bunch of insight on what the app is doing, so performance, information, things like that. You're telling me I don't even have to instrument my app.
I don't have to change source code. Just by the fact that my app is running in iOS, you'll be able to turn on App Insights and get telemetry and get, I guess, a whole app diagram and everything. >> You bet. Just to show you that there's nothing up my sleeve, I'm opening up this application here.
We can take a look in the bin folder, there are no Application Insights DLLs. I do not have the library for Application Insights associated to this website. I stopped the other application. You can tell that there's nothing up my sleeve here. I will go to the application here. Can see it's running.
I've got my Home, my Exercises, that's actually reaching out to the database, grabbing some fun stuff for me. There are some just running. I can see a video about that, I can see videos about health swings, all sorts of fun stuff. Now we are going to instrument IIS right now. First, we have to do a little prep. I'm going to use PowerShell.
Application Insights, the agent to run an iOS is distributed as a PowerShell module. I'm in Windows PowerShell 5.1, which is stuck on pretty much any recent modern Windows Server Operating System. Some execution policy and I'm just going to update my new Get-PackageProvider and allow myself to more easily install from the PowerShell Gallery.
I'm going to make sure I have the most current version of PowerShellGet. Now need to get to another shell because we've made some environment changes in that one. Now we're going to go and do the hard work of installing the Az.ApplicationMonitor module.
This is what's going to give me the capability to instrument IIS and all of the.NET applications that are running inside of it with no code changes. It's going out to get that module for me. I clicked a little faster.
Once it's installed, I can run enable Application Insight monitoring and give it my instrumentation key or I can give it the full connection string. Either one will work. For right now, they're deprecating just the instrumentation key where they want you to go the full connection string.
Like I said, right now either one works. What that's going to do is set a bunch of registry keys and update some information in IaaS and it's enabling this feature called codeless attach and it restarts IIS for me. >> There we go. That is all there is to making this thing work. >> I want to reiterate again, zero code changes. You just flip the switch on.
>> Yep, I've got the same app running here. what that does is it injects IS with the extensions that are provided. It will inject instrument at runtime for you so that you can get some of this rich information about your application. Let's hit a couple of pages. I did create ahead of time in the Application Insights resource.
Let's go to Azure. I can show you that here. I created one for Codeless Attach, so we can see this one separately. When you log in here, it calls your resource group, your instrumentation key, and your connection strings.
Those are the two things I could have provided. We started up on this application map. It takes a second for information to show up, I was also using this earlier, so we'll expand the time window.
It shows that I've got one instance, I've made a bunch of calls, and it's not only telling me about the application because in Application Insights, we would typically use this to get performance data, to get failure data, to get metrics about how the applications running, maybe some tracing but here, it's showing me the external calls that I'm making. We can see, it's going up to a SQL Server and that there's this plus two thing here. Let's expand that. It's going actually to two different databases.
>> Interesting. >> I'll go on the Mercury Health DB and I've got the master database is getting queried as part of this application, and we can see performance information. We can see the routes are getting called and performance of those.
That's all well and good. But for me, this hidden dependency thinks of if we instrument our app, say we want to move to the Cloud, which is the whole point of this series, I go and instrument my applications that I have had running here for years. Then, let them run for a week or two. I'm going to build up a pretty good map of all of the things that this thing connects out to. I don't have to go in and try to trace through lines of code, maybe even looking for code-bases that we might not even know where they existing anymore. Maybe they're built by contract or we don't have them anymore.
If you can't make code changes, you can drop this in and start getting these benefits. That helped discover what am I going to have to replicate or if I move my web application, what about my databases? I'm going to make sure I have conductivity back for things. >> This is awesome because man, this is a simple little demo app, but potentially, I could have an app that is far more complex than this where I don't know all the dependencies, and just by using this codeless instrumentation without changing a line of code, I get this nice map of all the resources my application really is touching on, right? >> Yep. it gets even more powerful if we can touch some lines of code. Let's pop back over into IIS Manager. Let's stop this guy, and we'll start up our main actual website here.
this one was instrumented for Application Insights. It was using a modern template, and it's exact same application, no difference, actually shares the same back-end database, so we will see the same exercises available. We would see the same nutrition and metrics information that's available. But this one is pointed at another instance of Application Insights. I can tell that, actually thanks to that PowerShell module that we just installed.
I can go and get Application Insights monitoring status, and it's going to come and tell me about the apps that are there and to tell me that my Mercury Health apps already instrumented. That's tell me that, hey, guess what? App Insights is already there and configured, so I'm not going to have to do anything. That Codeless Attach that we talked about, it will not override any application that already has App Insights configured. You don't have to be afraid that you're going to mess up one of your existing monitoring infrastructures. If you wanted to go and start capturing this information, you'd just be getting it for all of the ones that are not instrumented.
>> Cool. >> We can see it's instrumented. Let's go here and that data is landing in the Mercury Health App Insights Instance. In App Insights, we can create an instance per application, we can have an instance per service. How you want partition your App Insights is going to be vary based on your needs. But when you can make code changes, you can do fun stuff like labeling the different applications.
I could call this Mercury Health web, if we bring in that service that we talked about, the batch upload service I just briefly mentioned before, we could label that, and we can start seeing all of these components come together on one map or if I'm starting to break up microservices, where I can label all the individual components, so we can see the flow of things through them. If can't make code changes, it's a little harder to make the change to the role name. I don't think that's exposed in configuration at all, so you have to be able to make a small code change. I can actually show you what that code change would consist of. It's not very big. That code change is this.
>> Nice. One line is [inaudible] >> That's the code change to get it to label. It doesn't have to be hard-coded in your code, it could be coming from an configuration or from an environment variable or something like that but you just have to be able to add a line like that into your application as you connect up Application Insights. But just going back to why I would use Application Insights to start this discovery process. Because one of the considerations as we move to the Cloud is how do I write size, how do I make sure that the VM I'm putting it into is sufficient or the service that I'm going to put it into is going to perform sufficiently? Well, in addition to getting this discovery formation, I'm now starting to also build up a profile of how my application behaves.
I could start to see how long some of these calls are taking. I can start to see what the duration is on some of the performance on some of the pages. Now, I have something to compare against when I move that application into the Cloud. Not only I'm I doing a discovery, but I'm preparing myself for what performance I need to look for, and that way, I can make sure I'm getting the right level of performance out of the Cloud resources I'm provisioning. >> Wow, that is super cool.
I didn't even think about this, by using App Insights, you now have the ability to really map out what your app is doing, what resources it use. Nobody has really looked at this app in 10 years. This is a great way to figure out what's going on in our app. Above and beyond that, like you just said, wow, we can get a benchmark performance too.
On-Prem, this is how it runs. When we do move it into the Cloud, we want to run as fast, maybe even faster, so it gives us a nice baseline. Well, that's awesome stuff. You've built out this wonderful map.
We figured out what we need to do. I guess, what's the next step? >> Well, the next step I think that's going to be queued up a little bit for your next show. That's going to be determining what do we move first? Do we move our app? Do we move our database? Do we move this unrelated service? It's really one of those it depends scenarios, but I think, you're going to have a fun time with this series, Abel. >> Yeah, this is really important to me just because these are the types of stuff. These are real-world problems that we all run into, and don't get me wrong, I love showing the latest Static Web Apps and the Pipeline that automatically gets created and Cosmos DB, awesome frequent stuff, but we have some real-world problems, and hopefully, with this series, it lead us through how to solve this. Thank you so much, Steven.
This has been really awesome, super helpful stuff. Steven walked us through a couple of different ways to figure it out exactly what our app is doing, and how to even start planning for your migrations. If you want to learn more about this, check out this great blog post in the links down below, where Steven really explains that we think in great detail. We also have a lot more links and stuff to follow, go ahead and check those out. Like he said, on the next episode, we're going to continue down this path of On-Prem to the Cloud, and we're going to get started migrating.
Join us next time on the DevOps Lab. [MUSIC]
2021-02-24 16:25
