As I tour around Canada doing talks on Windows Azure at conferences and user groups, I found that the biggest concern around the cloud computing paradigm shift is cost. Slightly confused as to how a key offering of a platform is a sticking point against its adoption, I asked for some feedback. Here are some findings:
- If I invest in developing against a particular platform, how simple is it to migrate to a different platform?
- If the project that is deployed to the cloud doesn’t require the grade of redundancy and scalability in the cloud, is it possible to host the project in house in order to save money?
- How is cost accumulated for billing?
There are a few things that I’ve taken away from some of the feedback that I’ve gathered at the talks that I’ve done thus far. There is definitely a lack in understanding of the billing model of Windows Azure, but there is also a misunderstanding of the advanced infrastructure that Microsoft has unveiled. In this post, I plan to clarify some of the misunderstandings about the Windows Azure Platform.
Will I get a Migration Migraine?
To speak towards the first point, there are always many things to consider when choosing one platform over another. Each platform will normally have different offerings to attract a market from their competition. It’s ultimately up to the Developer or Systems Architect to make the decision to leverage those offerings, which could potentially “lock” an application into a particular platform.
If you are worried about your application being “locked” into the Windows Azure platform, you can opt out of the choice to use the Storage Services and leverage a [potentially larger] database instead. It’s the cost that will ultimately steer you in one direction or another on platform, and further more the features of said platform. On the plus side, leveraging Storage Services over a database while using Windows Azure gives you the ability to limit the cost of your application, while increasing the response speed of data transactions (Storage Services can be partitioned and scaled across multiple nodes, and also have a ).
If you feel the need to pull your application off of the Azure Platform, you can export the data in the Storage Service into a CSV, or Excel formatted file using the Azure Storage Explorer. The only extra cost of migration would be writing a script in order to migrate the data into your next storage solution, which is slightly more work then if you were migrate directly from one database to another, assuming there is a clear migration path between the two.
Windows Azure Billing Overview
Considering that the billing model for Windows Azure is a little complex, I though I’d take some time to break it down into sections, and outline some common misconceptions in each section, so it can be better understood. When deploying to Windows Azure you will be billed for the following categories: Compute Time, Storage Services, SQL Azure, AppFabric, Data Transfers.
The Core Costs
The Chart Above taken from my presentation “Taking it to the Cloud with Windows Azure” is an outline of how the charges are broken down. The Core Costs [cost that are billed each month for the service] of Windows Azure are Compute time, Storage Services, and Data Transfer.
Compute Time is billed out depending on the Instance Size you are running your application on. This cost is accumulated in real-time hours as long as you have resources allocated to a particular instance, I will review this in more detail below.
Storage Services aren’t necessarily required, however you are able to store Diagnostic information in table storage to keep track of errors and restarts of your applications in the cloud. Storage Services are also handy when you are using Worker Roles [behaves much like a Windows Service] to process long running/scheduled tasks, or tasks that require heavy lifting.
Data Transfer is metered by the amount of data that is travelling in or out of the data center. This is where you can benefit by optimizing your web application by using the ASP.NET MVC Framework to help minimize the size of your pages leaving the data center.
Situational Costs
That covers the “Core Costs” of Windows Azure, which leaves the additional three items at the bottom of the chart SQL Azure, App Fabric and Simultaneous Staging Environments.
SQL Azure is a full scale RDBMS running in the cloud, it is built on SQL Server 2008, and carries a few minor limitations over a regular SQL Server installation. SQL Azure isn’t a Core Cost as you can leverage Storage Services to create a Non-Relational Entity based Storage System and manage any needed relationships in Code. However, a lot of applications do require a more robust system, which will require a Relational Database.
Windows Azure AppFabric [not to be confused with Windows Server AppFabric] offers both Access Control Services for Cloud based Security as well as a Service Bus in which you could expose an on premise Database to the Cloud. Both could be leveraged in unique scenarios, but not necessary for all applications as .NET Roles and Membership Providers can still be leveraged in the cloud.
Simultaneous Staging Environments are costs that will occur from time to time when you are in the staging phase of a deployment. This occurs when you have both the Production and Staging Environments of your Hosted Service in use at the same time. I will explain this more in detail below.
Calculating Costs on Azure Compute Hours: Compute Sizes
The first thing you have to understand when calculating Windows Azure compute costs is that compute instances come in four (4) unique sizes to enable complex applications and workloads. These virtual compute instances are virtual machines running within one of currently six (6) data centre containers:
|
Compute Instance Size
|
CPU
|
Memory
|
Instance Storage
|
I/O Performance
|
|
Small
|
1.6 GHz
|
1.75 GB
|
225 GB
|
Moderate
|
|
Medium
|
2 x 1.6 GHz
|
3.5 GB
|
490 GB
|
High
|
|
Large
|
4 x 1.6 GHz
|
7 GB
|
1,000 GB
|
High
|
|
Extra Large
|
8 x 1.6 GHz
|
14 GB
|
2,040 GB
|
High
|
This is important to remember as the compute costs are directly related to the size of instance you choose. (Note: The default instance size is currently SMALL, if you wish to modify this it can be found in the Properties screen of your Web Role.)
Compute cost per size is as follows (note: prices are subject to change):
- $0.12 / hour for the SMALL instance
- $0.24 / hour for the MEDIUM instance
- $0.48 / hour for the LARGE instance
- $0.96 / hour for the EXTRA LARGE instance
When you check your bill, all instance hours are converted to SMALL instance hours and is billed at $0.12 / hour. If you have two (2) MEDIUM Instances running, you will be billed for four (4) SMALL instances. It is important to note that instance hours are accumulated by each hosted service that contains a deployed project, regardless if the service is running or suspended.
Deployment and Staging Environment
One of the nice features of Windows Azure is it gives you a staging environment in which you can test your application in parallel to your Production Deployment before promoting the new code into production.
In this screenshot (below), you can see the production and staging environments. The Production Environment has an active deployment, you can identify when charges are accumulating by the cube under each of the environments. If the Cube is Blue the Instance is Accruing Charges, likewise when the cube is Grey the Instance is inactive and no longer accruing charges. If both your Production and Staging environments have a Deployment [Cubes are Blue] Both Instances are Subject to Billing.
Note: In order to deactivate a deployment you must Suspend the application and Delete the Deployed Cloud Service Package.
Calculating Azure Storage Space
Windows Azure Storage is calculated in two ways: (1) storage space measured in GB hours and (2) storage is billed by storage transactions. Now, I know what you’re thinking: "What exactly is a 'GB hour'?" Assume there is 750 billable hours in a month. This means you can store 750GB of data for a billing period and you will get charged for 750GB. However, you could alternatively store 750GB for one (1) hour. As a result, your account would accrue 1 GB in storage charges since storage is billed at the following rates:
- $0.15 / GB Stored / Month
- $0.01 / 10K Storage Transaction
(Please note that billing fees are subject to change.)
The newly release Windows Azure Drive (XDrive) which is currently in beta will also be subject to this same pricing model, as the XDrive is a Page Blob which is mounted into Blob Storage and can be configured for capacities between 16MB – 1TB in size (up to 16 drives per VM).
Calculating Azure Data Transaction Costs
The last of the standard costs for Windows Azure is data transfer. Data transfer is the equivalent of bandwidth allocation in the traditional hosting model. These costs are calculated over the course of a month and billed out in terms of GB of data transferred, there is a separate rate for data being transferred in and out of Windows Azure.
North American & Europe Data Rates
- $0.15 / GB Outgoing Data Transfer
- $0.10 / GB Incoming Data Transfer
Asia Pacific Data Rates
- $0.45 / GB Outgoing Data Transfer
- $0.30 / GB Incoming Data Transfer
How to Forecast SQL Azure Charges
SQL Azure is another form of storage which is subject to both data storage and data transfer charges. SQL Azure databases are interesting as you can have as many databases as you need to consume your applications data. Charges are accumulated based on actual data usage per database.
From the pricing page for Windows Azure, the consumption rates for SQL Azure are as follows:
- Web Edition:
- Up to 1 GB relational database = $9.99 / month
- Up to 5 GB relational database = $49.95 / month**
- Business Edition:
- Up to 10 GB relational database = $99.99 / month
- Up to 20 GB relational database = $199.98 / month**
- Up to 30 GB relational database = $299.97 / month**
- Up to 40 GB relational database = $399.96 / month**
- Up to 50 GB relational database = $499.95 / month**
- Data transfers = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)*
* No charge for inbound data transfers during off-peak times through October 31, 2010
** SQL Azure 50 GB Business Edition Database and 5 GB Web Edition Database will be available starting on June 28, 2010.
Understanding AppFabric Billing
As you may or may not be aware, AppFabric is a place in which you can expose a endpoint as a pipeline from the cloud to a non-cloud based system. This makes it a relatively unique platform to meter for billing. Microsoft has decided to make a "pay-as-you-go" model, as well as a number of packages to make a more customized experience for your particular business requirement.
Bundled in with AppFabric is Access Control which is a flexible and configurable security model for Windows Azure. Access Control is billed out based on a transactional basis.
- Access Control: $1.99 per 100k transactions
- Service Bus: $3.99 per connection on a "pay-as-you-go" basis, or:
- Pack of 5 connections $9.95
- Pack of 25 connections $49.75
- Pack of 100 connections $199.00
- Pack of 500 connections $995.00
Bringing it all together
Hopefully, you now have a better understanding of Windows Azure billing. I’ve covered all of the current items that would be billable in Windows Azure. There are however a couple of pricing models that are available as part of Introductory offers Microsoft has put forth to get people to try Windows Azure. If you are thinking of moving to this platform and would like to calculate some estimates of what your applications may cost to run in the cloud consult the TCO and ROI Calculator. To find out more information, check out the following resources:
On Thursday May 13th, I travelled to the North York Community Centre to give a presentation at the Toronto Visual Basic User Group on Windows Azure. I’d like to thank the group for having me out, with a Special Thank you to the User Group leader Rob Windsor who was celebrating his Birthday that very night.
With a crowd of approximately 10 people this may have well been one of the smallest groups that I had giving my Windows Azure presentation to, but definitely by far the most interested in the cloud. The majority of the audience had questions, and may offered up more than one question, which is typically rare for a User Group.
There was one Question that I wasn’t able to answer at the event which I hope to clarify here.
The Question was brought on by the statement that a Windows Azure Queue Message was capable of storing up to 8KB. I’m glad to see questions like this arise as it lets you know that the audience is listening, here’s the question, “What is the maximum size that can be stored within a column of the Table Storage Service.”
After a little bit of research here is the official word from the MSDN Windows Azure Documentation Library.
An entity may have up to 255 properties, including the 3 system properties described in the following section. Therefore, the user may include up to 252 custom properties, in addition to the 3 system properties. The combined size of all data in an entity's properties may not exceed 1 MB.
I have posted the slides on SlideShare, the slides themselves aren’t terribly informative the true value of the slides is in the Speakers notes which unfortunately don’t get posted. If you’d like to get a copy of the slide deck, please drop me a line.
The code that I presented is an open source project which is available on CodePlex. The Azure Email Queuer is meant to be a Starter Project for an Internet Email Marketing Tool. The current hosted source is a little bit out of date, but I will be working towards Updating it shortly. You can download the Visual Basic version of the Azure Email Queuer from my website.
Monday, 22 February 2010 16:57 by
SyntaxC4While there are many different ways to get your database up and running into the cloud. You could read up on SQL Azure Sync Framework in my post titled “Synchronizing a Local Database with the Cloud using SQL Azure Sync Framework”.
However, nothing feels more comfortable to a developer than something that familiar. After a little bit of investigating while preparing for my talk at Confoo on SQL Azure, I managed to find a post on the MSDN website that Explains what is needed in order to use the Generate Scripts Wizard in SQL Server Management Studio.
Create the Transact-SQL Script
-
In Object Explorer, right-click the database, point to Tasks, and select Generate Scripts.
-
In the Script Wizard dialog box, click Next to get to the Select Database step. Select School, select Script all objects in the selected database, and then click Next.
-
In Choose Script Options, set the following options:
- Convert UDDTs to Base Types = True
- Script Extended Properties = False
- Script Logins = False
- Script USE DATABASE = False
- Script Data = True
SQL Azure does not support user-defined data types, extended properties, Windows authentication, or the USE statement.
-
Click Next, click Next, and then click Finish. The Script Wizard generates the script. Click Close when the script is completed.
-
In the generated script, delete all instances of "SET ANSI_NULLS ON".
-
Each CREATE TABLE statement includes a "WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]" clause. Delete all instances of that clause.
-
Each CREATE TABLE statement includes the "ON [PRIMARY]" clause. Delete all instances of that clause.
The reason you need to apply these changes to the script is that SQL Azure currently doesn’t support all the features of the currently release of SQL Server 2008. There are plans to start to incorporate some of the features that are in this outline, including the USE statement.
Hopefully this will make your life easier on your move to the cloud. Until then, Happy Coding!
Sunday, 20 December 2009 19:42 by
SyntaxC4If you are setting up your Development Environment for Windows Azure and want to avoid installing SQL Server Express. I didn’t want to use SQL Server Express because I’ve already installed SQL Server 2008 R2 CTP so I can interact with my SQL Azure Database in the Cloud.
From the command line, Navigate to the Windows Azure SDK directory.
cd "C:\Program Files\Windows Azure SDK\v1.0\bin\devstore"
Then you will Launch the Development Storage Initialization Tool [DSInit.exe]. You will need to set the SqlInstance [/sqlinstance:] that you wish to create the tables on, and you will need to force [/forceCreate] the tool to create the tables.
DSInit.exe /sqlinstance:<YourDatabaseName>/forceCreate
This will launch the Initialization Tool.
If you receive the error message below you it is most likely because the instance name was improperly set. Ensure to be use only the InstanceName do not include periods or slashes.
After your Development Storage is set up make sure you go into your Development Fabric and Start the Development Storage Service.
Happy Coding!
Monday, 14 December 2009 13:30 by
SyntaxC4
In order to test out the Windows Azure platform to it’s full extent I am looking for a few developers that program in the open source realm to develop a few simple web applications in Java, Python, or Ruby to be hosted on Windows Azure. These applications don’t need to be anything too extravagant, however, I would prefer if the application was to use the Windows Azure Storage API.
You can download the respective storage APIs here: Java, Python, Ruby, and PHP.
If you are an Open Source Developer and would like to try out the Windows Azure Platform contact me for a Windows Azure Token. Once you have deployed your application into the cloud, I will create a blog account for you on the Canadian Azure Experience Cloud Blog [that I installed using Azure BlogEngine.Net] for you to post your experience with Windows Azure.
All this sounds great, but what’s in it for you? I am not a Microsoft Employee, so I won’t be able to offer up much, but this is a great starting point for the Elance Windows Azure Contest. Plus I will offer up a post about you and your application on my blog for all the world to see [Hey, You found this didn’t you?].
Here are a few resources to get you going with Windows Azure: