In the past two months several of our partners and customers confronted me with the topic “hybrid cloud”. Seems that due to my experience from the last 2 years in a sensitive public sector organization as an enterprise architect people think about me as a hybrid cloud expert. Well, I am starting to be one because I am really spending a whole lot of my time thinking about this topic. First thing I want to publish is a mind map with some thoughts that I typically tend to take into consideration when it comes to hybrid cloud.

Hybrid Cloud - Thoughts - Large

Many people indeed tend to think about either cloud or on-premises but not both. Hybrid solutions are all about combining on-premises with cloud-based services. That way a hybrid solution keeps parts of the solution on-premises, moves other parts into public clouds and integrates those. Integration typically happens through mechanisms offered by either the public cloud, your on-premises platform or both. That way you can leverage benefits of public clouds whenever applicable such as the following:

  • elasticity, pay-per-use etc.
  • save costs through more efficient operations
  • increase your visibility
  • extend your business by growing into markets that cannot be reached with on-premises solutions, easily

Of course typical perceived reasons used as arguments for keeping assets on-premises are the obvious suspects: legal compliance, data protection and security are often mentioned as arguments for keeping (parts of) solutions on-premises. In addition, very often existing investments done and depreciation of existing assets are typical reasons for keeping parts of solutions on-premises. Whatever reasons and arguments are used, there will always be good opportunities to leverage the benefits of public clouds in some way. Typical examples are:

  • Web front-ends that do require scale. These can be moved into the cloud while at the same time keeping other parts perceived as more sensitive in on-premises data centers.
  • Providing additional services to a broader audience on-top of existing services. These new services definitely can be integrated with your existing services and they can absolutely be operated in a public cloud if it makes sense. Of course such new services operated in the cloud can call on-premises services through whatever mechanism.

Windows Azure indeed provides technologies and mechanisms for integrating services and applications operated on-premises with other services and applications operated in the cloud. I’ve summarized the most important options on Windows Azure in the mind map published as part of this posting (see image above and link at the end of the posting). The mind map summarizes a few core-questions you should ask yourselves to decide, which technique and technology to use for integrating on-premises services and applications with those operated in public clouds:

  • Is it legally possible and technically feasible to store data in the cloud or not?
    • If yes then Azure storage can be used from both, on-premises and cloud services for integration purposes.
    • Of course it is also possible to store data encrypted in cloud storage. This can be achieved by having e.g. a public key that allows cloud services to encrypt data while having the private key on-premises for decryption. Today this needs to be part of your implementation, but there might be features available in the future in Windows Azure to ease this task.
    • If storing data temporarily is possible and feasible, then Azure Queues or Service Bus Topics/Queues can be used for integration purposes.
    • If storing data temporarily is not possible or feasible, then using Azure Service Bus Relay communication is an option. In this case a communication-channel is relayed from the cloud to on-premises without any persistent or durable storage involved. This is similar to an ordinary web services call.
    • Last-but-not-least opening up the firewall ports to on-premises services with appropriate IP address restrictions to IP addresses of cloud services is an option. With in-place upgrades in Windows Azure, IP addresses are remained for your cloud-service therefore making this option easier. But in my opinion the Service Bus relay allows a better targeted exposure as (a) both, consumer and provider need to authenticate against service bus, (b) the consumer always needs to authenticate to the provider as usual and (c) the provider as full control of when to expose its functionality through service bus as part of its implementation. The last point (c) indeed is a very attractive choice!!
  • Which users must be used for authentication?
    • If the on-premises user-base must be used in the public cloud then there is a set of subsequent questions to ask:
      • Are the on-premises users in Active Directory? If yes, ADFS 2.0 is the primary option to integrate the on-premises user base with applications operated in the public cloud.
      • Are the on-premises users in a custom DB? If so it gets more tricky.
        • One option is a synchronization of the user DB from on-premises to cloud-based databases by using SQL Azure Data Sync.
        • If the user store must remain on-premises, then synchronization is not an option! So you must expose the authentication service somehow to your cloud-services. Well, again, writing a little wrapper-service around existing authentication APIs and exposing it via Service Bus Relay bindings to cloud services is an option. This exposed service can than be used for authenticating users in applications operated in the public cloud.
    • The Azure Access Control Service can provide a “unification” mechanism to authenticate both, on-premises users (through WS-Federation integration between ACS and ADFS 2.0, for example) and other users (any STS integrated via WS-Fed or the additional, already integrated providers such as Facebook, Yahoo, Google or Live ID).
      • This enables you to focus on one single authentication API and mechanism in your application. You only need to be able to process WS-Federation requests/responses and SAML tokens. And at the same time it opens up the option of integrating with a variety of identity providers incl. Facebook, Google, Yahoo, Windows Live and any other identity provider supporting WS-Federation and SAML tokens.
      • Of course you need to implement applications in a way that it is failure-tolerant with regards to claims delivered or not delivered in tokens. This is required as depending against which authentication provider ACS authenticated the user to a different set of claims will be delivered. E.g. a web application that requires the email address can take the email address from the SAML token issued if it is available in the token. In turn if the email address is not available in the token (because it was not issued by the authentication provider), the application needs to ask the user for the email address. That is fairly important to understand as neither your application nor ACS can force an identity provider to issue certain information in the token. The only attribute that is definitely included into the token is a unique name identifier claim that you can use in your database as primary key for associating your records with a user in a loosely coupled way.
  • The other aspects included in the mind map are less “critical” . E.g. calling a cloud service running in Azure from an on-premises service for integration-purposes is fairly simple and in no way different to calling any other service hosted somewhere else in the Internet. Only authentication from the on-premises service against the cloud-based service is tricky. Again ACS can be used in such cases to manage service credentials for cloud-based services. These are then used from on-premises to authenticate against a service hosted in Windows Azure by using ACS.

As you can see there are many options available that enable hybrid solutions with Windows Azure and therefore enable YOU to leverage the cloud whenever useful and beneficial for your solution while at the same time keeping solution assets on-premises that cannot be moved to a public cloud…

Finally, here’s the full mind-map integrated from XMind:

(thanks to Peter Koen for his help to fine-tune the article and re-publish a more concise version)