Minimum Viable Product - Part 9 - Azure Hosting

Good hosting costs money

You read that right, good hosting costs money. In my non-scientific testing assessment of hosting provider costs, .NET hosting costs a premium when compared to PHP or Rails hosting. The purpose of this series is to get a minimum viable product to market as quickly as possible. I think using cloud hosting is the future and the future is now. This post focuses on Microsoft Azure hosting and will only be able to touch some high level topics. I'll have to leave the detailed implementation bits to your more than capable googling skills. So let's get started.

Why host in the cloud?

I fully embrace cloud hosting. I know several companies out there that still think cloud hosting is risky and resist moving away from running their own servers on-premise. While not risk-free, here's my list of reasons that you need to get onboard with cloud hosting in general whether it be Azure or Amazon Web Services (AWS):

  • Servers and networks are managed by teams of people - Coming from a networking background, this hurts to say; you can get rid of the infrastructure guys and get more developers. The payroll expenses (or turnover) of in-house Network/DevOps teams are very expensive and frankly are no longer necessary. I don't have to worry about keeping servers patched, leases coming due, hardware failures or some jerk that has all the knowledge and we can't fire them.
  • Cloud services scale well because they are virtualized - Some of the same companies finding cloud hosting too risky also find virtualization too risky as well. As a result they are unable to see the value of being able to scale with a few mouse clicks. Cloud services are elastic in nature and can be scaled on-demand as opposed to having a rack of servers 'just in case' you need them.
  • Auto-deployments speed up my iterations - Cloud hosting is highly integrated with source control these days. Whether it is TeamCity, Octopus Deploy, AppVeyor and others; cloud providers reduce the work it takes to continually integrate.
  • Blob storage - Disk space can be cheap but always seems to run out if you're running a local network or server drive. With cloud blob storage you are able to grow disk sizes very easily.
  • Content delivery networks (CDN) - For next to nothing cloud providers will send your public files to key areas around the world for reduced latency.
  • One-stop shop - Cloud providers make it very easy to integrate with SMTP, Redis and other services that you'll likely need at some point.
  • Durability - If your risk management people are concerned about backups and service redundancy, the cloud makes it very easy to geo-replicate services.

Azure provides all the services you'll ever likely need for hosting a scalable web application, however let's take a moment to compare it against AWS. First off AWS doesn't offer native continuous integration from source control to your web application. AWS is geared more towards the Linux and Rails crowd. You can run Windows Server on AWS in the form of virtual machines. The major drawback here is you'll have to manage OS updates, security, etc; typically through remote desktop. One of the benefits in my list above was the ability to not do that. If you want to run on AWS, you'll have to stick to Linux to avoid having to manage the OS using their OpsWorks service.

I've worked with Umbraco instances hosted on AWS virtual machines before and it worked wonderfully. However there were always times that we had to do our work of upgrading servers which included the SQL server instances. To be sure, in my humble opinion, AWS seems like they are a very well oiled machine when compared to Azure in overall cloud operations. However, Azure does hold a few key feature that makes it stand head and shoulders over AWS if you're hosting .NET — the Azure Websites Service.

How to get the most out of Azure Websites Service

The Azure Websites service is not to be confused with other Azure services like the SQL or Blob services. It's its own thing. If you'd like to do traditional VM's similar to AWS, you can do that on Azure as well but it is worth noting that we're not using the VM service when we talk about Azure Websites service.

Developers are smart people, often times they are asked to wear many hats at once. One familiar role they find themselves in is the DevOps person. Developers really just want to make cool apps, they don't want to install OS hotfixes, upgrade SQL server instances or figure out how to expand a hard disk that is filling up. Enter Azure Websites service which pretty much takes all of the pain of the DevOps hat away.

Azure websites provides a .NET web hosting environment configurable through the browser. Azure websites is a headless environment that has no GUI for you to remote into. It's underpinned by a bunch of cool stuff I barely even know about. It works just like a Windows server instance to power everything, but is focused on client/server interaction. The only thing that sort of resembles a server is the ability to FTP into the file system of your server.

FTP'ing into the server should feel weird if you ever need to do it because you can easily connect a variety of source control services to your server. Once you push a new commit to GitHub, your server notices it and deploys the code. Files that are tracked in your source control are replaced while untracked files are untouched (media, indexes, etc). This blog is configured this way.

Agencies and larger sites may choose to setup deployment slots. Deployment slots allows developers to map different branches to different slots. Each slot has its own URL and can be tested independently of the production slot. At any point you can swap a deployment slot with the production. The benefit is that you can test drive new features before presenting them publicly. Bear in mind when you perform a 'swap', you're asking Azure to change the production pointer from one slot to another. If the media files on one slot differ from another slot, you'll end up with missing files at some point. We'll cover what to do about this in a moment.

Naturally there are some drawbacks to this service. The first is disk space which is limited to 50GB. There is no way to expand it to a larger amount. If you run out, you'll need a new plan. However the actual code for your web application should be separated from binary and text data. That's where the Blob Storage services comes into play. Blob storage is analogous to AWS S3 which is quick cheap data storage that can be propagated with the CDN service. By separating code from data, you'll find it's pretty hard to write 50GB of code. This blog is presently violating that paradigm as I'm simply storing my media on the web instance itself. And since I'm storing my media with the web instance, I'll have media sync issues in the future if I ever decide to add multiple deployment slots.

The solution for the media issue is to install and configure a File System Provider so that the media lives in one spot and all the deployment slots point to one set of media. Using Blob Storage also removes the prospect of ever filling up the 50GB quota.

Good hosting costs money part 2

I lead this article with this phrase and I'll be upfront, Azure isn't the cheapest option out there. However if you can afford it, it'll change the landscape of your development workflow for the better. AWS is cheaper, but you'll have to deal with VM's, software updates, security fixes, etc. Azure does that automatically. If you want continuous integration with AWS, you'll need to use a third party solution (TeamCity, etc). Azure plucks your code from your repo natively. The cost between the two is not that far off, I'll leave exact figures for you to do your own estimates. Another thing with AWS is the confusing pricing structure when trying to size things. Azure is pretty much small, medium or large and you can move up/down easily. Azure also has horizontal scaling which Umbraco supports based on triggers for heavy load sites.

When you consider the time spent on DevOps functions with a traditional VM on AWS versus Azure Websites, I think they're on pretty even ground. This blog gets a fair amount of traffic (few hundreds requests per day) and I've sized at a Medium web instance and a basic SQL server instance.

Let's talk a little bit about the SQL part of Azure. They use a version number for the SQL DB and have obsoleted editions such as Web and Business. You will be charged based on the performance level of the DB. For this blog, the cheapest basic DB works just fine. In the early days of SQL hosted on Azure was the poor integration with SQL Server Management Studio (SSMS). In the last few months they have made it much much better but you'll need to be on SSMS 2014 (update 6+) or else risk getting really upset when you can't do near the things you can do with a local DB. I don't use SQL CE so I can't really comment on how that would work on Azure.

All of the services we talked about are listed on the Azure Portal. There is a new portal and an old portal, but they both work (at the moment) to perform all the things you will need to do.

Actual Costs

If you're looking to get into Azure, you'll likely need to budget for $100-150/mo USD for a medium size web instance and a basic DB plan. That includes moderate bandwidth and SSL costs. Azure charges extra per month for SNI SSL services which is in addition to the cost of the certificate initially. When I look at my monthly bill the most expensive charges per month are the DB and the web instance which shouldn't come as a surprise. On the sites that have Blob Storage and CDN's configured, they are very inexpensive. 

Microsoft offers the BizSpark program for startups that can get you $150/mo USD in free services for up to three years. I've had mixed results from Microsoft as they denied me the free credits but someone else I know got them. Also if you have a valid Visual Studio MSDN subscription, you'll likely get $150/mo in credits while your subscription remains active.

Umbraco as a Service (UaaS)

UaaS is a first party hosting solution offered by the Umbraco HQ. It is based on Azure but the implementation details are likely not publicly available. There is a waiting list you can get on and it is about 40% cheaper than what you would spend on rolling your own with Azure. I haven't gotten to sample UaaS yet to be able to give you the pros/cons versus just hosting on Azure yourself. It's likely we'll all learn more over the next few months.


To summarize, I think you should be hosting your Umbraco site in the cloud be it AWS, Azure or UaaS. I highly recommend using Azure if you can afford it. Be sure to take advantage of all the free service credits Microsoft gives away as there is no telling how long they'll offer them. As UaaS evolves, it may end up being the defacto hosting for most Umbraco sites just like Wordpress has done. Next up we'll wrap up some loose ends and close out this series.