Application options for cloud migrations

- We've discovered different methods that you can use to find out what servers, applications, and services that your applications are using. Now it's time to delve into the strategy for migrating your applications to a cloud environment, and details that might not show up when you are mapping your dependencies. This will help you know what to look out for, and focus your attention on the details that matter in the context of migrating your applications to the cloud. I want to share with you, what are you going to do with your applications? You've made a list of your application, you know the dependencies, now we're talking about your strategy for moving it to the cloud, and you have a lot more options than if you're moving it just to another data center. Let me go through those options that you have for moving up to the cloud and they all begin with R. Let's go to the first one, that's rehost. This is where you would clone your servers, image it, send that image up to the cloud, and then reestablish that server as is. There's several benefits to this. If you have a system that just isn't going to operate with modern operating systems, or it's so sophisticated that hey, you have to just move these servers quite literally up to the cloud as is, then rehost is your answer. You just image that server, send it up to a cloud and install it on a cloud vm. This will be infrastructure as a service. Next, we take a look at re-platform the application, and this would be that you can modernize the app to work with the standard cloud platform. You would reinstall that operating system, reinstall that application along the whole dependency line in order to take advantage of the images that are available in the cloud. So you're not really rehosting, you're not imaging, and then moving that image all the way up, you're kind of redoing it here or replatforming this on the cloud servers themselves, and this would be an infrastructure as a service as well as rehosting. Now let's take a look at a little more sophisticated move, and that is refactor the application. This is where you take a lot of your code, your framework and just tweak it a little bit. Use most of your existing code and adjust it, just portions of it, to work with the cloud as a service provider. Let me give you an example, the SQL database. You might have an SQL database that you rehost, right? You would just image your server, quite literally, send that image up, and roll out a VM in the cloud with that image. Well, that is still you taking care of that SQL database. How about you decide that I'm going to use, let's say in Microsoft Azure, a thing called Azure SQL, and that is an SQL. And all you do is take care of the database. You don't take care of the server itself. You don't install SQL, you don't image SQL, you don't set up SQL, you let the cloud service provider do it. So you could very well be in a situation where this works out best for you, that you just adjust it a little bit according to the cloud service APIs and workflows, and then you don't worry about maintaining that SQL database. You just worry about using that SQL database. And this would be a platform as a service. And then that leads us to something that your application is going to be difficult to move to the cloud. You might have to rebuild the app, rewrite the entire code, and take advantage of the APIs and the application interface that the cloud service provider has. You modernize this. And again, what we're trying to do, the problem with rehost is that, hey, you have the same issues for with maintaining that, the same challenges and what you've done is you've just kind of moved it up to the cloud. With something like this, you let the cloud service provider take care of everything that's in the background. And this allows you to just focus on the application itself, not maintaining the servers, not making sure the operating system, not patching it, not doing this or that. You just deal with the interface. And again, this is going to be a platform as a service to rebuild that application to take advantage of what the cloud service provides for you and take you away from the actual maintenance of the infrastructure for that particular application. And then we have a situation where that application is just not going to work on the cloud. It's just not going to work. So you have this option and that is replace the application. You retire the old one, you find a comparable application that is offered by your cloud service provider and you just use that application. You somewhat transform the use of that old application, probably a legacy application, and you just use some kind of software as a service up in the cloud that you just have to worry about setting that up. You don't have to worry about maintaining it, you just use their software and use that as a service. So that's one option that you have for applications you just can't move to the cloud as is. The other one, you retain the application, you keep it, it's on your servers, it's on premises, you're not going to move this to the cloud. This is going to be a hybrid environment. And this is for those applications that for one reason or another, you just want to keep. So you have two options don't you, for applications that you can't move to the cloud? Either you replace it or you retain it. And if it cannot be moved to the cloud, then it's going to be on premises. And you're going to need to set up a hybrid environment in order to do this. But it's certainly an option that you have. So that is a look at the different strategies you can have. Each application is going to have its own strategy of how you migrate that one up to the cloud, dependent upon many factors. You rehost it, you refactor it, you rebuild it, you replace it, you retain it. Whatever strategy you choose, now you have more options to migrate your applications to the cloud.