Thursday, March 18, 2010

Installing Telerik’s Sitefinity CMS

So I’m only a day away from heading to the east coast’s first Give Camp, where I’ll be working with about 100 other volunteers to build websites for non-profit organizations in the Southern Maryland area. Shameless plug: If you’re a developer and you’re available this weekend, March 19-21, we still need more volunteers! Sign up at www.somdgc.org.

We’ll have only one little infinite weekend to accomplish this for 19 non-profits! So… then the question becomes, how are we gonna get this done???

The teams have several options, and it’s up to each team lead to decide on the most efficient technology for their team.  I heard at least one team is using SharePoint, and several are using DotNetNuke. The only restriction we have: it must be hostable at DiscountASP, who’s sponsoring free hosting for all completed sites.

Telerik is sponsoring Sitefinity CMS licenses, so I thought I’d install it and get familiar with it, as I haven’t used it before. I’m glad I took the time to work this out before the actual Give Camp, as it took me a bit of time to work through the issues. So I’ll summarize the easiest way to blast through the install and avoid the issues I ran into.

Step 1: Follow the directions

No, I’m not being sarcastic here. After I simply downloaded and ran the setup, and received several errors (including the inability to create the telerik virtual directory), I did a bit of googling on bing, and found the Sitefinity installation guide. While the guide calls out Vista, the steps work equally well in Windows 7. Seriously, follow this guide step-by-step, and you should be up and running.

Thanks to Jim Pendarvis, our Give Camp Fearless Leader, for pointing out this most-excellent webcast showing how to follow the directions. So now, with both the installation guide and the video, you’ll be all set.

Step 2: Follow the directions

Seriously, step 1 is what you need. But since I have a Step 2 now, let me call out a few things:

  • Several steps reference the app pool configuration (mainly Step 2). If you are running a 64-bit Windows installation, you will likely see an HTTP error 404.17 when trying to run the Sitefinity Project Manager. This is because the app pool must be configured to run 32-bit applications. Here are detailed instructions for doing this.
  • The installation guide talks about creating databases, in Step 8. This will save much pain and anguish. Once you have your site created, manually create the database and then specify that database in Sitefinity’s Site Creation Wizard.
  • When specifying your database, be sure to select the SQL Server 2005 / 2008 option, even if you’re using SQL Express. For the database path, you can then point to localhost\SQLExpress

Step 3: Start building your first Sitefinity CMS

Once I worked through the issues with the app pool and database, I was off and running. I built a very simple site just to get familiar with the product. It appears to be very straightforward and has several features that our non-profits are looking for (such as a discussion forum for members of their organization, a much-needed feature for the group I’m working with).

Friday, March 12, 2010

Azure: The true cost of web and worker roles

Since February 1, Azure customers are now being billed for their consumption of Azure resources. If you were an early adopter, you might have been spoiled by the free usage during CTP over the past year, or even during January of this year, when “mock bills” were generated but no actual costs accrued.
Recently I’ve been fielding questions about the true expense of running Azure web roles and worker roles, including questions about Microsoft’s “free” account for MSDN Premium developers. Let me share a few tidbits here that will, hopefully, help you manage your Azure costs.

Roles and Virtual Machines

First things first: web and worker roles are hosted in virtual machines (VMs). Each role deploys to its own VM. So, if you have a web role for your Silverlight application, and a worker role for some background tasks (like periodically fetching data from an external source and storing it in SQL Azure), you will actually consume two VMs, one for each role.

Virtual Machines and Instances

Ok, next up: instances. At the most basic level, you could view a VM as synonymous with an instance, and in the example above, you’d have two instances. Things take a twist, though, when you consider that Azure offers multiple VM sizes. The smallest size sets the baseline, and is equivalent to 1 instance:
Type Instance count Cost per hour
Small 1 0.12
Medium 2 0.24
Large 4 0.48
Extra Large 8 0.96
Each of the VMs vary by number of CPU cores, RAM and disk space. The price scales along with the instance count, so an Extra Large VM costs 8x what a Small VM costs.
Instances running ‘round-the-clock effectively cost 24 hours x 0.12 x 30 days = $86 monthly for a Small VM, up to about $690 monthly for an Extra large VM.
Microsoft bills in instance-hours. So you might be billed 48 instance-hours on a given 24-hour period, which either means you had two Small VM running for 24 hours or one Medium VM running for 24 hours.

Instances and Lifetimes

Now we’re getting to the fun part. Let’s say you just created a brand new Azure service, setting up a new name (like MyCoolApp.cloudapp.net). You just finished your first code iteration, and you publish your code to that new service of yours. Just two roles, both set up with one Small VM each.
You might notice that it takes a few minutes to deploy your code to that new service. Why? Because Azure is spinning up new VMs for you. Why is that important? Hold that thought a moment…
Ok, you’re done uploading and deploying, and finally, the Azure dashboard tells you your app is running. You are officially on the clock. You are now being billed for your two instances.
Now let’s get back to the point about your two new VMs. You might decide that, after your first set of tests, you’re going to suspend your new service. That is, leave everything uploaded (so you can show off your new app to the Boss later today). Guess what: You are still officially on the clock. The simple truth is, Azure is still hosting two VMs for you, each taking up a “slot” in the cloud fabric. So you’re still being billed for it, whether the web and worker roles are running or suspended.

Lifetimes and Clock time

Alright – if you’ve gotten this far, you’ve realized that your newly-deployed app, even in a suspended state, is going to burn through hours pretty quickly. And if you’re an MSDN Premium subscriber, with 750 free compute-hours monthly, you might have just done some quick math:
2 instances x 24 hours x 30 days = 1,440 hours !!!
Essentially, your MSDN account is good for one Small VM (equal to 1 instance) running ‘round the clock, as that 1 instance burns just under 750 compute-hours.
So you quickly scramble to delete your deployment from your service (don’t worry, your service definition, and fancy URL, stay in place; just your code and VMs get deleted). Lucky for you, your app was only live for about 10 minutes before you discovered this. So You can afford to deploy several times daily with little-to-no risk, as long as you delete the deployment after each test / demo cycle. Right?
Well, not quite right. When you deploy a VM, you are billed hourly. So even if the VM is up for 10 minutes, you are billed for a compute-hour. Since our example is using two instances, we’ve consumed 2 compute-hours in a very short time.

Clock time vs CPU time

This final per-instance tidbit might be obvious by now, but I’ll call it out anyway, just for good measure. Each VM, whether suspended or active, is costing you in compute-hours. And to take that one step further: Even VMs sitting around mostly idle still consume compute-hours at the same rate. Let’s go back and think about that worker role we have. Maybe it wakes up every 24 hours and fetches temperature data, and stores it in your local database. Maybe that service call takes, oh, 10 seconds to retrieve all needed data, and another few seconds to store it. Then it goes to sleep for 23.99 hours. You are still running at 0.12 cents per instance-hour.

Cost-based architecture

What to do today

So here we are, fully armed with the true cost of these web and worker roles. And here we are, with our elegant Azure application architecture, with a web role for our Silverlight app, a WCF web role for our service tier, and one worker role for each 3rd-party service we want to interact with (that way, we have a very modular system, with each role doing only what it needs to). You probably see where I’m going with this: While our web role is going to be super-busy (and we might need to scale it up to handle our web traffic), and our WCF web role might have to be scaled up as well, our worker roles will likely remain at 1 instance per 3rd-party service.
From a cost perspective, each of those worker roles, sitting almost-completely idle, is burning $86 monthly. Just three external services and you’re up to $250 per month.
Going back to the MSDN Premium accounts, you would require 5 instances running, in order to test your application. That means you’d burn through your 750 hours in about 6 days.
You will want to consider Azure’s pricing model when developing your architecture. The cost structure associated with instances and their lifetimes may mean making compromises such as rolling all of your 3rd-party integration code into a single worker role, and managing your polling intervals accordingly.

Future-thinking

The Azure team is reaching out to the community, asking for input about future ideas, where you can suggest a new idea or vote on someone else’s idea  (check out the voting site here). I want to draw your attention to a few ideas that could really help reduce cost:

What other great ideas would you add, to help create a more cost-effective model for your Azure rollout?