Foreword by Clemens Vasters

The first platform-as-a-service cloud capabilities to be released by Microsoft as a technical preview were announced on May 31, 2006 in form of the "Live Labs" Relay and Security Token services (see https://blogs.msdn.com/b/labsrelay/archive/2006/05/31/612288.aspx), well ahead of the compute, storage, and networking capabilities that are the foundation of the Microsoft Azure platform. In the intervening years, these two services have changed names a few times and have grown significantly, both in terms of capabilities and most certainly in robustness, but the mission and course set almost six years ago for the Azure Service Bus and the Azure Access Control Service has remained steady: Enable Hybrid Solutions.

We strongly believe that our cloud platform – and also those that our competitors run – provides businesses with a very attractive alternative to building and operating their own datacenter capacity. We believe that the overall costs for customers are lower, and that the model binds less capital. We also believe that Microsoft can secure, run, and manage Microsoft's server operating systems, runtime, and storage platforms better than anyone else. And we do believe that the platform we run is more than ready for key business workloads. But that's not enough.

From the start, the Microsoft cloud platform, and especially the Service Bus and Access Control services, was built recognizing that "moving to the cloud" is a gradual process and that many workloads will, in fact, never move into the cloud. Some services are bound to a certain location or a person. If you want to print a document, the end result will have to be a physical piece of paper in someone's hand. If you want to ring an alarm to notify a person, you had better do so on a device where that person will hear it. And other services won't "move to the cloud" because they are subjectively or objectively "perfectly fine" in the datacenter facilities and on their owner's existing hardware – or they won't move because regulatory or policy constraints make that difficult, or even impossible.

However, we did, and still do, anticipate that the cloud value proposition is interesting for corporations that have both feet solidly on the ground in their own datacenters. Take the insurance business as an example. Insurance companies were some of the earliest adopters of Information Technology. It wouldn't be entirely inaccurate to call insurance companies (and banks) "datacenters with a consumer service counter." Because IT is at the very heart of their business operations (and has been there for decades) and because business operations fall flat on the floor when that heart stops beating, many of them run core workloads that are very mature; and these workloads run on systems that are just as mature and have earned their trust.

Walking into that environment with a cloud value proposition is going to be a fairly sobering experience for a young, enthusiastic, and energetic salesperson. Or will it be? It turns out that there are great opportunities for leveraging the undeniable flexibility of cloud environments, even if none of the core workloads are agile and need to stay put. Insurance companies spend quite a bit of energy (and money) on client acquisition, and some of them are continuously present and surround us with advertising. With the availability of cloud computing, it's difficult to justify building up dedicated on-premises hardware capacity to run the website for a marketing campaign – if it weren't for the nagging problem that the website also needs to deliver a rate-quote that needs to be calculated by the core backend system and, ideally, can close the deal right away.

But that nagging problem would not be a problem if the marketing solution was "hybrid" and could span cloud and the on-premises assets. Which is exactly why we've built what we started building six years ago.

A hybrid application is one where the marketing website scales up and runs in the cloud environment, and where the high-value, high-touch customer interactions can still securely connect and send messages to the core backend systems and run a transaction. We built Azure Service Bus and the "Service Bus Connect" capabilities of BizTalk Server for just this scenario. And for scenarios involving existing workloads, we offer the capabilities of the Azure Connect VPN technology.

Hybrid applications are also those where data is spread across multiple sites (for the same reasons as cited above) and is replicated and updated into and through the cloud. This is the domain of SQL Azure Data Sync. And as workloads get distributed across on-premises sites and cloud applications beyond the realms of common security boundaries, a complementary complexity becomes the management and federation of identities across these different realms. Azure Access Control Service provides the solution to this complexity by enabling access to the distributed parts of the system based on a harmonized notion of identity.  

This guide provides in-depth guidance on how to architect and build hybrid solutions on and with the Azure technology platform. It represents the hard work of a dedicated team who collected good practice advice from the Azure product teams and, even more importantly, from real-world customer projects. We all hope that you will find this guide helpful as you build your own hybrid solutions.

Thank you for using Microsoft Azure!

Clemens Vasters

Principal Technical Lead and Architect

Microsoft Azure Service Bus

Next Topic | Previous Topic | Home

Last built: June 4, 2012