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.
SQL Azure Data Sync is
scheduled for final release soon. Formerly known as Project Huron, SQL
Azure Data Sync enables synchronization of data between SQL Azure
instances, or SQL Azure and on premises SQL Server databases.
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
The Development
Fabric is yet another part of Azure with "fabric" in its name. The
Development Fabric is a specialized Windows Azure environment used for
local development. It is akin to the Azure Fabric, but is hosted on a
single local machine. We install the Development Fabric with the Windows
Azure SDK and other tools.
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.
