Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

The rise of Agile Integration, Integration is not DEAD nor LAME!

June 12, 2017
Christina Lin
Related topics:
Microservices
Related products:
Developer Tools

Share:

    I wanted to blog about this for a very long time, but because of work and being too lazy to turn on my laptop on the weekends, I now finally have a couple of hours to sit down and start blogging.

    "Integration is DEAD."

    "No, no, let's talk about microservice!"

    "What is that again? Integration, you mean SOA? It's lame...".

    During my recent conversations with many people about Integration, these comments came up a lot. In fact, if you happen to attend any the software conferences, you see the rooms are full when the topic is about "containers" and "microservices." I understand the nature of a developer, always seeking for the latest and greatest technology that's out there. BUT! In my opinion, I don't think Integration is going AWAY if you containerize your application. Neither will it DISAPPEAR in a microservice architecture. In fact, Integration just gets more complicated and tricky when you try to break an application into smaller pieces and have them running all over the place in a distributed environment!

    Bulls imageIt was hard to deal with when we have to orchestrate, choreograph, and compose all the coarse-grained services together, and imagine letting tinnier, smaller and more refined services talk to each other. Yeah, trying to get an oversized heavyweight strong bull to co-ordinate and communicate is one thing. Ducklings imageI don't think to have to conduct thousands of small cute ducklings, (I know, they are now smaller to handle one by one, light and easy to replace) is going be any easier. :-)

    Maybe the word Integration was abusively used by too many vendors (Us too), and it is too often associated with ESB, which IMHO should be one of the Integration strategies. ESB can be overly complicated with wrapped around RPCs. Integration is about connecting, composing between services, neglecting integration when implementing microservice architecture (MSA) is going to be disastrous. I am sure a lot of smart people out there designing the MSA have already taken this into account. But they probably did not realize that because Integration is already deeply ingrained into their minds, even in microservice we still want loose coupling. Again, in my opinion, the wall between application development and integration are getting thinner and thinner, by that I mean you do integration in a microservice way and apply integration in your microservice. So, yes, integration needs to change, adapt and adjust accordingly but it never goes away:

    • Current deployment method
      • As services are updated more frequently than ever before, we need to quickly respond to the change, in the integration layer. We can package it into the container and standardize the deployment method across the company.
    • Speed and automated delivery
      • A quicker response to a developer, continuous integration and delivery, and faster time to markets can be achieved by adopting the DevOps trend. Integration should also be part of this cycle. Not OUTSIDE!
    • Flexible for changes
      • Making sure the message can be routed to the correct service, allowing automatic discovery of services, with load balance capability that shares the load no matter its synchronized or event base call. Providing and composed with flexible contracts like APIs between service can also minimize the impact on the changes.
    • More robust towards failure
      • In the integration, it's all about the isolation of failure, and the handling of errors, and increase service resiliency. Also, the ability for it to adopt version changes, and service lifecycle management is also one of the important factors in Integration.

    Some concepts of doing integration in MSA compared with the monolithic application are poles apart. For example, continue from the bull and duckling theme. When you try to get a couple of stubborn, massive bulls together and adjust position it takes a lot of energy, and often you will need to be creative and smart to improve according to their position. Therefore, the pipelines have to be smart and do many manipulations. Whereas the ducklings are easy to move around and cheap to replace. If one got sick, naughty or does not have the right color you need, simply toss it and get a newly hatched egg. (Alright, I don't mean any animal cruelty here; it's just a metaphor. ). The pipe that brings these microservice can be dumb or simple. Because each duckling is cheap to create.

    Microservices integration

    In my eye, microservice should never go freely to create on wherever and whenever it should be at least logically bound. I call this, application domain. By circling these microservices, we will be able to see a much clearer picture of inbound microservices integration and outbound microservices integration.

    The inbound microservices integration will be a lot more flexible in protocols, data formats because of the possibility to connect to various datasources and SaaS application. Since they are bounded within the same application domain, it's likely the data models are shared between these microservices. They tend to be more coupled with each other (although service autonomy is where we are trying to get. They are probably handled by the same person.) There will be a couple of microservices responsible for composing some of the other microservices together too. The logic inside should be simple and straightforward. And each of the microservices should easily take care of the protocol and data extract itself.

    On the other hand, the outbound microservices integration should be strictly loosely coupled with inbound microservices. Preferably access commonly managed endpoints from each application domain, yes, I mean APIs. It is mostly device or client bound. As it often requires putting together a more coarse-grain service like the old ESB days for the client application or from a process.

    Both inbound and outbound integration can be synchronous and asynchronous; it all depends on the need of your system. So, don't limit yourself to just one option. I strongly recommend the Enterprise Integration Pattern Book, as I said, the integration problem is still there. The patterns are extremely useful in this manner.

    Agile Integration is Red Hat's opinionated way of doing the integration. And most importantly, it's backed up by Fuse (Apache Camel) and OpenShift.

    It talks about 3 main pillars, which resonate my integration beliefs in the MSA world.

    • Distributed Integration
      • Lightweight, support distributed deployment
      • Pattern Based Integration
      • Reusable Connectors
    • Containers
      • Cloud native solutions
      • Lean artifacts, individually deployable
      • Container based scaling and high availability
    • API
      • Well defined, reusable, and well-managed end-points
      • Ecosystem leverage

    So! I hope my murmur on this blog post will at least make you think "Integration is NOT LAME." And start thinking about it the next time you create your next microservice.


    For a framework for building enterprise Java microservices visit WildFly Swarm and download the cheat sheet.

    Last updated: February 6, 2024

    Recent Posts

    • How Kafka improves agentic AI

    • How to use service mesh to improve AI model security

    • How to run AI models in cloud development environments

    • How Trilio secures OpenShift virtual machines and containers

    • How to implement observability with Node.js and Llama Stack

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue