Hybrigation Complete, Feedback Required...

So at last we've finished the Windows Azure hybrid applications guide, and it's out there ready for anyone interested in integrating cloud-hosted applications with on-premises services and partner applications. OK, so it's taken a little longer than originally planned but it is more comprehensive than originally envisaged, and incorporates a great deal of input from teams inside Microsoft, and advisors and reviewers outside the company.

One thing we discovered is that hybrid application integration (which I'm still resolutely referring to as "hybrigation") is a more complicated topic than we originally imagined. Not that it's hard to do - the tools and services in Windows Azure make the implementation really easy - but deciding how to approach it and which technology to use seem to be the key factors that contribute to a successful outcome.

We originally defined seven areas of concern for hybrigation, and concentrated on providing guidance on each one. These topic areas are:

• Deploying functionality and data to the cloud. It is likely that you will need to modify the code in your existing on-premises applications to some extent before it, and the data it uses, can be deployed to the cloud. At a minimum you will need to modify the configuration, and you may also need to refactor the code so that it runs in the appropriate combination of Windows Azure web and worker roles. You must also consider how you will deploy data to the cloud; and handle applications that, for a variety of reasons, may not be suitable for deploying to Windows Azure web and worker roles.

• Authenticating users and authorizing requests. Most applications will need to authenticate and authorize visitors, customers, or partners at some stage of the process. Traditionally, authentication was carried out against a local application-specific store of user details, but increasingly users expect applications to allow them to use more universal credentials; for example, existing accounts with social network identity providers such as Windows Live® ID, Google, Facebook, and Open ID. Alternatively, the application may need to authenticate using accounts defined within the corporate domain to allow single sign on or to support federated identity with partners.

• Cross-boundary communication and service access. Many operations performed in hybrid applications must cross the boundary between on-premises applications, partner organizations, and applications hosted in Windows Azure. Service calls and messages must be able to pass through firewalls and Network Address Translation (NAT) routers without compromising on-premises security. The communication mechanisms must work well over the Internet and compensate for lower bandwidth, higher latency, and less reliable connectivity. They must also protect the contents of messages, authenticate senders, and protect the services and endpoints from Denial of Service (DoS) attacks.

• Business logic and message routing. Many hybrid applications must process business rules or workflows that contain conditional tests, and which result in different actions based on the results of evaluating these rules. For example, an application may need to update a database, send the order to the appropriate transport and warehouse partner, perform auditing operations on the content of the order (such as checking the customer's credit limit), and store the order in another database for accounting purposes. These operations may involve services and resources located both in the cloud and on-premises.

• Data synchronization. Hybrid applications that run partly on-premises and partly in the cloud, run in the cloud and use on-premises data, or run wholly in the cloud but in more than one datacenter, must synchronize and replicate data between locations and across network boundaries. This may involve synchronizing only some rows and columns, and you may also want to perform translations on the data.

• Scalability, performance, and availability. While cloud platforms provide scalability and reliability, the division of parts of the application across the cloud/on-premises boundary may cause performance issues. Bandwidth limitations, the use of chatty interfaces, and the possibility of throttling in Windows Azure may necessitate caching data at appropriate locations, deploying additional instances of the cloud-based parts of the application to handle varying load and to protect against transient network problems, and providing instances that are close to the users to minimize response times.

• Monitoring and management. Companies must be able to effectively manage their remote cloud-hosted applications, monitor the day-to-day operation of these applications, and have access to logging and auditing data. They must also be able to configure, upgrade, and administer the applications, just as they would if the applications were running in an on-premises datacenter. Companies also need to obtain relevant and timely business information from their applications to ensure that they are meeting current requirements such as Service Level Agreements (SLAs), and to plan for the future.

So our first task was to investigate each of these areas and create good practice guidance around the scenarios and use cases for each one, then complement these with descriptions and detailed implementation information for the appropriate technologies that can satisfy the use cases in a variety of scenarios.

However, at the same time we wanted to provide a realistic example application that demonstrates as many of these technologies as possible (and without too cumbersome setup requirements). And it soon became clear that the decisions we made when designing and building the application would be of considerable use to readers, as well as the description we include of the code our development team created.

The result, therefore, is that our guide has two distinct sections. The first is a description of the fictional company and the application they (we) built, including the design decisions and implementation details. The second section is a series of use cases, and relevant high-level solutions, for each of the main areas of hybrigation concern. This section provides more information about where and how you might apply the Windows Azure integration technologies in your own applications.

And the nice thing is that there is a direct mapping between each of the chapters in the first section and the corresponding area of concern and appendix in the second section. It somehow feels like we really did get it right! Of course, its the readers and users of the guide that will provide the final confirmation (or otherwise) of this.

So now it's over to you: please tell us what you think of the guide, and which areas and sections you found the most or least beneficial. Did we hit the target? What makes it useful, and what should we have killed off during the final edit process? And, most important of all, what did we miss out that would have made it even better?

You can comment directly on this blog, or send me email using the link at the top of the page...