Designing Solutions That You Are Migrating To The Cloud

In this post, I will discuss some trends that I have noticed when people are planning the migration of a service to The Cloud.

I am going to make this post as cloud-agnostic as I can, with my limitation being that I only work in Azure. I don’t know AWS or Google Compute, but I know their offerings are similar to many found in Azure. So, I suspect that what I talk about here will apply across the Big-3 clouds.

My Observation

Let’s say that you are migrating a 2-tier application to The Cloud. You’ve been running it on-premises or in co-lo hosting until now. There’s Checkpoint firewalls, some Windows/Linux web servers, and a database cluster (let’s go with SQL Server Always On for this example). You want to move this to The Cloud.

The common thing that I see, by customers and consultants, is that they will look to take this design and redeploy it identically in their preferred cloud. They’ll want the same firewalls, virtual machines with the same OS, and a VM-based SQL Server cluster.

What has been accomplished with that migration? All they’ve done is move the problems. Nothing has really changed other than the location – OK, that’s a bit untrue because the cloud service might offer some automation, security, bandwidth solutions that the co-lo hosting company did not. But essentially, the application is identical. All the other benefits of The Cloud, such as elasticity, flexible (maybe even lower) pricing, easier disaster recovery, lower operational costs, etc … they cannot be delivered because the solution is identical.

The Objections

Why would one struggle to figure out how to build an S2D cluster with expensive VMs (for disk and network throughput) and Premium/Ultra SSD disks (for IOPS and lower latency), build up availability sets VM clusters, when you can just turn on a cloud service and get an Enterprise SKU of SQL Server with always-on availability? Adopting that cloud service WILL be cheaper, easier, near instantly available, and never quire a patch deployment or upgrade by you ever again. Sure, I’ll hear the usual BS arguments now:

• Cost of the PaaS service: Seriously? You want to run Ultra/Premium disks with high-core count VMs with Enterprise licensing, and you think that will be cheaper?
• App compatibility: I’m going Azure-specific here because it’s what I know … SQL Managed Instance is SQL Server that you know, but in the platform.
• License mobility: Yup, Azure (sorry!) supports hybrid usage benefit for SQL Server in the platform too!

And as for the web servers: the easy solution is to use a platform service. It is simple and will run your IIS or Tomcat code. And depending on your cloud, it will support IP filtering, firewall or full blow Layer-7 WAF and/or DDoS protection. Time to deploy? A few minutes. Future maintenance? Near none. DevOps integrations: way more than any VM could ever offer.

Cloud, Cloud, Cloud

When you are going to The Cloud, you need to leave the year 2008 behind you. I pick that year because that’s when I first attended cloud events and most people attending were there to learn how to stop The Cloud. Those people still exist, some consciously thinking like that and some unconsciously sabotaging their customer/employer.

Traditional solutions can be done in the cloud. But you have to ask: should they?

By The Way

How would I design the above scenario in Azure?

• Database: Azure SQL, which is an always-on (triple) cluster. I might go with Managed Instance if app-compat was a concern.
• Web services: App Services, Linux/Tomcat container from the gallery

Options:

• Redis Cache for database performance.
• CDN for static web content performance – large amounts of static content could live in a storage account with CDN support too.
• ASE instead of normal App Services if I need to bring a WAF into play.
• If using ASE, I could enable DD0S Standard Tier protection, with L4 on the VNet and L7 in the WAF.
• Traffic Manager to abstract the deployment from the cloud, enabling mobility of the service.