Application integration is a daily occurrence in businesses that use componentized or interconnected apps. While...
most cloud planners work to adopt the same practices for the cloud as they do for on-premises workloads, that may not be an optimal choice. By starting with the cloud's needs and tools, a cloud-centric planner can achieve better integration for the long term. That starts with an inventory of cloud interfaces, moves to a review of cloud integration tools and ends with a strategy based on evolution -- not on what has worked in the past.
Taking inventory of cloud interfaces
The first question a cloud planner should ask when building an application integration strategy is: "How do my application components appear when they're cloud-hosted?" Planners and architects know that "integration" in the application sense means tying together components through interfaces. Cloud apps are made visible by connecting one or more of their interfaces to a network -- such as the Internet or a VPN. Whatever is done to connect applications, it will have to exploit these interfaces.
In most cases, interfaces are published as a part of the deployment or orchestration tasks that will install cloud applications, so examining these tools and practices is a good start. If there aren't any current tools in use because the app won't be deployed in the cloud, then simply catalog the interfaces for each application component.
Once interfaces are identified, it's time to play "address detective." An interface will always have a network address, and this address has to be referenced by users and partner components. What form of address is it -- an Internet, IP or VPN? How would users and apps expect the address to be published (some sort of directory)? And how does the cloud provider assign and sustain the address if the application is hosted in multiple places?
If an application is spun up in the cloud, it will either have to register its address somewhere -- in a directory such as DNS, LDAP or UDDI; or the cloud provider will have to offer it through the management interface. If a component moves, the new address must be registered.
The next step is to determine how the address is registered for access, and the best strategy is one that its cloud component and users or partner components will support. If there are multiple options, select the one with the greatest flexibility. We're still in the early days of cloud application integration; having multiple choices is helpful.
Reviewing application integration tools
The next step is to choose tools for integrating, and they fall into three categories:
- Deployment and orchestration tools that install applications on the cloud. These tools will deploy cloud apps and often will also integrate multiple cloud components. Some may be flexible enough to support integration of non-cloud components, too.
- Open source tools for orchestration and integration that may not be a service of your cloud provider but that can support the provider's cloud deployment and connection needs.
- Commercial integration tools from software companies such as IBM, Microsoft and Oracle.
Some cloud planners may be tempted to use orchestration tools, but if you change cloud providers you'll then need to redo your cloud integration practices for the new setup. If you did an extensive competitive review of providers before selecting one, you probably want to keep your options open and forgo provider-specific integration tools.
On the opposite end of the spectrum are commercial integration tools, which can evolve from application development and application lifecycle management (ALM) software or from private cloud software. Enterprises whose cloud plans involve deploying a single vendor's software mostly or entirely should look at that vendor's tools first.
The most important point is to remember that not all development/ALM tools are fully capable of cloud deployment. Make sure your choice has that capability. It's a good sign when your integration tool is part of your vendor's own cloud software suite.
Open source integration is the middle ground, and it's often also the best solution. Most open source integration tools can be used with all the popular public cloud offerings -- users report it's easier to use them with IaaS than PaaS or SaaS. The tools obviously will allow you to integrate public cloud components with popular open source cloud stacks, such as OpenStack, Apache CloudStack or Eucalyptus.
The only problem with using open source is that the integration tools may expect you to deploy private cloud services to provide integration with the public cloud, while most commercial integration products will let you integrate data center components running on bare servers or virtualization.
If your company has multiple options for tools, a savvy cloud planner will list the integration options that work for the public cloud services being considered and then review how each has evolved to see if the tool is adapting to modern market needs in a timely way, and heading toward a cloud direction that's compatible with your business directions. To break a tie at this level, look for integration tools and practices that accommodate extensive application componentization, that support directory redundancy and performance enhancements and that have the widest range of interface and directory options.
Creating an application integration strategy for the future
About two-thirds of users who redeploy one or more major applications to the cloud find their current application integration strategies aren't cloud-optimal, and almost half say they're not even cloud-suitable. Starting your integration planning from the cloud side is critical if you want to continue or even expand your cloud commitment in the longer term. The further you go with an unsatisfactory cloud integration approach, the more difficult, expensive and disruptive it will be to change.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
How Built.io Flow helps connect separate systems