Let app architecture dictate cloud integration tool selection
Does your application rely on a homogeneous or heterogeneous stack? Will the architecture evolve? Learn the types of cloud integration and which app and dev team setups they match.
Cloud computing seems easy enough. You just add an application on top of an operating system, deploy it to the cloud and everything should work. But when that application needs to reach back into your local systems, you need cloud integration, and things can get complicated.
At a minimum, the application will require access to a database. For security, architecture or quick deployment reasons, you'll likely abstract that database with microservices. Then, those services will need to communicate with an ERP or finance system, a data warehouse, an HR system, or another point of interest. Furthermore, these warehouse, database or service components might operate on a different cloud.
Invariably, enterprise IT teams need a plan to get these systems to work together to fulfill the business's needs, and that means cloud integration. The most common types of cloud integration plans require you to choose whether to write custom code, work with a single integrated vendor or introduce an off-the-shelf system -- also known as integration platform as a service (iPaaS). Let's explore which of these three options best fits your organization.
Custom code for the cloud
Most organizations begin their cloud adoption journey with one system -- most likely a website. That often means the development team uses the management console of a vendor, exposes a few firewall rules and permits the website to reach into the data center to access local databases or internal web services.
As deployments become complex, the team may start to use an infrastructure-as-code approach, which is a type of IT setup wherein developers or operations teams write scripts that automatically manage and provision the technology stack of an application rather than using manual processes. And once the team begins to write code, they may need to integrate with another service.
True integration does not depend on calls to a web service or requests to a webpage; that type of process requires point-to-point communication. True integration requires some type of dedicated software. The simplest example is a broker that waits for a message on a port, analyzes that message when it arrives and takes a certain course of action based on that particular message.
The sequence is considered synchronous if the message is tracked as part of a web request and asynchronous if the two are separated. When an insurance system takes in a claim, processes it overnight as part of a batch and sends an email with an update the next day, that's an asynchronous transaction.
Another common integration scenario combines a cache with a broker. The broker receives the message, and the cache sends out the old information until the source system updates itself and refreshes the cache.
Cloud-native startups and established organizations moving to the cloud reinvent these patterns, as was the case with Groupon several years ago. Eventually, every company must decide whether it wants to maintain its own hand-coded integration tools or rely on open source or vendor options while keeping the custom code minimal.
End-to-end single vendor
Some software teams work wholly on a single vendor's offerings. They use that vendor's tools to write code, provide version control and put code in the cloud. When teams that operate this way experience a problem, the benefit is that they are not alone. The vendor's other customers often experience the same problems, which consequently motivates the company to push out solutions.
These vendors usually provide a stack of tools. This stack enables customers to build microservices in the cloud. Users can also create a web application via containers or VMs by using the operating systems the vendor recommends, and then deploy the application to the vendor's cloud. Teams must use the deployment system, continuous integration system, cluster manager, service bus and message queue that the vendor provides. They also need to apply the vendor-provided software delivery patterns, including their methods for feature toggles and staged releases.
One company took the vendor tool stack path rather successfully. The company decided to rent software over the web for accounting and finance rather than having to create web servers or infrastructure software. It had some legacy systems, COBOL and databases, but it already had internal integrations in place for those. It only needed a single integration point to connect its cloud systems. It had all the problems you would expect when coordinating one hundred teams all working on web services, but its cloud integration worked well because its environment was homogenous, and the vendor handled the integration for them.
Heterogeneous-ready iPaaS
Integration platform as a service is a single vendor offering designed to provide integration services in a heterogeneous -- and often hybrid cloud -- environment. IPaaS typically runs in the cloud, and it can monitor the health of all the organization's cloud-based applications, including apps that operate in the cloud for different vendors.
IPaaS products usually provide a single dashboard to view the status of those applications, along with the information that's passed between them. Most of these tools can connect to software delivery and support tools, such as those for build and deploy, requirements management, and issue management.
In theory, iPaaS sounds like a wonderful integration approach, but it takes a a great deal of work to adopt it. Before moving to iPaaS, your decision-making team should get engineering folks involved to help everyone understand how those connections work at the UI and code level. Because iPaaS adoption can change teams' perceptions of integration work, don't skip this part of the process.
Depending on the organization, teams will learn different things. Some discover that certain integration work that sounds easy actually requires custom code and vice versa. Others find that things they used to think of as custom code can become point-and-click configurable using a web interface. The ideal iPaaS offering abstracts infrastructure and change control. Once they are set into motion, changes within one system should automatically flow into other systems.
Before you make an iPaaS purchasing decision, conduct some experiments. Make sure you fit the iPaaS profile, determine how many unique, out-of-the-norm needs you have and calculate how much work it will take for those difficult edge-cases.
Which style works for your project?
The style of cloud integration you choose should depend on the type of organization you have and the challenges you face.
If your connecting setup is simple and the structure won't change, custom code might be the way to go. This is especially true if your goal is to create a single point of integration, such as placing one cloud instance into your data center. The custom code in this scenario can connect to internal integration software that already exists in the software environment.
As the number of connection points increases, custom code may become untenable, and the project might require a single vendor tool stack approach. Microsoft, Oracle and IBM are among the vendors that provide sets of tools for tight integration. Teams that can afford to do so might standardize on a single, homogenous integration platform.
Then, there are the enterprises that grew through generations of software development. The ancient code may be what Scrum co-creator Ken Schwaber calls a core system -- something essential to running the business.
A company that grew through acquisition or that operates through different divisions likely has multiple diverse cloud platforms to manage. The largest enterprises will even have multiple internal integration systems that they need to integrate -- and that's no joke. Those companies will look to iPaaS as a way to connect the almost un-connectable.
