In-Depth

Beyond IaaS with Microsoft Azure

Paul takes you beyond IaaS and shows how you can modernize your approach to IT with Microsoft Azure for true digital transformation.

• By Paul Schnackenburg
• 09/24/2018

Over the last three months I've looked at how to deploy VMs to Azure, how to pick the right virtual machine (VM) size and other optimizations, followed by network and security best practices.

And while everyone in IT is used to running VMs and can continue to do so with Infrastructure as a Service (IaaS) in the cloud -- it's not always the right thing to do. In this article I'll take you beyond IaaS and show how you can modernize your approach to IT for true digital transformation (drink!).

The three main flavors of cloud are IaaS, Platform as a Service (PaaS) and Software as a Service (SaaS). To transform your company's approach to IT you should be moving from IaaS to PaaS wherever possible and use SaaS for workloads where it makes sense. Here, I'll give several examples of how this can be achieved in Microsoft Azure for legacy workloads that you're looking to move to the cloud. Next month I'll look at your options for new applications or where budget for re-architecting exists.

Sprinkle a Bit of PaaS in your SaaS
What's your backup strategy for your on-premises VMs? You probably have backup servers, most likely also VMs that run a backup server application. Once you've deployed production VMs to the cloud you'll need back them up (yes, even with durable storage in Azure you'll want to back up VMs to protect yourself against ransomware, user error and for compliance reasons). But you're not going to spin up a VM and install a backup solution to back up the rest of your VMs (although there are several options in the marketplace for this -- see Figure 1), unless you must for some external reason or the platform service doesn't fulfill your technical criteria.

As I looked at in part three, a good option is to use the built-in Azure Backup service that negates the need to manage the backup server and the storage and simply provide you a service to protect your VMs.

Let's pretend you've lifted and shifted a classic three-tier application to the cloud, but it's got a varied amount of load. Perhaps it's not used much during nighttime -- use Azure Automation to shut down all but one of the front-end VMs to save money and then automatically start the VMs again in the morning. Azure Automation uses PowerShell or Python Runbooks and the really cool thing is not only can you use it to automate cloud actions, with Hybrid Runbook Workers on-premises you can initiate runbooks that are executed against on-premises servers.

The back-end data storage for your application is housed in two high availability (HA) SQL Server VMs that you need to back up, patch, monitor, and manage, as well as protect from malware and hackers. If at all possible, shift any database workloads to a PaaS service -- for SQL Server the Azure SQL Database as a Service (DBaaS) has near-feature parity with a full SQL Server, is much more cost-effective and removes much of the management overhead. If you absolutely need a "real" SQL server, use the new Managed Instances (in preview) where Microsoft manages the VM but you can use the full programming surface of a SQL Server, easing migrations of on-premises applications. Speaking of migrations, make sure you check out the Database Migration Service (DMS), which will help you move on-premises databases to Azure SQL Database, Managed Instances, MySQL or PostgresSQL in Azure.

The Web front-end VMs also have management overhead -- look to see if you can move your Web server load to Azure Web Apps instead. Again, it's a platform service, removing the need to manage the underlying VMs, with full support for ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP or Python. If you need to run on Linux that's supported in Web Apps, too.

This example application may have had a hardware load balancer/firewall in front of it when deployed on-premises, while you could use any of the very capable (and expensive) virtual appliances from F5, Kemp, FortiGate and others, use the built-in Azure Load Balancer platform service instead. It comes in a Basic and Standard SKU and can be deployed both as an internal and a public balancer, uses 5-tuple (source IP address, source port, destination IP address, destination port and IP protocol number) for building balancing rules and provides source network address translation (SNAT). If you're trying to protect your Web layer with a firewall, again you can pick virtual appliances from CheckPoint, Barracuda, Sophos or F5 (see Figure 2) or use the built-in Application Gateway, which provides SSL termination, URL-based routing, redirection, session affinity, WebSockets and HTTP/2. You could optionally also add the Web application firewall (WAF) with full OWASP 2.2.9 or 3.0 core rule set coverage.

So, instead of just using Azure Site Recovery's free migration feature (Figure 3) to move a collection of VMs to the cloud and paying for them 24x7 (probably costing you more than it would have cost to continue running them on-premises), you've now migrated the Web tier and the database tier to a PaaS service. You're also using automation to right size the resources for the load, minimizing cost and management overhead, in effect sprinkling a fair bit of PaaS on your IaaS deployment.

Limitations of Legacy Workloads
Obviously, this scenario won't work for every workload and your mileage may vary. The important point is that just moving VMs and continuing to do IT the same way you've been doing it on-premises is to rob your business of much of the opportunity of cloud computing.

If your application requires connectivity to your Active Directory domain you can run one or two domain controllers (DCs) in your virtual network, with the associated overhead and cost (including Site to Site VPN or ExpressRoute), or you can look at Azure AD Domain Services, which provides a managed instance of AD for your VMs (Figure 4).

A physics limitation that you can't work around with a cloud service is latency -- if you're moving a customer-facing application to the cloud, your users are likely going to experience better performance than you offered from your datacenter. Especially if this is an application used globally you should use Traffic Manager DNS load balancing to direct clients to the closest application, including on-premises instances, providing a true hybrid approach. But if this is an internal application that was sitting next to your users over gigabit Ethernet and it's now sitting in Azure there's going to be latency issues. Test often and test early in your projects to correctly estimate and manage this impact.

Wrapping Up
Honestly, taking into account all of these options and testing everything will take you longer than just shifting VMs to the cloud and calling the job done. But if you take the time to investigate what the cloud offers that can transform how you do IT, you'll improve far beyond just running your VMs in someone else's datacenter. And once you've done one application, you should be able to apply those learnings to the next one. Microsoft has excellent guidance in its Azure Architecture Center, including for tiered applications. Good luck on your journey to the cloud.