Friday, 4 November 2011

Windows Azure Pricing

Pay as you go: http://www.microsoft.com/windowsazure/offers/MS-AZR-0003P

What qualifies as a transaction in Windows Azure Storage (you pay per transaction): http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/09/understanding-windows-azure-storage-billing-bandwidth-transactions-and-capacity.aspx

MSDN Benefits for Windows Azure: http://www.microsoft.com/windowsazure/msdn-benefits/


Thursday, 3 November 2011

Windows Azure and operational cost reduction

One of the things that strikes me the most about using Windows Azure (or most cloud solutions) is the savings you can make with your test environments.

In Windows Azure world, your on-going cost is for your Compute instances (what you deploy your applications to) and your storage. Whether you are using the application or not, you are paying money for your Compute instances and storage to exist. Other costs (Access Control, CDN etc) you pay per use or transaction.

So if you have a system test or user acceptance test environment that you are not using, you can simply delete the Compute instances and any storage artefacts. Then you don’t pay for them.

Contrast this will your on premise applications. You probably have multiple test environments for different projects and those are sitting there, costing you money whether you use them or not.

Some people suggest that Windows Azure (and some other cloud services are not that cheap). I disagree. Let’s say I need a system test environment for 5 days a month. A “Large” Compute instance (4 x 1.6GHz, 7GB RAM, 1000GB storage) costs $0.48/hour. Well 5 days at 8 hours a day (most people don’t work 24/7) costs me $19.20 (this includes the operating system license). I can script the creation of my compute instances and other artefacts very simply, so automatically spinning up or shutting down assets on demand.

So, a pretty meaty server for a system test environment on Windows Azure costs me $19.20 for the 5 days per month I want to use it.

How much is your on premise hardware costing to run for a whole month?


Tuesday, 1 November 2011

PowerShell, MSBuild and 64-bit platforms

If you call PowerShell from MSBuild on a 64-bit platform, you will often get unexpected errors. One such error is as follows:

No snap-ins have been registered for windows powershell version 2

The probable cause is that the MSBuild executable you are running is not 64-bit. On 64-bit platforms you should execute MSBuild from the following location:

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe

Depending on how/what you have installed, your Start Menu shortcuts might be pointing to the 32-bit version.


About Me