By now, you've probably figured out that the name of the game at Microsoft is cloud—they are all in. Teams at Microsoft that once focused exclusively on building products for on-premises use are now being asked to cloud-enable them or build new, symmetric cloud functionality. This begs several questions: Are you still looking at your Windows Communication Foundation (WCF) service-based applications as on-premises solutions? Have you built and hosted any services on Windows Azure? More to the point, have you considered hybrid architectures where you have both on-premises and cloud-hosted services? If not, this article will help you start thinking about hybrid solution architectures.
Hybrid Application Architecture
As Figure 1 shows, services can live any many places, such as on-premises and hosted in Microsoft IIS with Windows Server AppFabric, or in the cloud hosted within a web, worker, or VM role.
Figure 1: An overview of a hybrid application architecture
However, the clients—except for the most traditional corporate desktop applications—do not live exclusively on-premises or in the cloud. Some users may connect to your applications via laptops or smartphones across the Internet. Because of this connectivity from the Internet, you are less likely to offer solutions where such clients connect directly to your on-premises applications. There are many good reasons for this, but the typical reasons are to leverage cloud services for scale and minimize the traffic and demand against your on-premises components, as well as to decouple clients from hard-coded knowledge of the location of your on-premises components, so that you can move them around as needed.
There are also alternative considerations in a hybrid application design with respect to the placement of your on-premises services. For example, you might have regulations that require you to host the data within specific physical confines (for example, within your corporation or within your country). Additionally, cost or uptime may be factors. In some scenarios, it may be more cost effective to maintain your on-premises data center, or it may be the only way to deliver an SLA of 99.999 percent uptime.
We will return to Figure 1 many times though this article. However, at a high level, as we explore this form of hybrid architecture, we have three main concerns: how all clients, on-premises components, and cloud-hosted components communicate; how to provide access to the data that those components need; and how to secure access to the components and the data. Along the way, we will introduce the functionality of existing Azure services as well as recently announced ones.
Communication
When extending the reach of your application out into the cloud, there are two important questions to ask: How will your on-premises and Azure-hosted components communicate, and how do you expect clients to communicate with your Azure-hosted components and with your on-premises components?
Cloud communication. When connecting your on-premises services with services that are hosted in Azure, you have three options: Your on-premises solutions can communicate directly to the Azure hosted services making SOAP-style or REST-style calls, they can establish a link across the Azure AppFabric Service Bus, or they can leverage the VPN-like connectivity of Windows Azure Connect. Each approach has different value propositions and important considerations, so we will briefly review each.
Communicating via direct SOAP and REST calls. In this scenario, your on-premises services become clients of WCF services hosted in Azure. This scenario is not much different from how you would build two on-premises services that communicate with each other across the same LAN. The challenge with this approach surfaces when considering how the Azure-hosted services will call back to your on-premises services. This complication is introduced by firewalls and other forms of Network Address Translation (NAT) that likely already protect your on-premises network environment from external access. You could go about "poking holes" in your firewall configuration to allow direct external access to your on-premises services, but doing so greatly diminishes your network's security and introduces a new IT management burden every time you introduce a new or reconfigure an existing on-premises service. Fortunately, for service-to-service communication, Azure provides an elegant solution in the Service Bus.
Communicating via the Service Bus. The Azure AppFabric Service Bus was designed to enable on-premises services to open a public endpoint on Azure that can be used to communicate back to the actual service hosted on-premises, while transparently navigating any firewalls that may appear along the way. As suggested by Figure 1, by using the Service Bus, your on-premises services open an endpoint that your Windows Azure hosted services can use to communicate with them. This provides quite a few benefits. First, the actual address of your on-premises service is known only to the Service Bus and is not made available to your Azure-hosted services (or to other clients, for that matter). This means you can, for example, change the IP address of your on-premises services without having to propagate the change to all clients. As soon as your on-premises services open a Service Bus endpoint, the Service Bus will have the updated information and will route accordingly.
An interesting feature of the Service Bus is that it can also detect when both the client and the service are on the same LAN, as might be the case when an internal user launches a client on the same network as your on-premises service. In this scenario, the Service Bus will dynamically upgrade the services to a direct link, which excises the hop out to the cloud and can greatly improve throughput.
There are two caveats to be aware of with the Service Bus. First, it works only for your WCF services (for example, it can't route access for shared network drives). Second, while it might seem like the ideal way for all clients to connect to your on-premises services, the Service Bus is charged for according to the number of concurrent connections, and these are $2 to $4 each, depending on how many you buy upfront. Because of this, you will want to position the Service Bus in the middle tier, much like you would a shared VPN, to your on-premises services from your Azure-hosted services and not allow an unlimited number of clients to connect this way.
Communicating via Windows Azure Connect. What if you need to flow more than service calls between your on-premises and Azure-hosted services? For example, what if your services need to communicate with your on-premises Active Directory (AD) or SQL Server? Or, what if your services need to access a network share? Windows Azure Connect offers an IP-level, secured, VPN-like connection from your Windows Azure hosted roles to your on-premises services. What's more, Windows Azure Connect can enable you to access your Azure role instances, much like accessing remote systems across a VPN. As of this writing, pricing for Windows Azure Connect has not been announced. However, you will want to use pricing as a mechanism for your roles to communicate back to the on-premises services in a controlled fashion, as it is not likely to be cost effective to allow unlimited clients to create such connections.
Client Communication
Given the previous analysis, when considering how clients will access functionality or data from your on-premises services, the option is typically to enable the clients to talk to your Azure role hosted services directly, and the Azure hosted services relay the request to your on-premises services, as appropriate. In certain scenarios with limited clients, it may be appropriate to allow clients to use the Service Bus directly to call back to your on-premises services.
Data Access
When examining a hybrid application, your architecture may now involve storing data on-premises and in the cloud. On-premises, these data stores might be network shares, SQL Server databases, or directories like AD. In the cloud, these might be Windows Azure's Blob, Table, or Queue stores; the local storage of the role instance; or SQL Azure. For the latter, your application design may choose to allow clients direct access to the data or restrict access so that it occurs only through services hosted in Azure roles.
It is important to address the fact that the locality of the data, relative to the service, affects both performance and cost. For example, if your services must access data from SQL Server on-premises, you would incur the cost of using Service Bus to your on-premises service, plus the cost of the data transferred. This data request to the on-premises service is also significantly slower than if the data were hosted near the Azure hosted service. So, what can increase performance and also reduce costs? Caching.
Caching Data Access
A newly added feature to the Windows Azure AppFabric feature set gives you the same in-memory, high-performance distributed cache that was available to you on-premises with Windows Server AppFabric, but it is provided to you as a hosted service. The Azure AppFabric Cache frees you from the responsibility of managing additional role instances in your architecture that are responsible for caching data. This enables you to have a shared cache available to all your services without requiring sticky client sessions, where a client must remain connected to the first server that it connected to. By leveraging the cache in your architecture, you can prevent trips to your on-premises data stores. This reduces the connection and transfer costs and improves the performance because cache access to your Azure roles happens at local network speeds. The cache also helps with accessing other Azure stores. For example, you can minimize the load on your SQL Azure instances by caching frequently requested data, and you can minimize costs on Azure storage (which is billed in units of I/Os) in the same way.
Security
You may have noticed in Figure 1 that all the components have a padlock on them. Ultimately, this is because all of these components require some form of authentication and authorization to control access to the resources they represent. In a hybrid architecture, the complexity of the security architecture can quickly spiral out of control, which is beyond the scope of this article. However, there are a few useful features that you should consider in your architecture to simplify things.
The crux of the security model is made simple by the Access Control Service (ACS). With simple configuration, the ACS can take a client's credentials (such as a Google, Yahoo, LiveID, or a simple username/password) and issue authentication tokens that downstream services, such as the Service Bus and the Azure AppFabric Cache, can use to authorize access. You can also build your Azure-hosted and on-premises WCF services with Windows Identity Foundation and thereby control access to them by inspecting ACS-issued tokens.
SQL Azure and Windows Azure storage have slightly different authorization models. SQL Azure requires that clients be allowed to connect through the SQL Azure Firewall. This restriction is made by IP address for all non-Azure clients and is an enabled/disabled option for Azure hosted services. The ramification for hybrid architectures is that your on-premises components must dial in from an IP address that is registered with the SQL Azure firewall if they are to make direct calls to it. After a client is past the SQL Azure Firewall, it must still present a valid SQL login and password, as you might have to on-premises. Note that SQL Azure does not support Windows Integrated authentication.
Windows Azure Storage requires that clients include an account name and key pair with every request. As long at this pair is presented, any client can connect regardless of whether it is an on-premises service, an actual client, or another Azure hosted service.
Moving Forward with Hybrid Application Architectures
Hopefully, this article got your gears turning about how you can start building hybrid applications that go beyond being purely on-premises or purely cloud-hosted, and it provided useful insights into how you facilitate communication, facilitate data access, and enable security across the whole distributed system.
Zoiner Tejada ([email protected]) is the president of TejadaNET, is recognized as a Microsoft Industry Influencer, and is an advisor to Microsoft's Connected Systems Division. Zoiner has a degree in computer science from Stanford University and blogs at www.theworkflowelement.com.
Additional References
The following links provide detailed information that can help you implement the architecture that is described in this article:
• For information about Windows Azure, SQL Azure, and Azure AppFabric, see the article "Windows Azure Platform Training Course".
• Find information about SQL Azure Labs.
• Find information about Service Bus.
• Find information about Access Control Service.
• Watch a Windows Azure Connect Talk at PDC 10.
• Watch an Azure AppFabric Cache Talk at PDC 10.
• Watch an Identity and Access Control in the Cloud Talk at PDC 10.
