A Survey of Modern Application Integration Architectures
The IT world is moving forward fast, and a single integration backbone is not sufficient enough in this era of integration.
CORE
·
Join the DZone community and get the full member experience.
Join For Freethe it world is moving forward fast. cloud services, mobile devices, and the internet of things peel away existing business models, but also establish wild spaghetti architectures through different departments and lines of business. several different concepts, technologies, and deployment options are used. a single integration backbone is not sufficient anymore in this era of integration.
a hybrid integration platform for core and edge services
“hybrid integration platform (hip)” is a term coined by gartner and other analysts. it describes different components of a modern integration architecture.
leveraging a well-conceived hybrid integration architecture allows different stakeholders of an enterprise to react quickly to new requirements. mission-critical core business processes (also called “core services”) are still operated by the central it department. these services run the business and change rather infrequently.
on the other side is the line of business needing to try out new — or adapt existing — business processes quickly in an agile way without the use of delaying and frustrating rules and processes governed by central it. innovation by a “fail fast” strategy and creating so-called “edge services” is getting more and more important to enhance or disrupt existing business models and therefore change the business.
figure 1: enterprise journey with core and edge services.
the following figure shows the components needed in a hybrid integration platform to run and change the business successfully:
figure 2: components of a hybrid integration platform.
application integration with an enterprise service bus (esb)
when to use it
esbs are usually used in bigger it projects where mission-critical core business processes have to be integrated with a need for high availability, reliability, and performance within the enterprise (“core services”). this affects many different technologies and applications to integrate standard software, legacy systems, custom applications, or external cloud services.
deployment model and target audience
integration specialists implement esb clusters to leverage high performance, high availability, fault tolerance, and guaranteed delivery of transactions. most of the integration happens on premise in the private data center. therefore, even “ microservices do not spell the end of the esb! ” you can deploy to cloud, but this is more “cloud-washed” — but not cloud-native — deployment and operations ; you “just deploy your existing application to the cloud!” however, this also can make sense, like for test instances or to use iaas capabilities without leveraging cloud-native features.
some options
an enterprise service bus (esb) includes products such as mulesoft anypoint platform , talend esb , wso2 esb , tibco activematrix businessworks , or oracle service bus . an alternative pure-coding solution is using an open-source integration framework such as apache camel or spring integration .
cloud-native application integration
when to use it
integration in a cloud-native environment is quite different than your traditional approach to application integration. typically, companies leverage platforms-as-a-service (paas) such as cloud foundry , kubernetes , openshift , or apache mesos .
the applications created using these cloud-native application integration tools run natively within these paas environments and therefore benefit from the features offered by these platforms, including provisioning infrastructure, service discovery, load balancing, elasticity, cluster management, or fail-over out-of-the-box. it also allows more agile development to implement, adopt, and scale new features or innovations quickly and efficiently.
for this, the application development and architecture needs to be adapted to cloud-native concepts. this especially includes applying concepts behind “ the twelve-factor app ” principles, which recommends best practices for cloud- native applications such as stateless services, automation via devops, or environment-independent backing services. often, you leverage independent containers (i.e., docker , coreos , or cloud foundry’s warden ) for building cloud-native microservices or applications.
deployment model and target audience
core it teams are adopting these paas platforms, but they are doing this to drive the agility for all developers. as a result, both the traditional integration teams as well as the developers within line of business are able to benefit from these platforms and the capabilities offered by the integration technologies.
paas are widely adopted: on premise, in the public cloud, or as hybrid deployments. however, many enterprises do not have a complete, long-term strategy yet regarding cloud or hybrid deployment architectures. hence it is important to develop cloud-platform-agnostic integration services, which can be moved from one platform to another without great effort or redevelopment.
middleware also should support and integrate mature, open-source frameworks for cloud-native environments such as spring cloud configuration , consul , netflix’s eureka , or hystrix instead of re-inventing the wheel by introducing additional complexity. the article “ a cloud-native architecture for middleware ” explains the concepts behind cloud-native platforms and deployment options in much more detail.
some options
tibco businessworks container edition or wso2 are examples for cloud-agnostic integration middleware supporting different paas and container platforms such as cloud foundry, docker, kubernetes , or aws ecs. jboss middleware services allows the deployment of its middleware applications onto openshift .
integration platform as a service (ipaas)
when to use it
an ipaas cloud integration middleware is a pure public cloud offering hosted by a speci c vendor. using ipaas allows the line of business to react quickly to new requirements or innovative ideas without struggling with the core it team and its long release and quality management processes. ipaas can be used for both mission-critical core services and innovative edge services.
deployment model and target audience
the vendor takes care of cloud-native features such as provisioning of infrastructure, elasticity, or multi-tenancy. this needs to be a real cloud-native enterprise-grade runtime and not just a “cloud-washed” offering. otherwise, it is not possible to scale out quickly and easily while still keeping high demands regarding stability and resiliency of integration services.
the target audience for ipaas is not necessarily the integration specialist with extensive technical experience. ipaas also allows colleagues with less technical expertise (sometimes called “ad hoc integrators”) to define, deploy, and monitor services and apis with its corresponding policies. ad hoc integrators often do not use the more powerful ide but an intuitive and simple-to-use web user interface.
ipaas has to work well together with other integration solutions. how different integration solutions work together depends from vendor to vendor. you should check if you need to redevelop existing services, if you can add changes via a web ui, and if different products work together at all (including commercial support).
some options
the ipaas market is just emerging these days. some examples are dell boomi , informatica cloud , mulesoft anypoint platform , snaplogic , jitterbit , or tibco cloud integration .
integration software as a service (isaas)
when to use it
isaas integrations serve “edge services,” which are not strategic and mission-critical for the enterprise — but very relevant for the specific business user. for instance, a business user creates a daily automatic flow to synchronize data from a google sheet with salesforce crm. this removes the need to integrate these updates manually every day.
deployment model and target audience
isaas is hosted and operated by the vendor. in contrast to the above integration components, isaas focuses on business users (also called citizen integrator in this context). they can create basic integration flows for personal or department interests in a very intuitive web user interface without any technical knowledge.
some options
examples for isaas solutions are snaplogic , tibco simplr, or ifttt (“if this then that”) .
iot integration gateway
when to use it
the internet of things (iot) changes the role of edge integration. it raises several new challenges not relevant for classical application integration such as low bandwidth or non-reliable connectivity.
here you need to integrate data directly on the edge devices, as not all data should be sent to the private data center or public cloud. for example, you might aggregate and filter sensor data from an assembly line in manufacturing, and only forward relevant information (such as alerts) to external interfaces. an iot integration gateway interconnects all devices via various iot standards such as mqtt, coap, websockets, bluetooth or rfid.
deployment model and target audience
integration specialists use the iot integration gateway to realize iot edge integration. development can be done via coding or intuitive web user interface and out-of-the-box connectivity to various iot standards.
some options
you can use hardware gateways from vendors such as intel , arm , or eurotech , or iot gateway open-source frameworks such as ibm’s nodered (implemented with node.js using javascript) or tibco’s flogo (implemented with google’s go programming language ).
api management
when to use it
the trend is heading towards an open api economy where services are exposed as apis to other internal departments, partners, or public developers. think about examples such as paypal, whose api is integrated into almost every online shop as a payment option, or google maps, whose api is used in almost every website that includes a description of how to get somewhere.
deployment model and target audience
the target audience is the line of business which leverages api portals to think about new digital products to increase revenue or make customers happy. a key for success in a hybrid integration architecture is a good cooperation between api management and different integration solutions. this enables developers to reuse services to concentrate on new features, shorter time-to-market, and innovation instead of recreating existing services again.
some options
examples of api management solutions are apigee (pure player), akana (pure player, formerly soa software), mashery (tibco), or 3scale (red hat). sometimes a hardware api gateway such as ibm datapower gateway is used as a replacement for or in addition to the software api gateway.
the need for a hybrid integration architecture
this survey shows that a single integration platform is not sufficient anymore in the era of cloud, mobile, big data, and iot. differentiation between core services for running the business and edge services for changing the business is a key step towards a hybrid integration platform. on-premise vs. cloud-native development and deployment is another key aspect. streaming analytics and business process management (out of the scope of this article) are not part of application integration directly, but also relevant for a hybrid integration architecture.
more ei goodness
if you want to see other articles in the guide, check out:
Published at DZone with permission of Kai Wähner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments