Last week, Microsoft announced the availability of preview bits for Azure Stack, an offering which allows customers to run Azure Services such as storage, PaaS Services and DBaaS within their own data centers or hosted facilities.

How is Azure Stack different from its predecessors like the Windows Azure Platform Appliance (WAPA) and Azure Pack (WAP), and why does Microsoft think it has a better chance of success? The answers to these questions hold special significance given that the narrative on private cloud has turned decidedly negative in the last 2-3 years.

Past attempts at Azure-in-a-box

To get a better understanding of Azure Pack’s unique features, let’s first take a quick background look at its predecessors, WAPA and Azure Pack.

WAPA was marketed as a combination of hardware (~1000 servers) and software (Azure services). The idea was that customers could drop this appliance within their own datacenter and benefit from greater geographical proximity to their existing infrastructure, physical control, regulatory compliance and data sovereignty. However, the timing of the release was less than ideal – WAPA was announced in 2012 during Azure’s early days when there was no real IaaS story. Additionally, the lack of a standard control plane across the various Azure services and the pace of change made operating the appliance unviable. The size (and cost) of this appliance meant that it initially appealed to a very narrow segment of customers, as only industry giants (eBay, Dell, HP) could reasonably afford to implement it.

WAP took a slightly different approach. Rather than trying to run Azure bits on-premises, it used a UI experience similar to that of Azure Portal (classic) to manage on-premises resources. Internally, the Azure Pack Portal depended on System Center 2012 R2 VMM and SPF for servicing requests. However, the notion of first-class software-defined storage or software-defined networking did not yet exist. Finally, WAP only made available one PaaS offering, the Azure Pack WebSites – a technology that made it possible to host high-density, web sites on-premises. The fact that other Azure PaaS offerings were not part of WAP was also a bit limiting.

How is Azure Stack different?

Azure Stack’s primary difference lies in the approach it takes toward bridging the gap between on-premises and the cloud. Azure Stack takes a snapshot of the Azure codebase and makes it available within on-premises data centers (Jeffery Snover expects biannual releases of Azure Stack). Given that Azure Stack is the very same code, customers can expect feature parity and management consistency. For example, users can continue to rely on ARM whether they are managing Azure or Azure Stack resources (in fact, Azure Stack quick start templates are now available as well in addition to the Azure quick start templates).

The following logical diagram depicts how the control plane (ARM) and constructs such as vNets, VM Extensions and storage accounts (depicted below the ARM) remain consistent across Azure and Azure Stack. This consistency comes from the notion of Resource Providers. The Resource Providers in turn are based on Azure-inspired technologies that are now built into Windows Server 2016, such as S2D (Storage Spaces Direct) and Network Controller.


What about Windows Service Bus? Windows Service Bus is a set of installable components that provide Azure Service Bus like capability on Windows servers and workstations. So in some sense it is similar to the Azure Stack concept. However, it should be noted that Windows Service Bus is based on same foundation as the Azure Service Bus (not a snapshot of Azure Service Code) and does not come with full UI and control plain experience that Azure offers.

Azure Stack Architecture

The following diagram depicts the Azure Stack logical components installed across a collection of VMs.

ADVM hosts services like AD, DNS, DHCP.

ACSVM hosts Azure Consistent Storage Services (Blob, Table and Administration services).

NCSVM hosts the network controller component that is a key part of software-defined-networking.

xRPM hosts the core resource providers, including networking storage and compute. These providers leverage Azure Service Fabric technology for resilience and scale-out.

This article provides a more detailed look at these building blocks.


The hybrid cloud is closer to the “plateau of productivity”

While the narrative on private clouds has turned decidedly negative, the demand for hybrid cloud continues to grow. This rise in demand is mainly due to the fact that public cloud adoption is set to spike in 2016 (just look at the strong growth numbers for public cloud providers across the board). This spike in usage is squarely based on enterprise IT’s growing interest in the public cloud. And as enterprise IT begins to adopt the public cloud, hybrid cloud is going to be at the center of this adoption. Why? Because despite all the virtues of the public cloud, legacy systems are going to be around for the foreseeable future – and this is not just due to security and compliance concerns: the enormity and pitfalls of legacy migration are well known.

So after languishing in the hype curve for years, hybrid IT may be finally reaching the proverbial Gartner plateau of productivity.

Azure Stack “hybrid” scenarios

Here are some example “hybrid” scenarios enabled by Azure Stack:

1) Dev/ Test in public cloud and Prod On-Premises – This model would enable developers to move quickly through proving out new patterns and applications, but would still allow them to deploy the production bits in a controlled on-premises setting.

2) Dev / Test in Azure Stack and Prod in Azure – This is the converse of scenario #1 above. The motivation for this scenario is that team development in the cloud is still evolving. Some challenges include: managing the costs of dev workstations in the cloud, collaborating across subscriptions (MSDN), and mapping all aspects of on-premises CI/CD infrastructure with services like VSO. This is why it may make sense for some organizations to continue to development on Azure Stack on-premises and deploy the production bits to Azure. Of course, as with scenario #1 above, this second scenario will require dealing with the lag in features and services between Azure and Azure Stack.

3) Manage on-premises resources more efficiently – Having access to modern portal experience (Azure Portal), automation plain (ARM), access cloud native services (Azure Consistent Services), as a layer over the existing on-premises infrastructure brings enterprises closer to the vision of FAST IT.

4) Seamlessly handle burst-out scenarios – Technologies like stretching on-premises database to Azure are beginning to appear. Azure Stack and its support for DBaaS make these hybrid setups even more seamless.

5) Comply with data sovereignty requirements – A regional subsidiary of a multi-national corporation may not have access to a local Azure DC. In such a situation, Azure Stack can help meet the data sovereignty requirements and at the same maintain overall consistency.

Promising offering. But don’t expect a silver bullet solution.

Azure Stack is fundamentally a different approach to hybrid IT. The fact that it is a snapshot of the Azure codebase will ensure consistency between on-premises and cloud. A common control plane and API surface is an additional plus.

However, the lag in features between the two environments will need to be carefully considered (as is the case today with differences in availability of services across various regions)

Even though customers are getting the same codebase, what they are *not* getting is seamless scalability and all the operational knowhow to run a complex underlying infrastructure. There is no getting around the deliberate capacity planning and operational excellence needed to efficiently run Azure Stack in your data center.

Finally, as organizations are increasingly realizing, adopting any form of cloud (public, private or hybrid) requires a cultural and mindset shift. No technology alone is going to make that transition successful.

With its unique approach to hybrid cloud, Azure Stack certainly looks to be a promising offering which will provide developers and IT Pros alike, an Azure consistent environment on-premises something was previously unavailable.

After countless hours throughout the course of this past year, this training course has finally gone live. Putting together a training course is like writing a book, each sentence undergoes multiple revisions, and even after publication it is hard to let go of the project.

Course Summary
The public cloud is tomorrow’s IT backbone. As cloud vendors introduce new capabilities, the application-building process is undergoing a profound transformation. The cloud is based on key tenets such as commodity hardware, usage-based billing, scale-out, and automation, all on a global scale. But how does the cloud impact what we do as programmers every day? What do we need to do at a program level that aligns us with the aforementioned tenets? This course is organized into three modules which discuss a total of nine techniques designed to help developers make more effective use of the cloud.

A brief summary of the course is as follows.

Course Outline
Module #1 Getting Started

This module will outline key principles that make up cloud computing and introduces the discussion on cloud oriented programming.

Module # 2 Exception handling and instrumentation
Exponential Backoff
Be very careful about “tight loops” in your logic. The consequences may be more than just an unresponsive UI. You are likely to run up a hefty cloud usage bill. So whether you are checking for a message in the queue or reading a table, it is essential to build in logic that multiplicatively decreases (aka exponentially) the rate on invocation.

Reimagine the Exception Handler
It has been a best practice to only handle exceptions from which our program can recover. For all other exceptions, the guidance is to “rethrow” the exception up the call stack. But with the cloud (and DevOps), we now have the ability to provision new resources, or alternatively redirect the request to another data center in a different geographical location.

Logging Takes a New Meaning
We know the importance of logging in a complex distributed application. In the cloud, it becomes critical to have rich logging. But don’t create a hotspot by logging into a single repository. Instead, use diagnostics frameworks that allow you to log locally but transfer the logs to a centralized repository asynchronously.

Module # 3 Container, Microservices and Reuse
Think Containers
Try to encapsulate as much as logic as possible into a “container” that corresponds to the unit of scale and availability on the cloud platform – whether it is a Windows VM instance or a Linux group. Doing so will allow the platform to scale and be more resilient.

Decomposition is a well understood software design principle. The idea of breaking a business problem down into smaller parts that promotes not only “separation of concerns” but also the notion of reuse is indeed very worthy. Microservices are being seen as a way to decompose your cloud based applications.

Reuse is often cited as the Holy Grail of software development. In the cloud it takes on a whole new meaning. Easy access to prebuilt ML algorithms and cloud marketplace offerings increasingly available on the cloud platforms and are very easy to use.

Module # 4 Cost, Scale and Automation
Cost Aware Computing
Architects, PMs and IT folks are not the only ones that need to worry about the overall total cost of ownership (TCO). Programmers have an important role to play to keep the costs down – whether it is adequate “poison message” handling, exponential back off or tight memory management can all go a long way in keeping the TCO low.

Partitioning is the key to scalability
“Sharding” is not just for databases. In the cloud, consider the use of horizontal partitioning logic for something as low-level as a singleton (i.e. if possible, use a partitioned set vs. a singleton set). The best way to scale in the cloud is to embrace “scale-out” at the lowest levels of your code.

Infrastructure as Code
A new category of programs that developers are likely to write, when working in the cloud, is automating the provisioning of infrastructure that is needed to host the applications they build.
The cloud has ushered an era of “software defined everything” – network, storage, compute etc. Consequently, every aspect of a modern data center API is accessible, thus bridging the chasm between developer and operations that is commonly referred to as DevOps.

Think #Microservices

April 12, 2015


Decomposition is a well-understood software design principle. The idea of breaking a business problem down into smaller parts that promote not only "separation of concerns" but also the notion of reuse is indeed very worthy.

In his highly acclaimed book, "Domain Specific Design," Eric Evans talked about designing software by creating models that mimic the business problem. If you are interested in detailed treatment of domain specific design, terminology, language, I highly recommend reading this book or watching recordings of Eric’s talk on infoQ talk

Once you have modeled the business problem that you are trying to solve into objects and entities, you have a number of decomposition techniques available to you, depending on the language and platform of your choice.

One of the obvious choices is to start with shared libraries, which are available in almost in any language. Shared libraries give you the ability to place some common code that represents an aspect of your solution into a library. This technique has obviously been extensively used over the years. However, one downside of a shared library is its tight coupling – given that library is linked (statically or dynamically) into the process space of the caller invariably leads to tight coupling. This is not to say you cannot achieve loose coupling with libraries. You can, but it is largely up to you to maintain that discipline – there are no built-in language protections to safeguard against tighter coupling. As a result, we often see such a solution degenerating into a tightly coupled brittle solution.

The other downside of a shared library is that the language used to develop the library and the language of the consumer(s) is usually the same.

Component-based design (CBD) was developed as enhancement to the idea of libraries. Examples of component-based design include COM and CORBA. CBDs introduced a notion of binary protocol that serves as a "firewall" between the caller and component, thus enforcing more discipline in terms of sharing. Additionally, this firewall makes possible reuse easier across languages. For example, a C++ based COM component could be invoked via a program written in VB.

The other important benefit of component-based design is process isolation. In other words, the ability to host a component in its own process space. This process decoupling can improve modularity and can provide the ability to independently manage the lifecycle of a shared module – i.e., the ability to deploy newer versions without impacting the callers.

While component-based design was certainly an improvement over shared libraries, it is not without its own downsides. The binary protocol (often proprietary due to the lack of industry standards) used for communication between the components was not Web/Internet friendly and was widely considered too complex. Additionally, despite the process separation, the caller and the component often continued to run in the same security context. Finally, the notion of scalability – scale-out, state management, discovery were not first-class concepts or even at least industry standard interoperable concepts.

SOA was considered an improvement over CBD. In SOA, services became the fundamental elements for developing software, instead of components. However, it is important to note that SOA and CBD are not competing ideas. SOA can be thought of as a way to leverage artifacts of CBD, components, in an attempt to make them easier to consume. The biggest advancement was the support for multiple protocols, including the ones that work well over the Internet. Additionally, SOA came with a well-defined notion to describe its capabilities, functional and non-functional characteristics, thus making them easier to discover and use. Unlike the process isolation, the service boundary was well-defined. SOA ultimately engendered a series of specifications (referred to as WS-* spec) that addressed many aspects including transactions, coordination, management, and quality of service.

Despite the promise, it is safe to say that SOA has not lived up to its potential. We will leave that debate – "why SOA has or has not lived up to its promise" to others.

In the last two to three years, a subset of SOA principles, referred to as "Microservices," has gained popularity. Companies like Netflix and Twitter embody the principles of SOA at the service level. However, the focus is on "micro" sized services as opposed to more coarse-grained services. The idea of microservices is to apply the principle of "single responsibility" (part of Robert Martin’s five principles of OOD) to a service.

Since each microservice exhibits strong cohesion, it leads to a system that is loosely coupled, thus yielding a number of benefits:

i) Failure of one microservice does not cascade to other parts of the system

ii) Each microservice is autonomous – it can deployed into a separate execution context, have it own data store of choice, have its own caching tier

iii) Each microservice can be scaled independently

iv) Each microservice can be easily deployed or updated independently

v) Each microservice can in theory be implemented in a different (within reason of course) underlying technology of choice

vi) Given their granularity, microservices can be composable – in other words, it is possible for to compose a large business process by building on a collection of microservices

All this sounds good, but microservices are not a "free lunch.” As you probably guessed from the earlier description, the "micro" nature of can add significant operations overhead due to proliferation of instances – execution environment (PaaS containers, VMs), networking stack and even data stores. The only way to be successful in deploying a large number of instances and keeping them in sync is through automation. Automation is also key to making the microservices cost effective by spinning things up and down as needed.

So how do we deal with the overhead associated with microservices? It turns out that the cloud offers perhaps the only viable approach for dealing with these overheads while still enabling us to tap into the advantages of microservices. Here is how:

1. Infrastructure as code leading up to automated deployment pipelines (coupled with continous integration) offers a manageable approach to dealing with a potentially very large number of microservices.

2. The ability to spin execution context all the way from the smallest micro sized VM to the largest VM to a multi-tenant compute service where you drop your code and have it be executed in response to a trigger is perfectly suited for microservices. Add to this the support for containers such as Docker, and now you have a way to package and deploy a microservice (granted that Docker support is not limited to the cloud).

3. The ability to tap into the elasticity of a networking stack makes it simple to provision a large number of microservices end points

4. The ability to tap into database as service (SQL and No-SQL stores) to promote autonomy with microservices

5. Emphasis on a DevOps mindset in the cloud offers a cost effective approach to managing microservices


  • Decompose the business project into models – objects with bounded context
  • Shared libraries, components, and services are decomposability options. All have some limitations associated with them. Microservices seem promising.
  • The cloud offers a way to implement microservices cost-effectively through VMs and Docker containers

Azure is a fast moving platform. It is almost a full-time job just to keep with up the updates 🙂

So at VSLive! I presented a session on *my* top ten announcements in “T-10” months (June 2014 – March 2015). I hope to update this list each quarter.

So how I did I come up with this list?

Firstly, I focused on services that are GA (Generally Available), i.e. the services that come with a money-backed SLA. The only exceptions are “meta” features such as Docker and Resource Manager – which may not be GA themselves but produce an end result that is GA.

Secondly, I picked services that I felt are architecturally significant – services that are both key enablers for Azure based applications and cloud-native. In other words, these services have themselves come together as a result of capabilities enabled by the cloud, including elasticity, resilience and composability. Please allow me to provide a couple of examples to explain my definition of “architecturally significant:”

  • Azure automation is an excellent and beneficial service, but I picked Resource Manager as one of the IaaS announcements in my list. As you will see shortly, Azure Resource Manager is the definitive resource provisioning and management service going forward.


  • Mobile services is one of my favorite services and I have used it extensively. Of course, it GAed outside of the T-10 month period. In the last ten months the key enhancement to this service has been the .NET support, which is very useful for .NET developers but not enough so to be deemed architecturally significant.

Thirdly, this list is based on *just* my personal opinion. That said, I would love to hear your thoughts – which features do you find most appealing and why? Please take a moment to leave a comment below. Thanks!

I broke down the list below into four categories – infrastructure, data and application tiers, and the tooling that goes with all the tiers. I find the aforementioned categories to be the most logical way to organize the ever-increasing set of Azure services.


Infrastructure Tier

#1 Bigger and Better Compute, Storage, and Networking

G-Series machines offer more memory (448 GB) and more local solid state drive (SSD) storage (up to 6.59 TB) than other Azure virtual machine sizes in the past. Additionally, premium storage allows for adding up to 32 TB of persistent storage per virtual machine, with more than 50,000 IOPS per virtual machine at less than one millisecond latency for read operations.

Key enhancements in VNET now allow multiple site-to-site connections, enabling you to connect multiple on-premises locations to Azure DC. Additionally, you can now connect two VNETs even if they are running in two different regions.

Finally, ExpressRoute allows you to create private (i.e. not routed over the public internet) high throughput connections between Azure datacenters and your existing on-premises infrastructure. Furthermore, Express Route connections offer a 99.9% SLA on connection uptime and up to 10 GB per second bandwidth.

The above announcements will help remove most concerns related to cloud performance and hybrid setup.

#2 Better Support for Automation and Management

Azure Resource Manager *appears* to be the definitive approach for provisioning and managing resources in Azure. Azure resources such as Websites, Database, and VM can be organized in groups (called Resource Groups). Resource groups are units of scale and management and access control (RBAC). Resource group members can talk to each other. Additionally, billing, monitoring and quota information rolls up to a resource group.

Azure Resource Manager supports both a declarative model (JSON), as well as an imperative model (PowerShell). Azure Resource Group “templates” (definitions of resources that make up a resource) are idempotent and “tightly” coupled (in a good way – deleting a Resource Group will cause all the constituent resources to be deleted as well)

Based on the above, it is clear that Azure Resource Manager is a key underpinning for the DevOps on Azure.

#3 Support for Containers

Azure team has announced support for Docker, which is a popular technology that allows applications and runtime to be packaged (aka “Dockerized”) in a manner that allows any Docker container to be run regardless of the OS. Currently, these Docker containers are Linux-based containers, but Windows-based containers are expected to be available in the future.

The Azure team has announced that Azure will support the Docker orchestration API. This means that you can use the Docker API (Docker Machine, Composer, and Swarm) to create a custom orchestration to create and manage Docker images in Azure. The Azure team has also announced that organizations will be able to host private Docker repositories (collections of Dockerized application images) within Azure storage.

Docker support in Azure has the potential to facilitate application migration to and from the cloud, improve reliability of applications by including the dependencies, and increase cost-effectiveness of Azure, since multiple Dockerized applications can be hosted within a single VM.

Data Tier

#4 Big Data Enhancements

The big data-as-a-service “HDInsight” has grown significantly in recent months. This includes support for Apache Storm, HBase, Apache Mahout, and Hadoop 2.6. In addition, from an infrastructure perspective, you can now scale up the HDInsight cluster without deleting and recreating it, and you possess the ability to choose from additional VM sizes. There is built-in integration between Azure Website logs and HDInsight. Finally, HDInsight support for VNET is also GA.

The growing importance of big data cannot be overstated. HDInsight has added some significant capabilities that make it easier to set up and work with services such as websites and process real-time events using Apache Storm.

#5 SQL Database Service Tiers and Performance Plans

SQL Database has added three service tiers (Basic, Standard and Premium). These tiers offer you the ability to choose from a range of options – size limits, self-service restore, DR options and performance objectives. The three tiers map to seven performance characteristics levels. Think of levels as ways to quantify the performance in terms of throughput (DTU), benchmark, transaction rate, and consistency of performance. For example, a Standard/S0 level offers 10 DTUs, a maximum database size of 250 GB, 521 transactions per minute, and “better” consistency. Similarly, the Premium/P3 level offers 800 DTUs, a maximum database size of 500 GB, 735 transactions/sec, and the “best” consistency.

If you have looked at SQL Database in the past, liked its ease of use but weren’t so sure about its performance and throughput concerns, then the SQL Database service tiers and performance plans is for you.

#6 Machine Learning for the Masses

There is a lot written about machine learning these days. Personally, I like Arthur Samuel’s definition below:

Machine Learning is the field of study that gives computers the ability to learn without being programmed – Arthur Samuel (1959)

Arthur Samuel used machine learning to build a checkers program that over time became a better checkers player than Arthur Samuel himself. While machine learning concepts such as deep learning and neural networks have been around for a long time, it is the advent of the cloud that has finally made these concepts viable to implement and within the reach of the masses.

Azure Machine Learning takes this even a step further. It makes it easy just to create machine learning models using a browser-based UI, where you can select from a range of algorithms. Once you have created a machine learning model, it is also easy to operationalize it by publishing it as a web service.

If you need predictive analytics by tapping into best of class algorithms already in XBOX, Bing, etc., Azure Machine Learning is the place to be.

Application Tier

#7 Azure Websites – The Go-To Execution Host

If you are building a PaaS based application on Azure, chances are that you are leveraging Azure Websites. Of course Azure Websites has been GA for a long time. But this highly used service (300,000+ instances and counting) continues to add features at a rapid clip. The last ten months have been no different. The Azure Websites team GAed capabilities including:

i) WebJobs – ability to run batch jobs within the Websites

ii) Migration Assistant – A tool that analyzes your on-premises IIS application and recommends steps for moving it to Azure Websites

iii) VNET Integration – Ability to talk to resources such as Azure hosted or even on-premises based VMs from within an Azure Website.

iv) CDN Support – Integrate Websites content with Azure Content Delivery Network (CDN)

v) Multiple (Production +4 ) deployment slots gives the ability to easily alternate multiple versions on your application in production

Whether you are building a web application, hosting a REST endpoint, or hosting a pre-packaged app, Azure Websites is the place to start.

#8 Ensure a Successful API Program

Ensuring a successful API program is critical for any startup, ISV, or large enterprise that is increasingly looking to modernize and unify silos of APIs spread across the enterprise. Azure API management can help you develop a successful API Program by providing out of the box features such as discoverability of your API, self-enrollment, API documentation, policies, analytics and security.

APIs are considered the silent engines of growth for any modern enterprise. Azure API Management makes it easy to get started.

#9 Outsource Your Identity and Access Control Using Azure AD

Every application has a need to securely manage the identity and control access for its users. Beyond the core authentication and authorization features, each application also needs a number of related capabilities including single-signon, self-service governance, seamless API access, high availability, DR, and the ability to support a growing set of authentication protocols including SAML, OAuth, OpenID, WS-Federation, etc.

This is why it makes so much sense to “outsource” this aspect of the application to a service like Azure Active Directory (or Azure AD in short).

Even though the premium version been available for a while, the Azure AD team has GAed some key capabilities in the last ten months, including:

Azure Active Directory Application Proxy – This feature allows for an on-premises application to be published via Azure AD and made available to external users as SaaS service.

Azure Active Directory Basic Tier – The Azure AD premium edition GAed in April 2014. It was more about enterprise oriented features such as multi-factor authorization, self-group management, writeback password resets to on-premises directories. In the last ten months Azure AD team has GAed support for the basic edition. The basic edition offers a lower price point and is designed for the “desk-less” worker. It has limited self-service capabilities and cannot write password resets to on-premises directories. Interestingly, the basic edition comes with the same 99.9% uptime SLA and no limits on storing objects.

If you are looking to outsource identity and access control for your Azure and on-premises applications, Azure AD can come in very handy.

Tooling Enhancements

#10 Load Testing Made Easy

While there have been a number of Azure-related tooling enhancements in Visual Studio, the one tool that stands out is the Visual Studio Load Testing Service. Technically this capability GAed in April 2014, outside of our “T-10” month timeframe, but I decided to include it anyways given its significance. Cloud Load Testing (CLT) offers the following features:

i) Easy to simulate a varying load (whether it is 200 or 200,000 concurrent users). Of course you only pay for what you use.

ii) The same tests that we have used on-premises in the past also work in CLT. The only difference is that the test execution is happening in the cloud.

Load testing has never been easy – the hardware, software and setup costs were non-trivial. With CLT you can conduct load tests easily, early, and often in your development lifecycle.

Public and private peering with Azure ExpressRoute is a topic that has come up a lot in my recent conversations recently so I thought I would capture some thoughts here:

What is peering?

According to Wikipedia contributors, in computer networkingpeering is a voluntary interconnection of administratively separate Internet networks for the purpose of exchanging traffic between the users of each network. An agreement by two or more networks to peer is instantiated by a physical interconnection of the networks and an exchange of routing information through the Border Gateway Protocol (BGP) routing protocol.

In Azure, peering translates into a private, dedicated and high-throughput connection between Azure and an on-premises data center via ExpressRoute. Note that Azure does offer Virtual Network (point-to-site) and Virtual Network (site-to-site) connectivity options, but rather, the routing is static or dynamic VPN. In contrast, ExpressRoute is based on BGP routing. For a detailed comparison of these options with guidance to choose between them, please refer to Ganesh Srinivasan’s blog post.

Furthermore, peering can be private or public. Public peering, as the name suggests, is a peering arrangement where the interchange between the participating networks happens over a public exchange point. Likewise, a private peering is a peering arrangement where the interchange between participating networks happens over a private exchange point.

So what does private / public peering mean in terms of Azure?

Public and Private Peering with Azure

As stated earlier, ExpressRoute allows you to create a dedicated circuit between on-premises and Azure DC. As part of this dedicated circuit, you get two independent routing domains (shown in green and orange below).

The “orange” link depicts private IP-based traffic among a customer’s network and VNET and VMs running in Azure.  There is a NAT in the path. Since the exchange point is completely private, this link represents a private peering based connection.

The “green” link depicts traffic between a customer’s network with Azure-based services that have a public endpoint (such as Azure Storage). Since the exchange point in this instance is indeed public, this link represents a public peering based connection.  Now, since the traffic is originating from a private IP (on-premises) address, ExpressRoute will NAT the traffic before it delivers the packets to the public endpoint of a service such as Azure Storage (ExpressRoute will use MSFT address range for the NAT pool) This means customers don’t have to go through their internet edge (proxy, firewall, NAT) to reach public Azure services, and thus *not* taking up a chunk of their internet bandwidth to communicate with Azure.

ExpressRoute Public and Private Peering

Please note that not all Azure public services are accessible via ExpressRoute public peering. The following services are not supported over ExpressRoute public peering at the time of writing of this post.

For more information please visit:

Express Route FAQ.

Extending Your On-Premises Network into Azure Securely

In this eBook, I present app solutions for different scenarios, with perspectives from a cast of characters which includes a power user, a developer, an administrator and an industry analyst. In these scenarios, the following questions will be answered:

• Why are apps needed? • What nagging problems are they designed to solve? • What kinds of apps can we expect to see in the marketplace? • How will SharePoint apps be secured? • What are the various revenue models supported? • Would in-app purchases be allowed? What about ads? • What is the difference between a public app store and a corporate app catalog?

The eBook is available at

In the past, I have written about the benefits of Platform as a Service (PaaS) style of applications. While I continue to believe that PaaS offers the best ROI for hosting custom applications in the cloud, there are a number of scenarios where inserting elements of Infrastructure as a Service (IaaS) to a PaaS solution can help alleviate some of the limitations that have prevented the adoption of PaaS. In a recently published post on the appliedis blog, I  look at a few compelling scenarios that are enabled by combining PaaS with the recently announced IaaS features within a Windows Azure Cloud Service.

Later today I will be presenting the “Cloud computing with the Windows Azure Platform” boot camp at MIX. My session is comprised of three sections:

  • Overview of Cloud Computing
    Introduction to Windows Azure Platform
  • Review an on-premise MVC3 app
    Move the on-premise app to Windows Azure
  • Fault Tolerance and Diagnostics
    Tips & Tricks – Building Scalable Apps in the cloud

As part of the second session, I will go over the steps to “Azure-enable” an existing on-premise MVC 3 based web application. This blog is an attempt to capture these steps for the benefit of the attendees and other readers of this blog.

Before we begin, let me state the key objectives of this exercise:

    • Demonstrate that apps built using currently shipping, on-premise technologies (.NET 4.0 / VS 2010) can easily be moved to the Windows Azure Platform. (Of course, the previous version of .NET (3.5 Sp1) is supported as well.)
    • Understand subtle differences in code between  running on-premise and on the Windows Azure platform.
    • Reduce the number of moving parts within the application by “outsourcing” a number of functions to Azure based services.
    • Refactor the application to take advantage of the elasticity and scalability characteristics, inherent in a cloud platform such as Windows Azure.


Community Portal – An MVC3 based on-premise application

The application is simple by design. It is a Community Portal (hereafter interchangeably referred to as CP) that allows users to create tasks. To logon to the CP, users need to register themselves. Once a task has been created, users can kick-off a workflow to guide the task to completion. The workflow represents a two-step process that routes the request to the assignee, first, and then to the approver. In addition to this primary use case of task creation and workflow, Community Portal also allows users to access reports such as “Tasks complete/ Month”.






The following diagram depicts the Community Portal architecture. It is comprised of two subsystems: 1) an MVC3 based Community Portal site, and 2) a WF 4.0 based Task Workflow Service. This is very quick overview assuming that you are familiar with the core concepts such as MVC 3, EF, Code-First and so on.



Community Portal is a MVC 3 based site. The bulk of the logic is resides within the actions  as part of the TasksController class.  Razor is used as the ViewEngine. Model is based on EF generated entities. Data annotations are used to specify validation for individual fields.  Community Portal uses the built-in membership provider to store and validate user credentials. CP also uses the built-in ASP.NET session state provider to store and retrieve data from the cache. In order to avoid hitting the database on each page refresh, we cache the TaskSummary (list of tasks assigned to a user) in the session state. 



Tasks created by the users are stored in SQL Server. EF 4.0, in conjunction with the Code-First library, is used to access the data stored in SQL Server. As part of the task creation, users can upload an image. Uploaded images are stored in SQL Server using the FILESTREAM feature.  Since the FILESTREAM allows for storing the BLOB data on a NTFS volume, it provides excellent support for streaming large BLOBs [as opposed to the 2GB limit imposed by varbinary(max)]. When the user initiates a workflow, a message is sent over to WCF using the BasicHttpBinding. This causes the WF instance to be created. This brings us to the second subsystem – workflow host.

As stated, Task Workflow Service consists of a WF 4.0-based workflow program hosted inside a console application (we could have just as easily hosted this in IIS). WF program is based on built-in Receive, SendReply, and InvokeMethod activities. As stated, this workflow is a two-stage workflow. The first call into the workflow kicks off a new instance. Each new instance updates the task status to “Assigned” via the InvokeMethod activity and sends a reply to the caller. Then the workflow waits for “task completed” message to arrive. Once the “task completed” message arrives, the workflow status is marked “complete”, followed by a response to the caller. The last step is repeated for the “task reviewed” message.


In order to ensure that all messages are appropriately correlated (i.e. routed to the appropriate instance), a content-based correlation identifier is used. Content-based correlation is new in WF 4.0. It allows an element in the message (in this case taskId) to server as the correlation token. Refer to the screenshot below: Xpath query is used to extract the TaskId from the message payload. The WF 4 runtime compares the result of the Xpath expression to the variable pointed to by the CorrelatesWith attribute to determine the appropriate instance where the message needs to be delivered.



A quick word on the reporting piece, again for the sake of simplicity, the Community Portal relies on client report definition files (.rdlc). This is based on the local processing mode supported by the report viewer control. Since the ReportViewer control (a server-side control) cannot be used inside MVC, an alternate route was created.

Finally, the following diagram depicts the on-premise solution – it consists of two projects: 1) an MVC 3 based CommunityPortal project, and 2) a console application that hosts the WF 4.0 based TaskWorkflow.



This concludes our whirlwind tour of the on-premise app.

Changing Community Portal to run on Windows Azure

Let us switch gears and discuss how the on-premise version of Community Portal can be moved to the Windows Azure Platform.

Even though our on-premise application is trivial, it includes a number of moving parts. So if we were to move this application to IaaS (Infrastructure as a Service) provider, we would have to setup and manage the various building blocks ourselves. For instance, we would need to install Windows Server AppFabric caching and setup a pool of cache servers; we would also have to install SQL Server and setup high availability; we would have to install an identity provider (IP) and setup user database and so on. We have not even discussed the work involved in keeping the servers patched.

Fortunately, Windows Azure platform is a PaaS offering. In other words, it provides a platform of building block services that can make it easier to develop cloud-based applications. Application developers can subscribe to a set of pre-built services as opposed to creating and managing their own. There is one other important benefit of PaaS – the ability to treat the entire application (including the virtual machines, executable and binaries) as one logical service. For instance, rather than logging on to each server (that makes up the application) and deploying the binaries to them individually, Windows Azure allows developers to simply upload the binaries and a deployment model to the Windows Azure Management portal – as you would expect there is a way to automate this step using the management API. Window Azure in turn allocates the appropriate virtual machines, storage and network, based on the deployment model. It also takes care of installing the binaries to all the virtual machines that have been provisioned. For more a detailed discussion on PaaS capabilities of Windows Azure PaaS, please refer to my previous blog post.

The following diagram illustrates the different pieces that make up a Windows Azure virtual machine (also referred to a compute unit). The binaries supplied by the application developer are represented as the dark grey box. The rest of the components are supplied by the Windows Azure platform. Role runtime is some bootstrapping code that we will discuss later in the blog post. Together, this virtual machine represents an instance of software component (such as an MVC 3 site, a batch executable program, etc.) and is commonly referred to as a role. Currently, there are three types of roles – Web role, Worker Role and VM role. Each role type is designed for a type of software component. For instance, a web role is designed for web application or anything related to it; a worker role is designed for long running, non-interactive tasks. An application hosted within Azure (commonly referred to as an Azure-hosted service) is made up of one more types of roles. Another thing to note is that an Azure-hosted application can scale by adding instances of a certain type.



Now that you understand the core concepts (such as deployment model, role and role instances) let us resume our discussion on converting the on-premise application to run on Windows Azure. Let us begin with a discussion of the deployment model. It turns out that the deployment model is an XML file that describes things such as the various roles that make our application, number of instances of each role, configuration settings, port settings, etc. Fortunately, Visual Studio provides tooling so that we don’t have to hand create the XML file. Simply add a Windows Azure project to the existing solution as shown below.


Select a worker role. Remember that a worker role is designed for a long-running task. In this instance, we will use it to host instances of TaskWorkflow. There is no need to select a web role as we will take the existing CommunityPortal project and map it to a web role.



We do this by clicking on Add Web Role in the solution (as shown below) and selecting the CommunityPortal project.


Here is the screen shot of our modified  solution structure. Our solution has two roles.  To mark the transition to an Azure service, I dropped the OnPremise suffix from our solution name – so our solution is now named CommunityPortal.


Through these steps, we have generated our deployment model!

The following snippet depicts the generated ServiceDefinition file. This file contains definitions of role, endpoints, etc. As you can see, we have one web role and one worker role as part of our service. The Sites element describes the collection of web sites that are hosted in a web role. In this instance, we have a single web site that is bound to an external endpoint that is listening to HTTP traffic over port 80 ( line # 12 & 17 ).

   1:  <?xml version="1.0" encoding="utf-8"?>
   2:  <ServiceDefinition name="WindowsAzureProject5" xmlns="">
   3:    <WorkerRole name="WorkerRole1">
   4:      <Imports>
   5:        <Import moduleName="Diagnostics" />
   6:      </Imports>
   7:    </WorkerRole>
   8:    <WebRole name="CommunityPortal">
   9:      <Sites>
  10:        <Site name="Web">
  11:          <Bindings>
  12:            <Binding name="Endpoint1" endpointName="Endpoint1" />
  13:          </Bindings>
  14:        </Site>
  15:      </Sites>
  16:      <Endpoints>
  17:        <InputEndpoint name="Endpoint1" protocol="http" port="80" />
  18:      </Endpoints>
  19:      <Imports>
  20:        <Import moduleName="Diagnostics" />
  21:      </Imports>
  22:    </WebRole>
  23:  </ServiceDefinition>

.csharpcode {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
.csharpcode pre {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
.csharpcode pre {
margin: 0em
.csharpcode .rem {
color: #008000
.csharpcode .kwrd {
color: #0000ff
.csharpcode .str {
color: #006080
.csharpcode .op {
color: #0000c0
.csharpcode .preproc {
color: #cc6633
.csharpcode .asp {
background-color: #ffff00
.csharpcode .html {
color: #800000
.csharpcode .attr {
color: #ff0000
.csharpcode .alt {
background-color: #f4f4f4; margin: 0em; width: 100%
.csharpcode .lnum {
color: #606060

While the service definition file defines the settings, the values associated with these settings reside in the service configuration file. The following snippet shows the equivalent service configuration file. Note the Instances element (line #4 & line #10) that defines the number of instances for a given role. This tells us that changing the number of instances of a role is just a matter of changing a setting within the service configuration file. Also note that we have one or more configuration settings defined for each role. This seems a bit odd doesn’t it? Isn’t Web.config the primary configuration file for an ASP.Net application? The answer is that we are defining configuration settings that apply to one or more instances of a web role. There is one other important reason for preferring the service definition file over web.config. But to discuss that, we need wait until we have talked about packaging and uploading to application binaries to Windows Azure.


   1:  <?xml version="1.0" encoding="utf-8"?>
   2:  <ServiceConfiguration serviceName="WindowsAzureProject5" xmlns="" osFamily="1" osVersion="*">
   3:    <Role name="WorkerRole1">
   4:      <Instances count="1" />
   5:      <ConfigurationSettings>
   6:        <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
   7:      </ConfigurationSettings>
   8:    </Role>
   9:    <Role name="CommunityPortal">
  10:      <Instances count="1" />
  11:      <ConfigurationSettings>
  12:        <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
  13:      </ConfigurationSettings>
  14:    </Role>
  15:  </ServiceConfiguration>

.csharpcode {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
.csharpcode pre {
background-color: #ffffff; font-family: consolas, “Courier New”, courier, monospace; color: black; font-size: small
.csharpcode pre {
margin: 0em
.csharpcode .rem {
color: #008000
.csharpcode .kwrd {
color: #0000ff
.csharpcode .str {
color: #006080
.csharpcode .op {
color: #0000c0
.csharpcode .preproc {
color: #cc6633
.csharpcode .asp {
background-color: #ffff00
.csharpcode .html {
color: #800000
.csharpcode .attr {
color: #ff0000
.csharpcode .alt {
background-color: #f4f4f4; margin: 0em; width: 100%
.csharpcode .lnum {
color: #606060


Visual Studio makes it easy to work with the service configuration settings so developers don’t have to work with the XML directly. Following screenshot shows the UI for adjusting the configuration settings.


Now that we have the deployment model, it’s time to discuss how we package up the binaries (recall that to host an application on Windows Azure, we need to provide a deployment model and the binaries ). Before we create the package, we need to make sure that all the files we will need to run our application in Window Azure are indeed included. By default, all the application assemblies will be included. However, recall that Windows Azure is providing the environment for our application to run. So we can expect .NET 4.0 framework (or 3.5 Sp1) assemblies, C Runtime components, etc. to be available to the applications running in Windows Azure. There are however, some add-on packages that are not available provided in the environment today such as MVC3. This means we need to explicitly include the MVC3 assemblies as part of our package by setting the CopyLocal=true.

Now that we have covered the concept of a service package and configuration file, let us revisit the discussion on where to store configuration settings that need to change often. The only way to change a setting that is part of the package (such as the settings included within the web.config) is to redeploy it. In contrast, settings defined in the service configuration can easily be changed via the portal or the management API, without the need to redploy the entire package. So, now that I have convinced you to store the configuration settings in the service configuration files, we must make a change to the code to read settings from the new location. We need to use the RoleEnvironment.GetConfigurationSettingValue to read the value of a setting from the service configuration file. RoleEnvironment class gives us access to the Windows Azure runtime. In addition to accessing the configuration settings, we can use this class to find out about all the roles instances that are running as part of the service. We can also use it to make checks to see if the code is running in Windows Azure. Finally, we also need to set the global configuration setting publisher inside the Global.asax.cs as shown below:



   1:             CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
   2:              {
   3:                  configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
   4:              });

That’s all the changes we will make to the web role for now.

But we also need to modify the worker role we just added. The on-premise version relied on a console application to the host the task workflow. The equivalent piece of code (shown) can be moved to the Run method within the RoleEntryPoint. This begs the question – what is RoleEntryPoint and why do I need it? Recall that when discussing the Azure VM, we briefly alluded to the Role Runtime. This is the other piece of logic (other than the application code files themselves) that an application developer can include as part of the package. It allows an application to receive callbacks (OnStart, OnStop. etc.) from the runtime environment and is, therefore, a great place to inject bootstrapping code such as diagnostics, another important example of the type of callback is the notification when there is a change in service configuration setting. We talked about the role instance count as being a service configuration setting. So if the user decides to add or remove role instances, the application can receive a configuration change event and act accordingly.

Strictly speaking, including a class derived from RoleEntryPoint is not required if there is no initialization to be done. That is not the case with worker role we added to the solution. Here we need to use the OnStart method to setup WorkflowService endpoint and open the workflowhost as shown in the snippet below. Once the OnStart method returns (with a return value of true) we will start receiving incoming traffic. This is why it is important to have the WorkflowServiceHost all ready before we return from OnStart.

The first line of the snippet below requires some explanation. While running on-premise, the base address was simply the local host and dynamically assigned port. However, when the code is being run inside Windows Azure, we need to determine at runtime which port has been assigned to the role. The worker role needs to setup an internal endpoint to listen to incoming requests to the workflow service. Choosing an internal endpoint is a decision we made. We could have just as easily decided to allow the workflow host to listen on an external point (available on the public internet) However, in deference to the defense in depth idea, we decided to limit the exposure to the workflow host and only allow other role instances running as part of the service to communicate with it.


   1:  RoleInstanceEndpoint internalEndPoint =
   2:       RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["TaskEndpoint"];
   4:    string protocol = "http://";
   5:    string baseAddress = string.Format("{0}{1}/", protocol, internalEndPoint.IPEndpoint);
   7:    host = new WorkflowServiceHost(new TaskService(), new Uri(baseAddress));
   9:    host.AddServiceEndpoint("ITaskService", new BasicHttpBinding(BasicHttpSecurityMode.None) { HostNameComparisonMode = HostNameComparisonMode.Exact }, "TaskService");
  11:    host.Open();

The Run method then simply runs a never ending  loop as shown below.  This is equivalent to the static void Main method from our console application.

   1:             Trace.WriteLine("TaskServiceWorkerRole entry point called", "Information");
   3:              while (true)
   4:              {
   5:                  Thread.Sleep(10000);
   6:                  Trace.WriteLine("Working", "Information");
   7:              }

Once we have gone through and included the  appropriate files, packaging the application binaries is just matter of right clicking and selecting the publish option. This brings up the publish dialog as shown below. For now we will simply select “Create Service Package option” and click OK.



That’s it. At this point, we have both the required artifacts we need to publish to Windows Azure. We can browse to the (shown below) and create a new service called CommunityPortal. Notice the two highlighted text boxes – here we provide the package location and the deployment model. Let us  go ahead and publish our application to Windows Azure.



Not so fast …

We’re all done and the application is running on Windows Azure! Well almost, except we don’t have a database available to the code running in Windows Azure (this includes the Task database and the membership database). Unless of course, we make our on-premise database instances accessible to the Windows Azure hosted service. While doing so is technically possible, it may not be such a good idea because of latency and security concerns. The alternative is to move the databases close to the Windows Azure hosted service. Herein lies an important concept. Not only do we want to move these databases to Windows Azure, we also want to get out of the business of setting up high availability, applying patches, etc. for our database instances. This is where the PaaS platform capabilities offered by Windows Azure shine.

In the next few subsections, we will look at approaches that allow us to “get out of the way” and let the Windows Azure platform take care of as many moving parts as possible. One other thing – changing the on-premise code to take advantage of Azure-provided services sounds good, but, it is only practical to do if there is semantic parity between the two environments. It is not reasonable to expect developers to maintain two completely different code bases. Fortunately, achieving semantic parity is indeed the key design goal that designers of Windows Azure had in mind. The following diagram represents the symmetry between the between on-premise and on Windows Azure offerings. It is important to note that a complete symmetry between on-premise and Windows Azure is not there today and is unlikely to be there anytime soon. Frankly, achieving complete symmetry is a journey on which the entire ecosystem including Microsoft, ISVs, SIs and developers like us, have to embark on together. Only then can we hope to realize the benefits that PaaS has to offer.


Let us start with moving the database to the cloud.

Windows Azure includes a highly available database as a service offering called SQL Azure. The following diagram depicts the architecture of SQL Azure. SQL Azure is powered by a fabric of SQL Servers nodes that allows for setting up highly elastic (i.e. ability to create as many databases as needed) and redundant (i.e. resilience against failures such as corrupted disk) databases. While the majority of the on-premise SQL Server functions are available within SQL Azure, there is not 100% parity between the two offerings. This is mainly due to the following reasons :

1) SQL Azure team has simply not gotten around building this capability into SQL Azure yet, however, a future release is planned to address this. An example of such a feature is CLR-based stored procedures. This is something that is not available on SQL Azure today, but the team has gone on record to add this capability in the future.

2) It simply does not make sense to enable certain features in a hosted environment such as SQL Azure. For example, ability to specify file groups will limit how the SQL Azure service can move the databases around. So this feature is unlikely to be supported by SQL Azure.



As application developers, all we need to do is provision the database on the Windows Azure portal by specifying the size as shown below. For this sample, we have a very modest size requirement. So we don’t have to worry about sharding our data across multiple databases. The next step is to replace the on-premise connection string with the SQL Azure connection string.




Remember from our earlier discussion that there is not 100 % parity between on-premise SQL Server and SQL Azure. Reviewing our on-premise database reveals one aspect of our schema that cannot be migrated to SQL Azure – this is the FILESTREAM column type that we used to efficiently store an uploaded image associated with a task. The FILESTREAM column type allows us to store the image on a mounted NTFS volume outside of the data file. This is something that SQL Azure is unlikely to support. Fortunately, Windows Azure provides Azure Blob storage that allows us to store large BLOBs efficiently. Furthermore, we don’t have to worry about managing the NTFS volume (as is the case with FILESTREAM) – Azure Blob storage takes care of that for us. It provides a highly elastic store that is also fault tolerant (as it keeps multiple copies of the data). Finally, should we need to, we can serve the images from a location closer to our users by enabling the Content Delivery Network (CDN) option on our Azure Blob containers. Hopefully, I have convinced you that Azure Blob storage is a much more optimal place for storing our BLOB data.

Now, let’s look at the code change that is needed to store the images in Blob store. The change is rather simple. First, we will upload the image to the Azure Blob storage. Next, we will take the address of the Blob container and store it in the Tasks table. Of course, we will need to change the Tasks table to replace the FILESTREAM column with the varchar (255) that allows us to store the address of the Blob container.


   1:         public void SaveFile(HttpPostedFileBase fileBase, int taskId)
   2:          {
   3:              var ext = System.IO.Path.GetExtension(fileBase.FileName);
   5:              var name = string.Format("{0:10}_{1}{2}", DateTime.Now.Ticks, Guid.NewGuid(), ext);
   7:              CreateOnceContainerAndQueue();
   9:              var blob = blobStorage.GetContainerReference("imagelib").GetBlockBlobReference(name);
  10:              blob.Properties.ContentType = fileBase.ContentType;
  11:              blob.UploadFromStream(fileBase.InputStream);
  13:              // Save the blob name into the table
  15:              using (SqlConnection conn = new SqlConnection(RoleEnvironment.GetConfigurationSettingValue("CommunityPortalEntities")))
  16:              {
  17:                  SqlCommand comm = new SqlCommand("UPDATE Tasks SET BlobName = @blobName WHERE TaskId = @TaskId", conn);
  18:                  comm.Parameters.Add(new SqlParameter("@blobName", name));
  19:                  comm.Parameters.Add(new SqlParameter("@TaskId", taskId));
  21:                  conn.Open();
  22:                  comm.ExecuteNonQuery();
  23:              }
  24:          }

With this change, we are ready to hook up the SQL Azure based CommunityPortal database to the rest of our application, but what about the existing SSRS reports? What happens to these reports, now that the database has been moved to SQL Azure? We have two options: 1) continue to run the report on an on-premise version of SQL Server Reporting Services (SSRS) by adding the SQL Azure database as a datasource, and 2) move the reporting function to an Windows Azure hosted SSRS service instance (currently in a CTP). The benefit of the latter is obvious by now. We get to subscribe to “reporting as a service” capability without being bogged down with installing and maintaining SSRS instances ourselves. The following screenshot depicts how, using Business Intelligence Development Studio BIDS , we can deploy the existing report definition to SQL Azure Reporting Services instance. Since our database is already migrated to SQL Azure, we can easily add it as the report datasource.


Outsourcing the authentication setup

What about the ASP.NET membership database? I suppose we can also migrate it to SQL Azure. In fact, it turns out that there is a version of ASP.NET membership database install scripts that are designed to work with SQL Azure. So once we migrate the data to SQL Azure based membership database, it is straight forward to rewire our Azure hosted application to work with the new provider. While this approach works just fine, there is one potential issue. Our users do not like the idea of registering a new set of credentials to access the Community Portal. Instead, they would like to use their existing credentials such as Windows LiveID, Facebook, Yahoo! and Google to authenticate to the Community Portal. Since these credentials such as Windows Live ID allow a user to establish their identity, we commonly refer to them as identity providers, or IP. Turns out that IPs rely on a number of different underlying protocols such as OpenID, OAuth etc. Furthermore, these protocols tend to evolve constantly. The task of interacting with a number of distinct IPs seems daunting. Fortunately, Windows Azure provides a service called Access Control Service (ACS) can simplify this task. ACS can act as an intermediary between our application and various IPs. Vittorio and Wade authored an excellent article that goes through the detailed steps required to integrate our application with ACS. So I will only provide a quick summary.

  • Logon to the
  • Create a namespace for the Community Portal application as shown below.


    • Add the Identity Providers we want to support. As shown in the screenshot below, we have selected Google and Windows Live ID as the two IPs.


    • Notice that the role of our application has changed from being an IP (via the ASP.NET membership provider that was in place earlier) to being entity that relies on well-known IPs. In security parlance, our Community Portal application has become a replying party or RP. Our next step is to register Community Portal as a RP with ACS. This will allow ACS to pass us information about the authenticated users. The screenshot below illustrates how we setup Community Portal as an RP



    • The previous step concludes the ACS setup. All we need to do is copy and paste some configuration settings that ACS has generated for us (based on the IPs and RP setup). This configuration setting needs to be plugged into the Community Portal source code. The configuration information that needs to be copied is highlighted in the screenshot below.


    • Finally, inside Visual Studio we need to add ACS as our authentication mechanism. We do this by selecting “Add STS reference” menu and plugging in the configuration metadata we copied from the ACS portal, as shown in the screenshot below.



    • Windows Identity Foundation (WIF) classes needed to interact with ACS are not already installed within the current versions of OS available on Windows Azure. To get around this limitation, we need to install the WIF update as part of the web role initialization.
    • That’s it! Users will now be prompted to select an IP of their choice, as shown below:


    Outsourcing the caching setup

     Up until now we have successfully migrated the task database to SQL Azure. We have also “outsourced” our  security scheme to ACS. Let us look at one last example of a building block service provided by Windows Azure Platform- caching. The on-premise version of Community Portal relies on default in-memory ASP.NET session state. The challenge with moving this default implementation to the cloud is that all web role instances are networked load balanced, so storing the state in-proc on one of the worker role instance does not help. We can get around this limitation by install caching components such as memcached on each of our web role instances.  However, it is our stated goal to  minimize the number of moving parts. Fortunately, what is now becoming a recurring theme of this blog post, we can leverage a Windows Azure Platform provided service called the AppFabric Caching Service.  The next set of steps illustrate how this can be accomplished:

    • Since AppFabric Caching Service is in CTP, we first browse to Appfabric labs portal  –
    • We create a new cache service namespace as shown below.




    • We are done creating the cache. All we need to do is grab the configuration settings from the portal (as shown below) and plug it into the web.config of the Community Portal web project. 


    • With the last step, our ASP.NET state session provider is now based on AppFabric Caching Service. We can continue to use the familiar session syntax to interact with the session state.


    We have taken an on-premise version of Community Portal built using currently shipping technologies and moved it to the Windows Azure Platform. In the process  we have eliminated many moving parts of the on-premise application. The Windows Azure based version of Community Portal can now take advantage of the elasticity and scalability characteristics inherent in the platform.

    Hope you found this description useful. The source code for the on-premise version can be found here. The source code for the “Azure-enabled” version can be found here. Also, if you would like to test drive Community Portal on Windows Azure – please visit  (I will leave it up and running for a few days)



    Netizen ( is a Windows Phone 7 application (available in the marketplace for free) that brings the voting record of your congressional representative to your finger tips, directly from your mobile phone. Simply select the Member of Congress you want to follow and "flick through" their voting record. Information about each member’s voting record is stored in Windows Azure Storage and is updated daily.

    But don’t just follow how your representative is voting in congress, make your voice heard. By clicking on the "Like It" button on the mobile application, you can influence your friends and neighbors about the bill through the power of social networking. For each bill, Netizen automatically provisions a Facebook page[1] dedicated to your member of congress. This page acts almost as a virtual ballot for a bill as well as a community hub where fellow constituents can gather to express their support. Pasted below are some screenshots from the application:

    Not using a mobile device? No problem! Simply point your browser to the addresses listed below: To get a list of representatives for the state of Virginia, use this address:

    To view the recent votes cast by the representative from Virginia 11th district, use this address:

    To view the Facebook page for the Bill H.R.4853 and Virginia 8th District, use this address:


    Screenshot #1 – Select state


    Screenshot #2 – Select Representative


    Screenshot #3 – “Flick through” the most recent roll call votes


    Screenshot #4 –  “Virtual ballot” – Dynamically generated Facebook page,


    Technical Details

    Netizen combines the power of Windows Phone 7 & Windows Azure. Here is how the application works

    WP7 App

    Windows Phone 7 app is designed to have a small footprint. As a result, the bulk of the functionality is located inside the Azure hosted service. Here are some of key highlights:

    1) The main screen (display of votes) is based on Pivot Control. Pivot Control provides a quick way to manage views. Each view (PivotItem) displays the details associated with a vote. Pivot control makes it really convenient for switching between different vote views. The Pivot control employs lazy loading to conserve resources. In addition, in order to limit the resources used, we only display the ten most recent votes.

    2) Some addition performance related items include:

    · Invoking garbage collection explicitly after the rebinding the pivot control.

    · Storing the state in the isolated storage in order to make application resumption quicker.

    · Doing all the data transformation on the server, again in order to reduce the processing foot-print on WP7.

    · Keeping a close watch on the overall size of the XAP file – the current version is under 150K.

    The following link provides great performance related tips:

    3) Since it is important to support a disconnected mode of operation, we always store the most recent data obtained from the Azure service into isolated storage. Another possibility is use of Sync Framework 4.0.

    4) We experimented with embedding the browser control for web-based logins. It is possible for the web page to callback into the Silverlight code.

    5) All the Netizen Azure service methods are based on REST. This made it quite easy to use the WebClient class to access them. A better alternative would have been the use reactive extensions as it would have made the code a bit cleaner.

    6) One gotcha that we ran into was based on our decision to use SyndicationFeed as the data format. This was based on our desire to allow users to access the voting records
    via their favorite feed readers (in addition to the WP7 app). In order to process the returned SyndicationFeed type, we had to explicitly add a reference to System.ServiceModel.Syndication. Here is the relevant code:

       1: XmlReader reader = XmlReader.Create(new StringReader(xmlContent));

       2: SyndicationFeed sFeed = SyndicationFeed.Load(reader);

       3:                    var entries = from en in sFeed.Items.Take(MaxNumberOfItemsPerFeed)

       4:                                  select en;

       5:                    foreach (var en in entries)

       6:                    {

       7:                        var x = en;

       8:                        SyndicationContent sc = x.Content;

       9:                        XmlSyndicationContent xsc;

      10:                       if (x.Content.Type == "text/xml" || x.Content.Type == "xml")

      11:                       {

      12:                           xsc = (XmlSyndicationContent)x.Content;

      13:                           VoteDetails vds = xsc.ReadContent<VoteDetails>();

      14:                           Votes.Add(vds);

      15:                       }

      16:                 }


    Where the class VoteDetails is defined as shown below:

       1: [DataContract(Namespace = "")]

       2:         public class VoteDetails

       3:         {

       4:             [DataMember]

       5:             public string BillID { get; set; }

       6:             [DataMember]

       7:             public string Date { get; set; }

       8:             [DataMember]

       9:             public string Democratic_AYEs { get; set; }

      10:             [DataMember]

      11:             public string Democratic_NAYs { get; set; }

      12:             [DataMember]

      13:             public string Description { get; set; }

      14:             [DataMember]

      15:             public string Question { get; set; }

      16:             [DataMember]

      17:             public string Republican_AYEs { get; set; }

      18:             [DataMember]

      19:             public string Republican_NAYs { get; set; }

      20:             [DataMember]

      21:             public string Result { get; set; }

      22:             [DataMember]

      23:             public string Roll { get; set; }

      24:             [DataMember]

      25:             public string Vote { get; set; }

      26:         }

    Azure Service

    As stated earlier, the bulk of processing resides within the Azure based service.

    This includes the following:

    · A WCF/ REST service hosted on Windows Azure (x-small instance) that exposes the voting record as an RSS/ATOM feed. Here is what the WCF contract looks like.

       1: namespace Netizen.Contract

       2: {

       3:     [ServiceContract]

       4:     [ServiceKnownType(typeof(Atom10FeedFormatter))]

       5:     [ServiceKnownType(typeof(Rss20FeedFormatter))]

       6:     public interface INetizenService

       7:     {


       9:         [OperationContract]

      10:         [WebGet(UriTemplate = "rep/{zip}-{zipFour}")]

      11:         string GetRepresentative(string zip, string zipFour);


      13:         [OperationContract]

      14:         [WebGet(UriTemplate = "reps/{state}/{feedType}")]

      15:         SyndicationFeedFormatter GetRepresentatives(string state, 

      16: ng feedType);



      19:         [OperationContract]

      20:         [WebGet(UriTemplate = "vote/{repID}/{feedType}")]

      21:         SyndicationFeedFormatter GetVotes(string repID, string feedType);


      23:         [OperationContract]

      24:         [WebInvoke(UriTemplate =

      25: bscribe/{state}/{district}/{notificationUri}")]

      26:         void SetSubscription(string state, string district, 

      27: ng notificationUri);


      29:     }

      30: }


    All the data is stored in Azure tables. A batch program is used to obtain the congressional voting record from Office of the Clerk of the U.S. House of Representatives and stored in Azure Tables. Data is appropriately transformed to make sure that Azure Table queries are efficient.

    · Since the batch job runs once a day, it did not make sense to have dedicated worker role just loading data. Instead, we rely on a concept of “dynamic worker” within the web role job. We launch a console based data loader executable using the concept of startup tasks.

    2. A MVC2 based web application hosted on Windows Azure (co-located within the same worker) Is used to dynamically generate Open Graph API  pages (that are deemed as Facebook Pages).

    [1] A page hosted on our site that includes Open Graph tags, making it equivalent to a Facebook Page


    Today there is a lot of talk about the different cloud-based services including Infrastructure as a Service (IaaS), Software as a Service(SaaS), Platform as a Service (PaaS)and so on. While each of the aforementioned services has its unique place, in my opinion Platform as a Service (PaaS) stands out in this mix. This is not to suggest that PaaS is somehow better than, say IaaS. This would be an improper comparison. In fact, as shown in the diagram below, PaaS builds on the capabilities offered by IaaS.

    Diagram 1

    So here is my point: If you are a developer, IT shop or an ISV responsible for building, deploying and maintaining solutions, leveraging PaaS is where you reap the maximum benefits cloud computing has to offer. PaaS providers offer a comprehensive application development, runtime and hosting environment for cloud enabled applications.  PaaS simplifies the IT aspects of creating software-as-a-service applications by offering a low cost of entry, easier maintenance,  scalability and fault tolerance, enabling companies to focus on their business expertise. This is why, PaaS is seen as a game-changer in the IT world fueling innovation from the larger players including Microsoft (Windows Azure Platform), Google (Google App Engine), SalesForce (, as well as the smaller players such as Bungee Labs and Heroku .  

    APPIRIO recently conducted a State of the Public Cloud survey. What was interesting about this survey is that it focused on companies (150+ mid-to-large companies in North America) who have already adopted at least one cloud application. . The survey found that 68% of these respondents planned to have a majority of their applications in the public cloud in three years. There are two concepts to note here in the key survey finding – applications and public cloud . Let us look at each one of these concepts and how they related to PaaS:

    · Public Cloud – As we will see shortly, in order to provide economies of scale and elasticity of resources at a price that is attractive to small and medium businesses, PaaS providers need to maintain a massive infrastructure. The cost of setting up and maintaining such an infrastructure can only be justified if there are a large number of tenants. So it is no coincidence that almost all the major PaaS providers (including Windows Azure Platform) are based on the public cloud.

    · Applications – The survey respondents also indicated that they are looking to move their applications to the cloud. This is different from taking their existing on-premise servers and moving them to a public (IaaS) or a private cloud. Doing so would not allow parts of the application to take advantage of elastic resources available in the cloud. Moving the server to IaaS platform has benefits in the form of availability of elastic virtualization. However, the benefits are limited because the various parts of the application (UI tier, business tier, etc.) cannot be individually scaled. This is why it is better to migrate the application to the cloud. In order to facilitate this migration, PaaS platforms offer application building blocks that are symmetrical to the ones available on-premise. In other words, when building cloud applications, developers can still use the same development tools and programming constructs as the ones they use when building on-premise applications.

    The diagram below illustrates this concept in the context of a traditional four tier ASP.NET based web application. This application is deployed as a single virtual machine image within the on-premise data center. Moving this image to IaaS is certainly useful. It opens up the possibility to take advantage of shared pool of infrastructure resources. However, it is the PaaS platform (Windows Azure Platform in this instance) that allows each tier to scale independently. And it is not just about the elasticity in scaling (perhaps your application does not have an immediate need for it). But by mapping parts of your application to a set of pre-built application services (such as AppFabric Caching, AppFabric storage etc.) can improve fault tolerance and lower maintenance costs.

    Diagram 2

    As you can see PaaS providers are well-suited to support the two aforementioned concepts (public cloud and applications). This is why PaaS is increasingly seen as such an important development going forward.

    Let us take a deeper look at the benefits of PaaS with the aid of some concrete examples. Since I have hands-on experience with the Windows Azure Platform, I will reference its features to make the case for PaaS.

    Server VM, Network, Storage

    Even though organizations are benefiting from the advances in virtualization technology (live migration, virtualization assist processors, etc ), the overall management experience is not as seamless as they would like. These organizations have to continue to worry about creating and maintaining virtual machine images, and configuring the necessary storage and network before they can get to building and deploying their applications.

    By utilizing PaaS, virtual machines, storage and the network are pre-configured by the provider. Furthermore, the PaaS providers monitor the virtual machines for failures and initiate auto-recovery when needed.

    As far as the resources such as storage, compute and the network are concerned, PaaS-based applications can simply acquire them as needed and pay only for what they use,

    It is helpful to see the series of steps that Windows Azure platform undertakes in order to meet the needs of an application:

    · First, the application developer uploads the code (binaries) and resource requirements (# of web and middle-tier nodes, HW, memory, fire wall settings etc.);

    · Based on the resource requirements, compute and network resources are then allocated appropriately. Please refer to diagram below. Windows Azure will attempt to allocate the requested number of web-tier nodes based on the resources that are available. Furthermore, it will try to place the nodes across the different racks to improve the fault tolerance.

    · Then, Windows Azure creates appropriate virtual machine images by placing application specific code on top of base images and starts the virtual machines;

    · It then assigns dynamic IP (DIP) addresses to the machines;

    · Virtual IP addresses are allocated and mapped to DIPs; finally,

    · It sets up the load balancer to route incoming client traffic appropriately.


    The above diagram depicts a snapshot in time of available resources within a Windows Azure datacenter. Little blue boxes denote slots that are available. Windows Azure uses this information to dynamically allocate resources.

    As you can see from the above steps, Windows Azure intelligently pulls together resources to create a custom setup that meets application-specific needs (applications can operate under the impression that there is a limitless supply of resources). Note also that all through the steps above, application developers were not expected to setup the OS, log into the machines directly or worry about IP addresses, routers and storage. Instead, the application developers are free to focus on implementing the business logic.

    Patch, Service Release, New Version

    Whether they are utilizing virtualization or not, organizations have to deal with changes in the form of patches, OS upgrades, etc. This is commonly the case even if the servers are placed with a “hoster”. As we saw earlier, PaaS providers are responsible for providing the OS image. Since they are the ones providing the OS image in the first place, they are also responsible for keeping them up-to date.

    It is helpful to see how the Windows Azure platform performs OS upgrades:

    · Windows Azure team applies patches once each month.

    · In order to ensure that upgrades are performed without violating the SLA, Windows organizes the nodes that make up an application into virtual groupings called upgrade domains. Windows Azure upgrades one domain at a time – stopping all the nodes, applying the necessary patches and starting them back up.

    · By stopping only the nodes running within the current upgrade domain, Windows Azure ensures that an upgrade takes place with the least possible impact to the running service.

    · The underlying virtual machine image is not changed in this process thereby preserving any cached data.

    As a case in point, consider the recent publicly disclosed vulnerability in ASP.NET. ASP.NET-based applications hosted on Windows Azure had the vulnerability patched for them when the Guest OS was automatically upgraded from version 1.6 to version 1.7.

    Windows Azure platform recently introduced the notion of Virtual Machine (VM) role. As part of using the VM Role, users are allowed to bring their own custom virtual machine image to the cloud, instead of using an image provided by Windows Azure. This is a powerful capability that allows users to control how the virtual machine image is setup. In many ways this is akin to capability offered by IaaS platforms. But with great power comes great responsibility. Customers using the VM mode are expected to setup and maintain the OS themselves. Windows Azure does not automatically understand the health of applications running in a custom VM image.

    No Assembly Required

    Distributed applications by their very nature have a lot of moving parts and consequently a lot of steps are required to assemble the various components. For instance, assembly steps include installing and configuring caching components, access control components, database-tier components and so on.

    PaaS greatly simplifies the assembly by providing many of these application components as ready-made services.

    It is helpful to consider a few examples of application building block services offered by the Windows Azure platform:

    Azure App Fabric Caching – This is a distributed in-memory cache for applications running in Windows Azure. Application developers do not need to bother with configuration, deployment or management of their cache. Applications simply provision the cache based on their needs (with the ability to dynamically adjust capacity), and only pay for what they use.

    AppFabric Access Control Service – This service simplifies access control for applications hosted in Windows Azure. Instead of having to handle different access control schemes (OAuth, OpenID etc.), Windows Azure-based application can integrate with AppFabric Access Control. AppFabric Access Control service in turn brokers the integration with various access control schemes thereby greatly simplifying the task of application developers.

    SQL Azure Service – This is a cloud-based relational database service available to applications hosted on Windows Azure. Application developers do not have to install, setup, patch or manage any software. High availability and fault tolerance is built-in and no physical administration is required.

    There are two noteworthy things about the examples above. First, each of the aforementioned services has a corresponding on-premise equivalent. This is what makes it possible for developers to migrate their applications to the cloud. Second, even though these services are functionally and semantically equivalent, they exhibit the core characteristics of the cloud, namely elasticity and fault tolerance. To be specific, let us consider the SQL Azure service. SQL Azure supports most the T-SQL functionality available on SQL Server that is running on premise. However, SQL Azure has built-in fault tolerance (it keeps multiple copies of the database in the background) and elasticity (databases can be scaled out seamlessly). Additionally, there is no need to go though the typical setup steps such as installing the product, applying patches andsetting up back-up and recovery. Setting up a SQL Azure database is literally a matter of issuing a “create database” command.


    In this post, we saw how PaaS providers offer a comprehensive application development, runtime and hosting environment for cloud enabled applications.  This greatly simplifies the IT aspects of creating software-as-a-service applications enabling companies to focus on their business expertise.