In my previous posting I outlined a number of thoughts, considerations and technical options for building hybrid-cloud solutions. This types of applications and services operate and run assets on public cloud platforms such as Windows Azure while keeping other assets in private data centers on-premises. That way such kinds of solutions enable you to leverage the benefits of public cloud platforms while at the same time keeping assets you cannot or do not want to move to a public cloud on-premises in your own data center.
The Windows Azure Platform offers a strong set of services and capabilities that do enable hybrid cloud scenarios. These platform-services do enable an effective and efficient integration of assets running in the public cloud with assets you keep on-premises. Some of these options do even enable this integration without storing data you cannot or do not want to store in the cloud, at all. In the mind-map I’ve published through my last posting, the most important of these services are summarized and outlined.
With this posting it’s time to get more specific. Together with one of my peers from Microsoft consulting services Western Europe, Andy Rynes, I’ve been thinking about an easy-to-understand yet comprehensive scenario to outline the possibilities, options and applications of the concepts I’ve outlined in the previous posting supplemented by dynamic private cloud management concepts. Explaining the architecture and application of hybrid cloud integration-points is subject of this posting so that you get a practical understanding based on a true scenario.
Online Shop with integrated Payment and Account Management
Consider a typical architecture for an online-shopping system if you would design it for being operated in your own data center on-premises! Typically (and simplified) such a system includes the following components and services:
The following figure summarizes, how these assets are combined in the simplified architecture I use for ongoing discussions in this and future posts.
Note: the figure above does not specify the means of communication between the the web front-ends accessed through the browser and the services. But let’s assume the following practical and realistic assumptions:
Hybrid-scenario – Assets to be moved to the cloud and to keep on-premises
It is obvious that a web shop including its order processing can benefit from characteristics of public cloud platforms such as elastic scalability. These assets of such a solution can definitely benefit from time-bound increase of resources during busy shopping seasons such as Christmas while at the same time do not need a lot of resources during seasons with less shopping-activity such as summer holiday season.
On the other hand in many countries personal billing and payment information are treated as very sensitive. Therefore in some scenarios you might want or have to keep them on-premises in your own data center.
Finally this situation leads to a hybrid cloud scenario where you definitely benefit from putting the assets of the front-end web shop including the order processing in the cloud while leaving your payment and billing account management services on-premises in your own data center. Based on the assumption above this simple scenario leads to two different integration steps from assets hosted in the public cloud to on-premises operated assets:
Updating the architecture diagram based on the knowledge and approaches outlined above will result in the following refined architecture for our hybrid solution:
As you can see, the (apparently) “sensitive” information and data such as credit cards, billing etc. stays on-premises in your own data centers. For the interactive use case the connection from the public cloud is relayed through Azure service bus relay bindings to the on-premises hosted account management service. In this case the account management service connects from inside out to the service bus to offer its endpoint to other parties authenticated to the same service bus namespace. If you provide those service bus namespace and credentials to the shop-front-end as the only party, no one else will be able to connect to this account management service.
Furthermore payments are just stored as encrypted messages on Azure queue. A little adapter application / service that runs on-premises queries this Azure queue in regular intervals to retrieve payment messages and forward them to the actual payment service. A public key is used in the cloud to encrypt messages before they’re put onto the queue. The corresponding private queue is used by the application that monitors the Azure queue for new payment messages to decrypt the payment messages and forward them to the payment service. That way even the payment message that might contain sensitive data is stored in the cloud without having the option of decrypting the message in the cloud. In addition the data is stored temporarily, only, as the messages are deleted from the queue as soon as they’ve been processed on-premises.
Unleash the full power – on-premises and public cloud unified
Of course it would be really neat if some of the concepts such as dynamic provisioning in case of increased load could also be applied to your on-premises world. In addition having a management solution that allows you to manage both, the cloud and on-premises assets through one, unified tool and infrastructure is an important aspect. That is were you need to take aspects of private cloud into consideration to treat the scenario above as comprehensive and really understand your full potential of possibilities and opportunities.
I’ll definitely will demonstrate the concepts outlined above with a practical example in one of the next posts in February-timeframe to equip you with a practical example on hybrid cloud solutions.
In addition I think Andy will pick up my post to equip you with details with regards to the architecture of a private cloud infrastructures. This will finally fill the gap and shows you, how to implement dynamic operations efficiency across public and private cloud using the Windows Azure Platform and the on-premises Windows Server and System Center 2012 platform.