Let's talk IaaS

When looking at migrating an existing application to Azure, most people fall back on what they know, which is to move the virtual machines or use the lift and shift model.  While lift and shift appear to be the easiest way to move your legacy application in the least cost-effective way, this can be very useful and fast when moving legacy applications to Azure that have not been modernized or have dependencies on third-party resources that may not have been modernized as well. With on-premise Active Directory services being synchronized with Azure Active Directory, help and virtual machine management are provided through an already established process, helping you ease into the Azure model.  This means that the virtual machine and services you move to Azure can still leverage their service accounts to function, as well as the data access service accounts, to your databases. Databases and AD services can also be moved out as managed services, meaning you can use domain joining within Active Directory domain services and move existing SQL databases as they are. This can be used to help bridge gaps when modernizing your applications.

A hybrid setup for sharing services generally requires a permanent connection to Azure, like a Virtual Private Network (VPN) or Express route, so as to expose the internal corporate network to Azure securely. At the beginning of this chapter, links were provided to configure a VPN or ExpressRoute to Azure. Because of network complications and devices, I would suggest you use the links for these configurations. 

The following diagram shows moving virtual machines into Azure and leveraging a VPN/Express Route to access on-premise services, as you can see:

As we discussed in the previous chapter, Azure resources are deployed via ARM templates using PowerShell or Azure DevOps deployment services to deploy the resources.  ARM templates allow you to create, update, or delete all resources within the template. The templates use a parameters file that can be used to point at different environments and use a declarative syntax to define what resources are getting deployed, as we will see in a moment. Let's save the Azure DevOps version for our deployment chapter and focus on the PowerShell version. Let's discuss this structure before I show you a script that I use to deploy a virtual machine, which is modified from the standard one.