Businesses interested in cloud computing have likely noticed that many vendors now provide integration and orchestration
as part of their cloud services. For many, the shift may seem like creative marketing, because users today report little difference in orchestration and integration between the cloud and legacy IT. As cloud computing continues to evolve, however, that will change; cloud planners must address the impact of cloud-specific applications.
For enterprises, cloud computing is in a transition state. Early cloud use focused on server consolidation and development/testing. Then, cloud was an almost-static tool whose integration with the rest of the company's IT portfolio was trivial. Today, companies are looking at cloud applications that never ran on their traditional data center systems at all -- applications designed for the dynamism of the cloud. Getting these applications connected with users, with other applications and even with each other is a significant new problem -- one that pushes DevOps and deployment concerns into issues with orchestration, integration and management. The most critical decision a cloud planner can make is crossing the boundary between "basic" DevOps and advanced orchestration and integration.
Crossing into cloud orchestration, integration
Orchestration refers to the deployment and connection of app components. Integration is the process of satisfying interfaces among components to support workflows. Clearly, these functions are connected. When applications deploy onto static resources, a single set of tools typically called DevOps will provide for both. Adding cloud computing means changing resource allocations that must be accommodated, or application workflows will be broken.
Orchestration and integration will vary in complexity depending on how many variables are encountered, or created, during deployment.
Applications present functionality through network-enabled APIs, which provide workflow pathways for both intra-application (horizontal) traffic and user (vertical) traffic. When an app component deploys, it is assigned an address that must be used to link its interfaces with those of other components and users. Orchestration creates addresses and interconnects the deployed components, but integration is still needed to make the new application accessible to users and to link it with other components that may have already deployed.
Orchestration and integration will vary in complexity depending on how many variables are encountered, or created, during deployment. The cloud will always increase dynamism and variability, and so any cloud project should include a specific examination of both tools and practices in orchestration and integration to ensure stable and supportable operations over the long term.
When researching integration and orchestration options for a cloud project, it's important to consider how to accommodate dynamism -- in particular, cloud bursting and failover -- and functional hybridization of applications.
Mapping app workflow for complex, dynamic clouds
The general rule in reviewing apps for special treatment in cloud orchestration and integration is to map the workflow of the applications. This helps determine how often information flows outside the set of app components and how complicated the internal workflow for the application is. Highly interconnected workflows, when used with cloud-hosted components, quickly override traditional practices for deployment and integration.
Cloud-enabled, open-source DevOps tools -- such as HEAT, Puppet, Chef and Juju -- can accommodate the dynamic assignment of server/virtual machine resources and deploy cloud applications. If you set up the tools to return the addresses of the resources they use, those addresses can integrate components and orchestrate connectivity. However, keeping track of component addresses and mapping connectivity for workflows explodes in complexity as the number of components and the dynamism of applications increases. IBM, Microsoft, Oracle, Cisco, BMC and other vendors offer commercial orchestration tools as part of their cloud portfolio that can simplify this complicated process. As cloud apps shift from static to dynamic, these tools may offer a better approach to orchestration and integration because they can deal with large numbers of interconnected components.
Specializing orchestration for cloud bursting, failover
Cloud applications may also need specialized orchestration/integration if they make heavy use of cloud bursting or failover. In both these situations, the orchestration of component workflows will change dynamically to respond to load or failure. This dynamism means that the interconnection among components and with users may have to be changed as well. Unlike traditional orchestration and integration, these changes have to occur with little or no disruption for users, and they should be driven automatically by either system notifications or by recognized excess workloads.
In effect, cloud bursting and failover make orchestration and integration into management processes, and commercial tools are often better integrated with application management.
Most orchestration/integration issues come down to reporting the location of deployed components in directories, so that users or other components can find them. RESTful applications would normally use DNS; SOA applications might use UDDI; and both could use directory protocols like LDAP for maintaining links among application elements. Look for orchestration/integration tools that can automatically update these directory links.
However, nearly all cloud bursting and failover applications will also require some form of load balancing to distribute work to more (or replacement) components. The load balancer will typically have to be configured to locate each of the components it controls. Be sure your orchestration/integration tools allow for that.
Prepping cloud apps for hybridization
Few users are contemplating moving everything to the cloud, so it's critical to accommodate the pieces of application functionality that remain on local servers or even desktops. You'll need to link dynamic cloud elements with static, data-center-hosted pieces of the application.
The most complicated orchestration/integration requirements arise when the cloud is used to back up or supplement traditional IT applications, for two reasons: because this creates a mixture of dynamic hosting and static configuration, and because traditional applications are often managed through separate application lifecycle management (ALM) processes. Again, it may be helpful to consider commercial tools for complex requirements, starting with an exploration of the orchestration/integration capabilities of the ALM packages already in use.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Dig deeper on Cloud development and testing