A small development company thinking about using Azure

Question

I'm a small software company (me and one other), and we currently pay about £50 per month ($75 ) for our hosting. We have 2 VPS machines to cover our 12 websites.

Now, I'm looking towards Azure to see if it will suit our requirements. I have a few questions that I hope people could help me with:

1. The websites we have are not heavily used (100 visitors per day maximum) however we have 12 currently. With Azure, do you only pay when the website is used or when the machine is "ON"? It'll need to be on 24/7 like our current host
2. Would we create one deployment machine and put all 12 websites on there? If we need 12 different hosted services could it get expensive very quickly?
3. What would we do about sending / receiving email and scheduled tasks? There is a remote desktop session available, so presumably I could install Smarter Mail and our scheduled task applications on here?

I've had a test with the portal and publishing, and it seems pretty smart (other than no full text search for SQL Azure) but I'd really appreciate other people's experience.

Answer 1

1. You pay for the web role for every hour that it is running, even if no traffic hits the web role. In addition to the cost per hour for the web role, you pay for Table/Blob/Queue storage (if used), outgoing bandwidth (per-GB used, incoming is free), SQL Azure (if used), and various other Azure services you can sign up for. See Microsoft's pricing calculator.

2. If you want to run all 12 sites on a single web role, check out the Windows Azure Accelerator for Web Roles. It has a lot of nice features to help you do this.

   However, keep in mind that if you only have a single web role running these sites, you will have downtime, and it could be in the middle of the day. Microsoft is continually doing maintenance, taking roles down, destroying them, rebuilding them, and putting them back up to do updates, migrations, etc., and your role could be down for a while when undergoing maintenance - and you have no control over this process.

   To mitigate this Microsoft recommends having at least 2 web roles. In your situation, each of the 2 roles could run all 12 sites. However, for this to work well, all of the sites have to be built so that there is no affinity to any particular server. That is, if a user logs in and they hit Server A and server A puts something about the user in cache, then the user's next request goes to Server B, Server B won't have the bit of data in it's cache and so the second request might fail. You want to avoid this - make sure that your sites are written so that they work properly when behind a load balancer.

3. Yikes, I would be careful here. I would highly recommend against logging in via RDP and installing an app on a web role. If you do this, the next time the role gets recycled and rebuilt (which will happen with Microsoft's regular maintenance), any custom installations you did like this will be wiped out.

   There are two parts to this. The first is getting some kind of emailing software installed. You can install the email software via command line during the role initialization in a Startup Task. See here and here. This will cause the software to reinstall every time your web role is rebuilt by Microsoft. Alternately, you could connect to third party emailing services via API, such as MailChimp, and not worry about handling the email yourself. Keep in mind that if you are sending emails out yourself, you could run into trouble with SPF because your IP address in Azure could change from time to time.

   The second part to question 3 is related to scheduled tasks. There are a couple of approaches:

   • Use a worker role (or have the web role also run as a worker role), which is effectively an infinite loop that does something over and over. You could have it check an Azure queue for work, etc., or check a folder for files, and when it finds one, it processes it somehow. This assumes that you want some type of work to be done immediately once it's ready. If you're looking to send emails, you could do something like this:

     a. Your web app decides an email needs to be sent. It stores the email related data in an Azure Table, and creates an ID for the email.

     b. Your web app then takes the ID for the email and adds it to an Azure queue, indicating that an email needs to be sent.

     c. Your web app forgets about the email and gives a response to the user

     d. A worker role (potentially running on the same box as the web role) picks up the message out of the queue, sees that an email needs to be sent, grabs the data from the Azure table, and sends the email.

     e. The worker role then cleans up the data from the queue and table

   • You can use scheduled tasks. A web role, after all, is a full fledged windows server, and does have scheduled tasks. However, as with the software install, you'll need to be sure to set up your scheduled tasks via a startup task so that they are in place even after a role has been recycled.

Overall, you have to think a little differently when working with Azure web roles. Microsoft is forcing you to go down a path that makes your application more scalable and reliable. By wiping out the web role and rebuilding it during maintenance, they are forcing you to automate the installation of software/apps on your web role in a script. This allows for better scalability, as all you have to do when you need 100 more instances of your web roles is change a setting and wait. It provides for better reliability because it means that your web roles are set up the exact same way every time.

It can be a bit of a pain at first to transition to the Azure way of doing things, but it can have some good benefits in the end.

Answer 2

1. You pay CPU time, i.e. when the machine is running
2. You can deploy multiple websites on one web role
3. Scheduled tasks would probably require an additional worker role, i.e. additional cost