BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
IT teams face a number of challenges when they need to integrate cloud applications. And the scope of these challenges depends on three primary factors: the application model, whether multiple providers are in use and an enterprise's choice of cloud integration tools or suites.
The challenge related to an application's model or architecture is the most critical. Integration is the connection of applications and components, and the architecture of those applications influences how they are integrated.
While there are many possible application architectures, the three most popular are the service bus or message bus/queue, the cloud front-end model and the microservices model.
The service bus model
Service bus integration tools are familiar to most developers, and until the web model of RESTful interfaces put pressure on older technologies, like service-oriented architecture (SOA), they dominated enterprise applications. A bus is a kind of message pathway that transactions follow and is primarily subject to business rules that decide which applications are run. Applications connect to the bus and can then receive some of the messages, which are usually business transactions.
This model can be a challenge in the cloud because it presents high overhead and potential delays, and can disguise inefficient connections between the cloud and a data center. As a result, simple service bus technology usually requires additional integration tools and steps and isn't the best basis for cloud app integration.
These issues with basic service busses have, however, driven an evolution toward more general API brokers that are suitable for different kinds of interfaces, including SOA. Companies like MuleSoft, a leader in service bus technologies, now offer broad API broker integration tools. These products are much more likely to satisfy general cloud integration needs.
The cloud front-end model
The cloud front-end application model consists of a set of cloud-hosted components that provide the connection between users and business applications, as well as the business applications themselves. This model is the most common for enterprises because it lets them maintain their core applications and databases in their data center and use the cloud to field transactions from multiple sources.
Providers' cloud integration tools are the logical solution to front-end integration issues, and they also offer specialized tools to create application front-end and mobile back-end processes. Where possible, use these tools to build cloud front ends for your business applications. However, these tools are not portable among cloud providers, so if you to have a multi-cloud deployment, you'll have to use different tools for each provider. In addition, users often have to supplement cloud providers' front-end tools with other cloud integration tools.
The microservices model
The microservices integration model typically requires an intermediary element, such as an API broker, API gateway or storefront design pattern that provides microservices users with access to microservices processes. The problem is that the features and capabilities of these tools vary and don't resolve all integration issues. Of the three, the API gateway is the most suitable in the long term for cloud and hybrid cloud integration. The simplest approach -- the storefront model -- provides little support for dynamic integration or load balancing, and the API broker option provides only user and service binding; it won't scalability and load-balancing features. Some platforms, such as Nginx, offer a complete set of microservices API brokerage and integration tools -- something that's important to meet evolving microservices needs.
Some of the best microservices integration tools are found in the cloud. Microsoft's Azure Service Fabric, for example, extends across the cloud, including other cloud providers' platforms, and on premises. It offers solid microservices integration and supports other models of cloud integration as well. These tools resemble general-purpose API brokers but are available as a cloud-hosted service, which enables them to integrate tightly with other cloud tools.
An API-centric approach
The market continues to move decisively toward an API-centric integration model, because developers can apply it to both traditional application workflows and microservices, as well as to both the data center and the cloud. This leads to the question of whether a cloud provider or on-premises API gateway is best, and the answer depends on your own application hosting plans.
Still, even API gateways don't do everything. Products such as Dell Boomi, which are known as integration platform as a service (iPaaS), roll all necessary integration tools into a single suite. This approach advances the state of cloud integration because it handles more of the application deployment and lifecycle tasks. However, while iPaaS suites might provide their own DevOps-like features, they rarely provide explicit, deep DevOps integration. This means that the operational side of application lifecycle processing isn't fully connected to the integration side. This iPaaS-to-DevOps integration is the last important step that cloud integration tools need to take to resolve all deployment challenges in public, multi- and hybrid clouds. They continue to approach that goal but aren't quite there yet. Until we get there, cloud integration will still require somewhat separate tools, and a single suite probably won't be enough.