This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Beginning a hybrid cloud project: Read more in this section
- Cloud stack comparison shopping when moving from public to hybrid cloud
- The limitations of hybrid cloud computing fundamentals
- Is the hybrid cloud model a myth in enterprise IT?
- Building a hybrid cloud on SaaS, PaaS and IaaS
- Hybrid clouds: A fix for PaaS, SaaS integration issues?
- Combining Agile and DevOps practices to build a hybrid cloud
Explore other sections in this guide:
Users of cloud services report that Software as a Service and Platform as a Service create more application integration problems than Infrastructure as a Service -- or even private IT. That can’t continue if cloud services are to reach maximum potential. Hybrid clouds can help by creating a uniform platform for deployment of integrated applications, facilitating the use of deployment/integration tools, and guiding application development and application lifecycle management practices to optimize integration. However, if hybridization isn't done right, the result could be worse than before.
Application integration is the process of linking application components to connect workflows and to optimize user access to productivity tools. Nearly every enterprise uses application integration with their internal IT assets, because most applications today are componentized in some way -- at the minimum they are presented from an application server through a Web server and to a range of browsers or mobile applications.
Most IT professionals are good at integration in the current IT environments. The problem with the cloud is that public cloud services don't present the same integration options as internal IT, and that's particularly true for Software as a Service (SaaS) and Platform as a service (PaaS), because these services limit the range of middleware, deployment tools and integration tools available to an IT pro. They also introduce dynamic resource connection requirements. Infrastructure as a Service (IaaS) -- because all the system and application software is supplied by the user -- looks more like internal IT and has proved easier to integrate because only one of these problems is present.
Hybrid cloud technology addresses both issues, not by making the cloud static or somehow making static-application integration and deployment tools work for dynamic resources, but by elevating integration overall to a dynamic level. In fact, the more dynamic a company's own IT resources are likely to become, the more likely it is that adopting private cloud technology internally and hybrid cloud technology to envelope both internal and public-hosted resources is the only path toward effective integration.
When integrating static application elements, the first step is to connect things, because the deployment has placed the elements in a largely fixed location so it's simply a matter of making the connection through URLs or directories. When integrating dynamic elements, the first step is to find things, because you can't presume that components stay in place. Deployment or integration tools that are directory-driven -- meaning they expect to find components dynamically -- can be used to integrate applications either in or out of the cloud. They work for IaaS, SaaS and PaaS equally well, in fact. The problem is that many enterprises don't use them because they didn't use dynamic resources before the cloud. Moving to private cloud architecture for their own IT would force them to use dynamic integration techniques and tools, and so solve the problem.
In most cases, hybrid cloud deployment solves application integration problems with PaaS and SaaS services, but the real source of the solution is 'hybrid DevOps,' not the hybrid cloud.
As always, though, the cure can sometimes be worse than the disease. The fact is that while implementing hybrid cloud platforms for applications will solve integration problems, it creates all of the work and uncertainty of a private cloud deployment that might not be justified. Less than 20% of companies see private cloud as a clear advantage over virtualization, so it might be better to look at adopting cloud-friendly integration tools to support application integration even without a hybrid cloud. This raises two obvious questions. First, when is it better to actually build a hybrid cloud? Second, what exactly should be looked for in deployment/integration tools that makes them "cloud-friendly"?
Users will typically find a private cloud helpful if their applications benefit significantly from dynamic resource assignments. A good test is to ask whether the company has adopted virtualization, and, if so, has it adopted tools to move virtual machines dynamically. If the answer is "Yes," then the company may be on track to adopt private cloud technology for resource efficiency or application availability reasons, and making the move to hybrid clouds now would only move up their private cloud transition. If the answer to either question is "No," then it may be better to look at cloud-friendly integration and deployment.
The traditional "connect" model of application deployment and integration deploys application components in static locations: "Put this component on this server and then connect it to that component" is a verbal picture of the model. The deployment process commits specific resources and so these can be connected.
With PaaS cloud components, the resource may be committed in the cloud, but it isn't necessarily in a dependable place and it can't be deployed using standard management tools -- the APIs of the cloud provider must be used. With SaaS components, the resource is never really deployed at all; it's purchased and must be integrated in the form that the SaaS APIs present.
All of this is compatible with cloud integration tools that fit the developer-operations (DevOps) model. Developers or software vendors describe the process of deployment and integration in the form of an abstract model or script, and this script then loads and connects elements as needed. Nearly all of the open source and commercial cloud DevOps tools support both dynamic cloud resources and static internal resources, but it's easy to validate this by reviewing features and pilot testing. Using a cloud-compatible deployment and integration tool -- not the hybrid cloud commitment itself -- is what makes hybrid clouds a solution to integration problems.
In most cases, hybrid cloud deployment solves application integration problems with PaaS and SaaS services, but the real source of the solution is "hybrid DevOps," not the hybrid cloud. Integration issues can be a factor in deciding to actually commit to an enterprise hybrid cloud strategy, but they can't justify that move by themselves. IT professionals must assess the total benefit case for hybridization before they take that step, no matter what their application integration goals and problems are.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @CloudAppsTT.