This content is part of the Essential Guide: Essential guide to cloud management

Understanding hybrid cloud workflow management

Working with hybrid clouds requires proper planning. Tom Nolle explains what cloud planners need to know about hybrid cloud integration and workflows.

Before diving head-first into hybrid cloud computing, there are certain things cloud planners need to understand in order to effectively utilize hybrid clouds within their organization.

In this tip, we explore essential ideas and strategies cloud planners should keep in mind when it comes to hybrid cloud workflow management and integration, including understanding the four major driving forces of hybridization.

Almost all enterprises believe they'll be customers for public cloud computing, and, on at least a small scale, most are there already. Most also believe they'll have in-house data centers even in the far future. Hybrid clouds, then, are less a cloud choice than a cloud consequence, and cloud planners have to understand the forces of hybridization, frame a hybrid cloud strategy that integrates what hybrid clouds separate, and manage workflows for an increasingly dynamic future.

If we accept (as we should) enterprise assertions that they are committed to data centers in the long term, then hybrid cloud requirements arise because public cloud services supplement these data centers in a variety of ways. There are four specific hybridizing forces at work:

  • Server consolidation, a trend that has been a driver for virtualization, can be taken even further if the low-utilization application-specific servers can also be hosted in a public cloud. For very low utilization levels and where the same application is run in multiple, widely separated, satellite locations, the cloud is a better choice.
  • Cloudbursting for scaling capacity to match needs and to replace failed components.Companies are recognizing that public clouds can augment internal IT resources under extreme conditions, if the applications are designed to support this goal.
  • As-a-service application purchases by line departments. While few line organizations are prepared to rush out and manage IaaS deployments of their applications, most say they'd be happy to buy at least some applications in as-a-service form. This is the trend that creates the often-discussed "shadow IT," where companies have applications the CIO doesn't know about until someone presents them for integration.
  • Increased demands for agility even in core applications. If there were no shadow IT, no server consolidation, it wouldn't stop companies from adopting public cloud services. Mobile worker empowerment and the need to create quick business responses to competitive problems, opportunities, or public policy changes, all encourage at least a division of core applications into a front-end/back-end structure with the former hosted in the cloud and the latter in the data center.
One pixel Mike Matchett: Building a hybrid cloud

For the cloud planner or CIO, the problem these forces create is the fact that they're almost impossible to plan for. Shadow IT, by its nature, is covert. Agility is the response needed to address unexpected problems or opportunities. Hybridization thus means framing a hybrid cloud architecture that can adapt to conditions as they unfold.

A hybrid architecture has to integrate separate application and data elements. To make that work, it's essential that a hybrid model be defined and that the tools and techniques used in the hybrid cloud support that model. If this is done, then new hybrid elements are fit to the model and can be expected to work as planned.

A hybrid cloud architecture starts by recognizing the front-end/back-end nature of applications that support the end user. Application pieces that relate to presentation of information, the GUI, and user notifications and support, are naturally cloud friendly. They should be separated cleanly and the workflow between the front and back ends should be designed to pass across the cloud boundary efficiently. The back-end components, designed to reside in the data center, should also be "layered" so that the portions of applications designed to update sensitive and business-critical databases are loosely coupled to the data editing and even analytics processes. This combines to create a three-layer vision of applications, with the UI at the top and database updating at the bottom.

The second step is to visualize the cloud boundary as something that slides from the very top of this stack to the bottom. At each position, the boundary will cut through application connections that will have to be optimized for hybrid cloud use, and will also change cost and risk profiles. For example, pushing the cloud boundary to the bottom of the stack generates major database risk and hosting costs that would likely be justified only in the case of a major facility-wide IT failure. At each step from top to bottom, the cloud boundary location will dictate a set of conditions that set the boundary there, and a set of policies that must be enforced for cloud boundaries at that point.

The third step is to select a cloud workflow management and integration strategy that is as unified as possible within any of the layers, and that uses work queues to loosely couple the layers themselves. The goal of this step is to ensure that if you move components between the cloud and data center within a given application layer, the process will be consistent at the technical component connection level. Without this every component move has to be customized.

When you have a hybrid architecture mapped out, it's critical that you test your approach against the dynamic drivers of change. The benchmark standard for agile business support is a well-developed enterprise architecture model using a modern framework (TOGAF, for example) and driving a service-bus workflow mediated through a business process execution language. While this approach is heavyweight in terms of technology, what it achieves is the ability to "compose" an application by linking components in sequence along a business process flow. Whatever you do, in each of your three hybrid architecture layers, it must accomplish this same goal.

All of the hybrid drivers above will move your cloud boundary around, and the boundary can also move in response to changes in internal or cloud costs, the performance of the cloud connection, and your access to a skilled labor pool to sustain applications in house. An agile architecture for hybridization may not prevent all the problems that these (often colliding) forces generate, but it will ensure your response will be as efficient as it can be.

Next Steps

Find the latest news and tips on building a hybrid cloud

Discover three obscure benefits of hybrid clouds

What are the signs you may be ready for hybrid cloud strategy

Dig Deeper on Cloud application integration