Penny Pinching in the Cloud: Lift and Shift vs App Services - When a VM in the Cloud isn't what you want
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!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Nick
Akka.net works well in IIS if you register the actorSystem as a singleton. Most common, using a clustered web, service, and lighthouse setup allows you to work in a concurrent environment with the static actorSystem reference.
Petabridge has a good example of a signalr web client with a backend cluster.
So I guess the question is: can you please point us in the right direction to learn how to shift our mind set from 'old school File.Save(..)' to the new Storage based approach? Also how do we protect files so only authorised users can access them?
I do think that Azure's pricing doesn't always scale well - especially to zones outside the US (esp NZ / Australia for me), depending on the requirements and numbers of sites you run and especially if you're wanting SSL. Funnily enough, I wrote about it a couple of months back after your earlier "penny pinching" post (which was also very useful, by the way).
I'd be interested to know if I have a reasonable argument myself or if other people outside the US have similar views. I may have completely overlooked some of the fine-tuning options available with Azure DTUs or even pricing tiers.
An issue I've had for awhile is when I have to create an environment with a domain controller. Usually my go-to VM template is just to take the OOTB SharePoint VM set which comes with an app/sql/ad servers. You get the whole package. It's super convenient for just about anything Windows related.
The problem is that I would rather not have to use a VM for AD. I know that there's Azure AD, but can I just create an AD Service and an app and sql server VMs and then configure those VMs to join an Azure AD domain?
Thanks in advance.
These prices come with MSDN Subscription where get Azure benefits. See here for details: https://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/
Best Wishes, Oleg
The other thing here is that resources are so extremely limited that for a limited budget (I'm a student), I cannot get any real work done. In the end I started running vm's which run the heavy tools at a 'local' provider. This while still using azure (app service/azure db) for the pretty straightforward code 'n deploy thingies.
Following on from the above updates can sometimes require a reboot or a restart of a service. That requires downtime be it 1 minute or longer. If this happens automagically then how do you plan for that, let you customers know?
Towards the end of the article you say "Lots of automatic benefits - backups, custom domains, ssl certs, git deploy, App Service Extensions, and on and on. Dozens of features.". How are these automatic benefits? Certainly backups maybe, but Git deploy? Nope still using SVN, App service extensions - nope have to change app, SSL certs - nope I have to switch my cert from old to new and do stuff, in other words not automatic. I guess we have different thoughts on what automatic means. To me automatic means press Go and that's it. Pretty much nothing about Azure is press go and that's it. Normal it's change how you app works, deploys, builds, source control etc... then maybe it will work.
Currently as I understand it SQL Azure doesn't support anything but the database engine side of SQL Server so SSRS, SSIS, SSAS, SQL Agent is all out the window - so if you are using any of them you're also out of luck.
The introduction of the web jobs functionality though gives an effective alternative to this when using app services for website hosting.
I had Azure VM with SQL Server installed on it. I started deploying more ASP.NET Core Websites and while processor was OK, there was not memory enough (https://github.com/aspnet/Hosting/issues/781). This was resolved with some fixes in ASP.NET Core but still I came to the point that I need only extra 1GB of memory which in example here would mean a jump from DS1 VM for 50.59$ to DS2 101.18$, that means 1GB memory would cost you another 50.59$. Unacceptable. You would get 7GB memory and extra core which are not used, not even environment friendly.
Thinking further, I decided to get rid of SQL Server as it eats resources. I moved my databases to Azure SQL Databases which I am happy with because of all benefits Scott mentioned except one, the cost for small databases (https://feedback.azure.com/forums/217321-sql-database/suggestions/18932212-new-pricing-tiers-x-small-databases).
Moving further, databases were moved, but more ASP.NET Core websites are coming and again, I just need that one 1GB Extra memory.
That's were I started thinking about moving my VM websites to App Service Plans, where the given resources don't count your OS resources (I guess) + all the benefits Scott mentioned and I really like, including recently posted Continuous Delivery (https://blogs.msdn.microsoft.com/visualstudio/2017/04/25/automatically-build-and-deploy-asp-net-core-projects-to-azure-app-services/).
Thinking ahead, but there is still an issue, at some stage I would need an extra 1GB+ for my websites, so I would need to still double the cost to S2, and recently my websites started using free Lets's Encrypt which is easy to deploy on IIS in seconds (https://github.com/Lone-Coder/letsencrypt-win-simple) but a pain in Azure Service Plans (even there is some extension), unless I am not aware of a one click solution.
The decision was done, I had to move away from Azure VM and cannot consider Azure App Service as I cannot scale granularly Memory and Processor. I moved to UK VM Cloud provider, who offers on the top only SSDs and you can increase/decrease memory by 0.5+GB or add/remove 1+ processor. The expected cost is almost a half what I used to pay.
This is my scenario. In my scenario, this worked perfectly as I don't need the other perks of Azure as I don't use them. I simply need to run the websites. I still keep my database in Azure SQL Databases as this seems to be more beneficial than having my own SQL Server, even the databases are small and lower cost would be welcomed. I also backup my websites through Azure Files/Folder Backup.
Hope my Penny Pinching will be also helpful for the readers :)
Cloud services and azure batch do exactly what you need. Functions too but they don't work very for long running jobs on the consumption plan.
The exact use case Scott outlined in the article we've implemented with about 50 websites. The app service services on azure are awesome and easy. My only complaint is the terrible disk IO, it is so slow and any process that requires it will suffer.
And I use one SQL Server DB, Basic tier, and segregate different sets of data by schema (dbo, imo, ths,tht, etc).
So I can host as many data-centric websites as I want for like $20-25 per month.
These websites are not heavy use at all, but they all need to be there for various reasons.
So yeah, I like Azure for penny-pinching.
I wish App Service was cheaper for running 1 website a little bit like Heroku where it starts at $7 with SSL included with a custom domain.
There is a lot things that are not needed with the Basic and Standard plans for just a single website.
Maybe providing a smaller size VM or getting the Shared Plan out of preview and providing SSL/Custom Domain
For students, you can check Microsoft DreamSpark (I believe a new name is Microsoft Imagine) benefits for Azure.
See here:
1. https://azure.microsoft.com/en-us/pricing/member-offers/imagine/
2. https://imagine.microsoft.com/en-us/Catalog/Product/99
Additionally, you can active Visual Studio Dev Essentials Azure Subscription, which gives you $25/mo. For details, please see here: https://azure.microsoft.com/en-us/pricing/member-offers/vs-dev-essentials/
Full list of offers: https://azure.microsoft.com/en-us/pricing/member-offers/
And again, low rates for App Service like you can see in Scott's screenshot available for Visual Studio subscribers with additional credit of $50 - $150 per month.
https://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/
Best Wishes, Oleg
- S2 App Service Plan with 3.5 GB RAM and 2 cores costs $148 per month.
- Linux VM with 2 cores and 3.5 GB RAM costs $55
- Windows VM with 2 cores and 3.5 GB RAM costs $84
I just don't understand why an automated VM should be almost 3x more expensive than a Linux VM.
Our best penny pinching tip for Azure is to make use of the Elastic Database pools. They have cut our SQL costs a LOT.
Thanks!
Comments are closed.