We have a project that we are considering to move over to Azure. However, the move to the cloud can be a bit daunting if you’re not fully expecting certain things. Cost is really one of the big factors driving our decisions. I sat down and chatted with my friend David Makogon, and discussed some of the best Azure scenario's for our deployment. A lot of good information came out of that conversation, and I feel it might be a lot of good information to share if you have a similar situation.
Our scenario: Our application is build on ASP.NET WebForms, and is running on shared hosting. It’s connected to a shared SQL Server instance through the same host. The host (who shall remain nameless) is a piece of crap. Random downtime, poor support, and an overall bad experience. We were looking at two different options: a dedicated server or the cloud.
Everything I’m talking about is my understand as of the date of this post (June 1st, 2010). I cannot guarantee the accuracy of the information after this post. If it changes, I will do my best to update.
When looking at Azure, you’re really looking at “roles". A roles were are interested in are the following:
Web Role A web role is a web site or web service running on Azure.
Worker Role A worker role is a process that runs in the background to perform tasks. Think of it as a “windows service” on the web.
SQL Azure It’s like a hosted SQL Server instance.
Pricing is based on per role per hour (web or worker). For example, if I run a web role 24 hours, it would cost me about $2.88. These are called compute hours. The problem with the naming is that even though you might not be “computing” anything, you’re still be charged for the role being deployed. Imagine a single site, running 24 hours a day for 30 days. This will cost you about $86 a month. That’s your baseline cost for hosting.
Now, people are going to actually use your site. This requires bandwidth. Bandwidth is cheap. You’re looking at $0.10 per GB for data coming IN, and $0.15 per GB for data coming out. And yes, that translates to 10 cents and 15 cents respectively.
Bandwidth is also required when you’re talking between roles. Imagine you have a web role running in a datacenter in Redmond, and a worker role on a datacenter in China. Ok, I really don’t know where all the datacenters are, but play with me here! If the web role needs to talk to the worker role, that requires bandwidth (and is priced at the rate above).
However, if all your roles are hosted in the same datacenter, you don’t have to pay for bandwidth charges. This is called “affinity”. If roles are in the same datacenter, they have the same affinity. Different datacenters, different affinities. Something to keep in mind when planning scaling.
When we talk about data storage in Azure, there are two possibilities.
First, there is table storage. Forget everything you know about relational databases, because you’re not going to get any of that here. Data goes in, and a data comes out. You’re responsible for managing the data. However, it’s really cheap. You’ll only be looking at $0.15 per GB for table storage.
Second, there is SQL Azure. You can take your trusted SQL Server databases and deploy them to the cloud. Then they’re used the exact same way as regular SQL Server instances would be used. For a single 1 GB SQL Azure instance, you’re looking at paying $10 per month.
I’ve written several ASP.NET applications, and I’m a fan of session state. I’m sure many other ASP.NET developers out there will agree with me. However, Azure does not have anything in place for managing session state. Azure is really a “stateless” system. There are 3rd party examples out there of how to do this, but right now there is nothing official.
There is a built in membership and roles provider, so don’t worry about that!
Note About Worker Roles
At first, I was considering the thought of not having to run a worker role. I’m developing a web application, why would I need one? However, there are a few good reasons why you might want to think about baking in the cost of a worker role.
First, Azure provides a lot of data on the roles and how they’re performing. Worker roles can collect and analyze this information on the fly. Ever have a web application crash? Worker roles can collect crash information, and send a nice email or log it for future reference. All this is done independent of the web role.
Second, worker roles can help you programmically scale other roles. Imagine a site that normally sees less than 1000 hits a day. Somebody posts a link to the site on Digg or Reddit, and the internet goes crazy trying to access this website. Normal shared hosting or even dedicated hosting would buckle under the weight of all the requests. In Azure, your worker role can watch the site and start new instances as they are required. The removes the strain off of a single process, and balances it between several. After the internet goes to sleep, the worker role and kill unneeded web roles. You do have to pay for the roles that it starts up, but hopefully it wouldn’t be for that long.
Azure is a great solution, and I’m looking forward to using it on future projects. The upstart costs of Azure hosting can be scary, but you need to think about it long term. Imagine the costs of having to buy and house several servers for a farm. Imagine having to pay for a dedicated pipe for all the servers to connect to the internet through. Imagine costs of system administrators. Then imagine how much less running multiple roles on Azure would cost. The cost of Azure will grow as your site grows. But the goal is that as the site grows, so will your pockets.
I’m really hoping that I didn’t provide any misleading information in this post. If you were considering Azure at all, either for a new project or an existing one, hopefully you now have more information than you did before.