Developing applications for a hybrid cloud deployment isn't a black art, but it is something of a mystery to many enterprises.
It's likely that any user who contemplates one hybrid cloud development will end up doing many such projects, so it's smart to develop a strategy that can be applied to all the projects, then test it out on a modest hybrid deployment first. To succeed, such a strategy must consider the hybrid cloud application mission, the reason for hybrid cloud use, and the critical interplay between hybrid operation and quality of experience (QoE).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Among the worst mistakes cloud-application planners can make is considering such technical issues as hybridization, integration or cloud platform selection without first setting the context for the application itself. Application design is always driven primarily by the mission, not the technology -- but the mission statement has to properly blend business issues and technical requirements.
The many facets of cloud applications
Applications can be classified multi-dimensionally. They can be transactional or involve information delivery (first dimension). They can be mobile, as opposed to being based on the desktop (second dimension). Finally, they can be session- or instance-based (third dimension). In all these dimensions, the first option demands more design attention than the second.
In the first dimension, transactional applications are ones that record or change information, which means that they must be reliable in how they interact with their associated databases to avoid risking data corruption. That increased reliability requirement means that the public cloud components of hybrid applications must be reliable, or special programming measures (two-phase commit, for example) must be adopted to protect data integrity. If you're using the hybrid cloud in cloudbursting or failover applications, transactional apps need to maintain data integrity during any scale-in or -out, or failover activity as well.
Application design is always driven primarily by the mission, not the technology.
In contrast, information-delivery applications are tolerant of failures or changes in response time; users will repeat a request for the information if the first request is lost. That means that such simple techniques as load balancing front ends will support elastic scaling of applications and shifting of work between the public cloud and the data center.
In the second dimension, mobility creates special concerns in two ways. First, mobile connections are made through wireless networks that are usually less reliable than desktop connections. This will exacerbate issues of data integrity in transactional applications. Mobile users may also work in multiple and variable geographies, which can create significant performance differences if the public cloud service is offered out of a single data center. If users are widely separated, look for providers with regional hosting.
The issue of session- or instance-based applications (the third dimension) refers to whether a user will be engaged in a long, multi-step interaction with the application, as opposed to a single, short-duration one. Collaboration is an example of a session-based interaction, where simply processing a credit card purchase is an example of an instance-based application.
In application design, there's a tendency to author software for session-oriented applications to depend on a reliable, consistent connection throughout -- what's called stateful behavior. Most instance-oriented applications are written as Web applications are, without internal expectations of maintaining the context of a multiphase conversation with a user (these are called REpresentational State Transfer or stateful applications). Stateful applications are much more difficult to hybridize because the application will lose knowledge of an in-process user activity if a component cloudbursts or fails over into the cloud.
The reason for hybridization can be either dynamic component scheduling or front-ending existing applications with cloud components. Dynamic scheduling means allocating resources in the cloud or in the data center to application components based on workload or whether a resource has failed.
Front-ending hybrid applications build a Web-like experience between the user and the rest of the application, taking advantage of the public cloud to scale these components or move them geographically depending on where users are located. Front-ending creates a consistent model of hybridization -- components are always either in the cloud or the data center -- so it's easy to design for. Where dynamic movement of components is required, all the issues of insuring consistent user experiences and database integrity will apply.
Ensuring high-quality user experience
Consistency of user experience is the most challenging of all hybrid cloud design issues, in part because it's both the most subjective and most variable. Public-cloud QoE can vary significantly depending on where users are located in relation to the cloud-hosting point, where the cloud hosting is located relative to the data-center components, and what the quality of connectivity is in all these places.
Quality of Experience issues in hybrid cloud applications are most easily addressed by using availability zones to manage the location where hosting takes place (ensuring that users are never too far from cloud-hosted components) and by ensuring that cloudbursting or failover dynamic scheduling doesn't create application errors that can introduce delays in stateful behavior for transactional applications.
A final point in hybrid cloud application design is the role of the client device and any local software hosted there. On-client software can manage the user-to-application interaction to prevent users from creating multiple updates by resubmitting requests when QoE is poor. It can also help to resynchronize application sessions or transactions during cloudbursting or failover.
If the majority of the design issues presented above are relevant to your own hybrid cloud application, you may want to consider specializing a device application to complement the rest of the cloud application. Doing that, in turn, will improve stability and user satisfaction.