vali_111 - Fotolia


How to succeed with hybrid cloud application integration

In a hybrid cloud environment, it can be tricky to ensure all of your applications play nicely together. Expert Tom Nolle helps you think through the process.

It's becoming clear that every enterprise that adopts cloud computing will adopt hybrid cloud computing as well. If applications are going to float between public cloud and the data center, in addition to between public clouds, it's critical that you understand how the already complex task of application integration can be managed. Start by understanding what makes hybrid cloud application integration complicated, focusing on how each driver of change impacts integration and the alignment of tools with the specific integration issues.

Almost all applications today are built from separate components, loaded and run in different systems. Most will have to exchange data with other applications as well. This picture of applications implies that enterprise IT is really a web of workflows, and that vision is what drove the service-oriented architecture (SOA) movement two decades ago. SOA isn't simple, and yet, the problem it was designed to solve seems simple in a world where hosts are virtual and applications scale and move dynamically.

Application integration is the process of connecting workflows across components and applications. We have mechanisms to do that today for traditional data center hosting, and so what we have to focus on in the hybrid cloud is how those mechanisms have to be adapted.

Most companies won't want to completely revamp their application integration strategies; the impact on their productivity, on application lifecycle management and on security and compliance would be significant. Focus instead on the concept of adapting, and start by cataloging just what you have to adapt to.

Hybrid cloud adoption has four different impacts on application workflows:

  1. Some applications/components are hosted off premises and are subject to different security, compliance and network connectivity controls and capabilities.
  2. In some cases, cloud applications can use cloud-hosted services not available in the data center and not implemented in the same way, even across cloud providers. These differences impact workflow integration and component mobility.
  3. Applications/components can move dynamically, which means that workflows have to follow them, and can move between different connectivity/security zones.
  4. The cloud introduces the notion of dynamic scaling of capacity to match workload, something rarely offered in noncloud deployments.

Successful hybrid cloud application integration is best approached by accommodating each of these impact drivers, first in designing the hybrid cloud environment and then in adapting/adopting tools to address each issue. While the steps you'll take may be directed toward specific drivers from the list above, they'll have to be taken in such a way as to minimize the systemic risks that agile hybrid cloud environments pose.

The first step in successful hybrid cloud application integration is to create a unified application deployment and connection model across all of the hosting platforms/providers. This means defining "hosting" as an abstraction that can be mapped to any cloud or data center resource.

The biggest mistake you can make in hybrid cloud integration is overspecializing. You should establish a common network connection model across your entire hybrid cloud and then work to define a standardized hosting model to deploy applications/components.

The connection model issue can only be addressed by creating a virtual private network that can host all of the applications and components. Enterprises are increasingly looking to adopt software-defined or virtual networks as their connectivity core, and if the proper software-defined network or software-defined wide area network model is adopted, it can connect everything, whether in the cloud or the data center. There's no substitute for open uniform connectivity, so it's critical to get this right, and enterprises are recognizing that the basic cloud networking tools (OpenStack's Neutron, for instance) are best used to supplement this enterprise virtual network, not create it.

Once you have a suitable connection model, standardizing deployment environments facilitates using a single toolkit to integrate workflows wherever they lead. DevOps and Infrastructure as Code (IaC) tools all support a standard deployment process even today, and support for it is improving over time.

Taking this step will radically reduce any special issues associated with hybrid cloud integration and, in some cases, even eliminate them. However, not all users are familiar with the IaC tools and features, and these are important in standardizing hosting.

Finally, review the event handling properties of your DevOps solution; strong features here will help manage the operations lifecycle.

The second step is to define "home ranges" for applications/components based on security, compliance and execution requirements. Few organizations will want every component of every application to run anywhere in the hybrid cloud. If an application/component relies on a web service available only on a public cloud, then the home range for it is that cloud. If internal audit compliance rules or government regulations can be satisfied in only some places in the cloud, then these places are the home range. These home ranges have to be enforced by policy in the operations software that deploys and connects applications to ensure that they are run only where they can/should be.

Enforcing home range restrictions through tools and policies isn't difficult and doesn't require special tools. It does require attention to the specific restrictions of cloud providers and data center environments. It takes some planning and review, but grouping applications by home range is useful because it detects potential problem areas with failover and cloud bursting. You'll also find that if you can keep your specialization in tools and practices aligned with the various home ranges, you'll have an easier time with both integration and management.

The third step is to associate every application/component that can be scaled with load with a load-balancing function as a front end. Work distribution has to be provided with scalability, and so the workflow connections used in application integration have to connect with the load balancer, not with the scalable components. Load balancing, application delivery control, "Layer 3 switching" and other technologies have all been used for this mission.

When you're integrating applications for the hybrid cloud, it's critical that you have the smallest possible number of implementation options to support workflow distribution during component scaling and that you ensure that scale in or out steps don't disconnect workflows or create "hairpinning" or undesirable circuitous paths for data.

In the long run, hybrid cloud integration will become the rule simply because hybrid cloud will be the dominant model. The earlier your business gets experience with it, the better your long-term results will be.

Next Steps

How IaC can get you to DevOps

A different take on hybrid integration options

A step-by-step plan for integration

Dig Deeper on Cloud APIs and integration