The Nickel Tour of Azure : How are Azure costs calculated?

Windows Azure platform: AppFabric

AppFabric is another part of Azure with "fabric" in its name. AppFabric was originally known as BizTalk Services, and then later as .NET Services. Unlike the Azure Fabric or the Azure Fabric Agent, AppFabric is not a low-level controller/manager of the virtual machines. Instead, AppFabric provides the Service Bus, Access Control services, and connection components.

The Service Bus is the functionality that serves as a bridge between on-premises applications and Windows Azure. The Service Bus also facilitates bidirectional communication between two non-Azure applications.

Bridging local and Azure applications is useful in certain cases such as if there is information in our local warehouse management system (WMS) we want to make visible to our clients via an Azure-based portal we develop. If our WMS has an API we'd like to manifest directly to our partners, we can also use the Service Bus to abstract the WMS API. In this case, we'd register our WMS's endpoint with the Service Bus, which would then create a public set of its own endpoints. We'd provide the Azure endpoint URIs to our partners to be consumed by their applications. When a call is made against the public endpoints, Azure queues that client request and passes it to our WMS. Our WMS responds to Azure's request, and Azure sends the data on to our partner. The Azure Service Bus handles the discovery and registration of the endpoints, and handles the NAT as well. In terms of securing our WMS, no one needs to know our private IP address, and we limit our firewall to a smaller list of IPs to allow through.

In the Service Bus examples, we'd obviously need a way to limit access to the application or endpoints. This is one of many places where the Access Control functionality of AppFabric is important. Access Control issues security tokens that can be consumed by Azure and non-Azure applications via REST (SOAP has been announced but was not in place at the time of writing). Access Control is a claims-based identity service, similar to OpenID or Microsoft's LiveID.

AppFabric also incorporates projects codenamed Dublin and Velocity. Both Dublin and Velocity are standalone projects that can be used with both Azure and more traditional applications. At the time of writing, these projects were announced but not released, so more detailed information should be gathered directly from Microsoft. Project Dublin is an effort to enhance the management of .NET 4 WCF and WF services as well as IIS management and monitoring. Dublin utilizes PowerShell commandlets and IIS integration.

It is useful to note that AppFabric can be used separately from the other parts of Azure, and its components can be used individually from one another.

SQL Azure

Originally known as SQL Data Services, SQL Azure for many people is the most exciting item on the Microsoft Azure menu.

SQL Azure is an almost feature complete implementation of SQL Server 2008 Geographic data types are now supported. Unlike Table Storage, SQL Azure is completely relational, with a defined schema, supports T-SQL, and we can connect via ADO.NET or ODBC.

We can manage our SQL Azure databases through the SQL Azure Portal, directly via sqlcmd, or through SQL Server Management Studio 2008 R2. At the time of writing, SQL Server 2008 R2 is the most recent release of SQL Server, and is the only SQL Server Management Studio (SSMS) version that can completely connect to SQL Azure. Microsoft provides a SQL Azure Database Manager (formerly known as Project Houston), an online tool that is used to manage SQL Azure databases. There are also a couple of third-party tools, such as SQL Azure Manager and the Omega Web Client, for managing SQL Azure. Undoubtedly, more tools will arise as more people begin to work with SQL Azure. The SQL Azure Manager (though in Alpha testing at the time of writing) can be found at http://hanssens.org/post/SQL-Azure-Manager.aspx. The Omega Web Client (along with other great third-party tools for Azure) can be found at http://www.cerebrata.com.

Just as with SQL Server, we can have multiple databases per SQL Azure instance. Database sizes are limited, so if it's possible our application may exceed the maximum size, it's a good idea to either build in an archiving strategy and tools, or plan for a multiple SQL Azure account and multiple database solution at the beginning. Behind the scenes, and just like the storage options in Windows Azure, SQL Azure data is replicated three times to ensure availability and backup.

Codename Dallas

Project Dallas is Microsoft's entry into the new data-as-a-service (DaaS) market. The goal of Dallas is to provide a single authoritative source and a single billing method for public data. Think of Dallas as a "data marketplace", where we can buy subscriptions to data useful for our applications, and where data providers can sell their data.

The data in Dallas are accessible via a REST API, and can be consumed by applications on any platform. Support will be for SQL Server and SQL Azure to directly consume Dallas data, but this has not been delivered at the time of writing.

More information on Codename Dallas can be found at http://www.microsoft.com/windowsazure/dallas/.

Development Fabric

Considerations for the ASP.NET developer

It's easy to think developing a web role is just the same as developing a traditional website, but that's not the case. The web role is not just a website, but a complete ASP.NET web application. If we have multiple instances of our web role application running, the Azure load balancer doesn't guarantee a user's connections will all be made on the same VM. One consequence of this is that our application should either be stateless, or use the database (or table/blob) or cookies to maintain session state. In-process session state isn't an option.

Imagine a local web farm with a load balancer that does not maintain session state. The ideal solution in this case would be to use some type of session storage to maintain state across servers. This is also the case with Windows Azure web role instances. We cannot maintain state in-process if we bounce between machines; however, the state can be shared using our table/blob storage or our SQL Azure service. While we can attach our debugger to our local instance of the Development Fabric, we cannot debug applications remotely that have been deployed in Windows

Azure. We will need to maintain our logging and use it to debug issues, if present in the cloud. Because we are not guaranteed to browse our web application on the same server after every call, there is no persistence with local storage. Microsoft answers this issue quickly with table and blob storage. All data and files that need to be accessible need to be saved in a storage service or a SQL Azure database (the highly scalable option is using storage services).

How are Azure costs calculated?

Microsoft Azure has two methods for calculating the monthly service charges consumption pricing or commitment (subscription) pricing. Because Windows Azure, SQL Azure, and AppFabric are three independent services, each is priced separately and with its own rates. The charges may seem like nickel-and-diming as they are broken out by the different features of each service, but having the charges broken out allows us to utilize and pay for only what we use.

In addition to production-scale pricing plans, Microsoft also offers limited-use plans suitable for development and conference room pilot efforts. For the most current rates and offers, visit http://www.microsoft.com/windowsazure/pricing/. We're not going to list the base rates here, as they are likely to change over time. Instead, we'll look at how the charges are applied to each service in the next section.

Cloud services such as Amazon EC2 bill in a manner close to what Microsoft does, yet offer a little more flexibility with types of VMs (they offer both UNIX/Linux pricing and Windows pricing, which varies based on the type of hosting needed). They also offer commitment plans, but theirs is called "Reserve Instances". This is where a flat fee is paid up front, based on a time commitment, but a reduced usage fee is charged on a monthly basis.

Calculating Windows Azure pricing

Windows Azure charges are calculated based on utilization of four resources compute time, storage, storage transactions, and data transfers.

Compute time is billed as service hours or the amount of time an application is deployed. When calculating compute time charges, keep in mind each instance of an application runs in its own VM. If we have two instances of an application running simultaneously for an hour, that is calculated as two service hours of compute time.

Storage is billed as the daily average gigabytes consumed in the storage service (tables and blobs). To minimize costs, we want to minimize the size of resources we store for a long duration. If we have a 30 GB blob in storage for a month, our average daily consumption would be 30 GB. If we were to upload a 30 GB blob for a single day, our average consumption would be 1 GB.

Storage transactions are the CRUD operations we perform against tables and blobs. Every create, read, update, and delete operation we perform against our data is a transaction.

Data transfers are billed as the total number of gigabytes uploaded or downloaded via the Internet during a month. Any communication within sub-region (same data center) is not charged. This is helpful for HTTP calls between different services, and also emphasizes the correct usage of Affinity Groups to keep dependent services together.

The other transactions are application requests, and pass through the Queue Storage. At the time of writing, there was no specific charge for application requests.

Calculating SQL Azure pricing

SQL Azure is sold in two editions Web and Business plus data transfers. SQL Azure databases are billed monthly but calculated per diem, and we are only charged for the days we have the database.

Both editions are self managed and support Visual Studio, SQL Server Management Studio, and SQL Server Integration Services. The Web Edition has a capacity of up to 5 GB, while the Business Edition has a capacity of up to 50 GB and supports advanced features such as auto-partition and upcoming plans for common language runtime (CLR) integration.

As with Windows Azure, data transfers are calculated as the total number of gigabytes uploaded or downloaded via the Internet during a billing month.

Calculating AppFabric pricing

AppFabric charges are billed by Access Control transactions, Service Bus connections, and data transfer.

Each claim of identity made to the Access Control service is a transaction. Charges are calculated based on the actual number of transactions during a billing month.

Service Bus connections are sold as individual pay-as-you-go connections, or can be purchased in flat-rate packs. Individual connections are charged based on the maximum number of connections utilized during a day. Connection packs are calculated daily, based on the pro-rata number of connections. If we buy a 30-pack of connections at the beginning of a month and then buy another 30-pack one week in, we are charged for 7 connection days for the first week, and then 14 connection days thereafter.

As with Windows Azure, data transfers are calculated as the total number of gigabytes uploaded or downloaded via the Internet during a billing month.