I got an interesting question today. This is actually an extremely common one so I thought I'd take a bit to explore it. It's worth noting that I don't know the result of this blog post. That is, I don't know if I'll be right or not, and I'm not going to edit it. Let's see how this goes!
The individual emailed and said they were new to Azure and said:
Question for you. (and we may have made a mistake – some opinions and help needed)
A month or so ago, we setup a full up Win2016 server on Azure, with the idea that it would host a SQL server as well two IIS web sites
Long story short, they were mired in the setup of IIS on Win2k6, messing with ports, yada yada yada. '
All they wanted was:
- The ability to right-click publish from Visual Studio for two sites.
- Management of a SQL Database from SQL Management Studio.
This is a classic "lift and shift" story. Someone has a VM locally or under their desk or in hosting, so they figure they'll move it to the cloud. They LIFT the site as a Virtual Machine and SHIFT it to the cloud.
For many, this is a totally reasonable and logical thing to do. If you did this and things work for you, fab, and congrats. However, if, at this point, you're finding the whole "Cloud" thing to be underwhelming, it's likely because you're not really using the cloud, you've just moved a VM into a giant host. You still have to feed and water the VM and deal with its incessant needs. This is likely NOT what you wanted to do. You just want your app running.
Making a VM to do Everything
If I go into Azure and make a new Virtual Machine (Linux or Windows) it's important to remember that I'm now responsible for giving that VM a loving home and a place to poop. Just making sure you're still reading.
NOTE: If you're making a Windows VM and you already have a Windows license you can save like 40%, so be aware of that, but I'll assume they didn't have a license.
You can check out the Pricing Calculator if you like, but I'll just go and actually setup the VM and see what the Azure Portal says. Note that it's going to need to be beefy enough for two websites AND a SQL Server, per the requirements from before.
For a SQL Server and two sites I might want the second or third choice here, which isn't too bad given they have SSDs and lots of RAM. But again, you're responsible for them. Not to mention you have ONE VM so your web server and SQL Server Database are living on that one machine. Anything fails and it's over. You're also possibly giving up perf as you're sharing resources.
App Service Plans with Web Sites/Apps and SQL Azure Server
An "App Service Plan" on Azure is a fancy word for "A VM you don't need to worry about." You can host as many Web Apps, Mobile Apps/Backends, Logic Apps and stuff in one as you like, barring perf or memory issues. I have between 19 and 20 small websites in one Small App Service Plan. So, to be clear, you put n number of App Services as you'd like into one App Service Plan.
When you check out the pricing tier for an App Service Plan, be sure to View All and really explore and think about your options. Some includes support for custom domains and SSL, others have 50 backups a day, or support BizTalk Services, etc. They start at Free, go to Shared, and then Basic, Standard, etc. Best part is that you can scale these up and down. If I go from a Small to a Medium App Service Plan, every App on the Plan gets better.
However, we don't need a SQL Server, remember? This is going to be a plan that we'll use to host those two websites. AND we can use the the same App Service Plan for staging slots (dev/test/staging/production) if we like. So just get the plan that works for your sites, today. Unlike a VM, you can change it whenever.
SQL Server on Azure is similar. You make a SQL Server Database that is hosted on a SQL Server that supports the number of Database Throughput Units that I need. Again, because it's the capital-C Cloud, I can change the size anytime. I can even script it and turn it up and down on the weekends. Whatever saves me money!
I can scale the SQL Server from $5 to a month to bajillions and everything in between.
What the difference here?
First, we started here
- VM in the Cloud: At the start we had "A VM in the Cloud." I have total control over the Virtual Machine, which is good, but I have total control over the Virtual Machine, which is bad. I can scale up or out, but just as one Unit, unless I split things up into three VMs.
Now we've got.
- IIS/Web Server in the Cloud: I don't have to think about the underlying OS or keeping it patched. I can use Linux or Windows if I like, and I can run PHP, Ruby, Java, .NET, and on and on in an Azure App Service. I can put lots of sites in one Plan but the IIS publishing endpoint for Visual Studio is automatically configured. I can also use Git for deployment as well
- SQL Server in the Cloud: The SQL Server is managed, backed up, and independently scalable.
This is a slightly more "cloudy" of doing things. It's not microservices and independently scalable containers, but it does give you:
- Independently scalable tiers (pricing and CPU and Memory and disk)
- Lots of automatic benefits - backups, custom domains, ssl certs, git deploy, App Service Extensions, and on and on. Dozens of features.
- Control over pricing that is scriptable. You could write scripts to really pinch pennies by scaling your units up and down based on time of day or month.
What are your thoughts on Lift and Shift to IaaS (Infrastructure as a Service) vs using PaaS (Platform as a Service)? What did I forget? (I'm sure lots!)
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
© 2017 Scott Hanselman. All rights reserved.
