For those looking to create a new Cloud system with an on-premises/alternate host component. Or possibly you are looking at migrating an application to the cloud but you have to have some piece of the system on-premises. There are options. Even though Microsoft’s approach to the cloud was “we’re all in” that does not mean that your system has to be “all into” Azure.
When integrating to an Azure application you have a number of options, choosing the best one means understanding what is involved in these options.
Here is a graphic which outlines the 4 main options for integrating with Azure.
From the top.
1. Data Synchronization
This form of integration propagates changes made on one database to another, and vise-versa. You can even setup a data hub system to sync 3 or more databases with each other. This is commonly used in situations where an application is too large for a single location or has a remote data cache. For example channel9.com which is hosted on Windows Azure, uses Data Sync and Traffic Manager to host multiple versions of their applications across the globe. Comments made in Europe and Asia can take up to 1 hour to Sync to the US datacenters and viewed by those accessing the site from the US.
This form of integration is performed by the SQL Azure Data Sync service. One of the databases (called the hub database) has to be a SQL Azure database. If you want to sync more than one on-premises database together it has to go through the hub. Periodically, the databases are queried for changes and those changes are made to the other databases.
Data Sync is a very effective integration pattern because it can greatly reduce load on your datacenter and does not require any external endpoints, the database connects to the hub using Windows Azure Connect (number 3 on the list) the load on your local database is very controlled.
2. Application Layer
Application layer integration is very common. In fact it is widely used on multi-tiered applications to improve overall performance. 3rd party frameworks like nServiceBus and BizTalk can provide scalable, flexible solutions to help multiple systems communicate with each other.
To take the service bus concept to Azure you have 2 main options both provided by the Windows Azure AppFabric Service Bus. Relay Messaging and Queue Messaging. Relay Messaging provides a real-time connection between two or more components to allow request-response calls which traverse network boundaries. This feature is crucial for those applications that require immediate feedback from connected business logic. Queue Messaging is a persisted, transactional message system that was added to Azure Service Bus later. This feature is similar to Azure Storage Queues, the key difference being that Service Bus Queues are guaranteed ordered, transactional, and other features making them the better choice for enterprise level integration. This messaging scheme is used for a variety of patterns like pub-sub. Queue Topics can also be used to split the message stream into filtered subsets or duplicate entries picked up by different subscribers. Azure Service Bus is a very flexible service, providing a number of Application Layer integration solutions.
To be continued…
This is the end of part 1. In part 2 I will go into Azure Connect and Virtual Networks.
Thanks for reading.