There was a time not too long ago, before the cloud was a part of every enterprise technology conversation, when integration work was considered the purview of a specific architecture and engineering group.
If messages failed to send, or services failed to respond, application stakeholders would create a trouble ticket for the integration team to address.
In some ways, this separation of labor was effective enough at the time. There were a finite number of point-to-point integrations between systems, and most request/response traffic would flow through an integration backbone, such as an ESB or MQ server.
Even if a developer did some of the adaptation work in their own code, when their applications would be promoted, it would be standard practice to hand over the specifications and allow integration teams to manage how the transactions would play out, with jobs and traffic scheduling to hopefully avoid bottlenecks.
Whenever a blockage did occur, integration engineers would be first on the scene, because they were the most familiar with how their team set up each adapter and data transformation step branching off of that message bus.
In the modern application world, integration has become way too complex to be the purview of one group, or even one huge department, as our applications now surf on an ever-changing sea of services and hybrid IT architecture that is connected to partners, and the world at large.
Covering complexity with MESH
The software development community at large constantly invents new ways to bridge the divide between message queues and point-to-point integrations in order to talk to disparate systems. There were web services and SOA, then various shades of integration fabrics, and then containers and service meshes as today’s cloud native architectures evolved.
One company attempting to tackle today’s integration challenges, meshIQ, has coined a new acronym to break down the integration pattern. In this case, it’s not another service mesh—MESH stands for “Messaging, Event processing, and Streaming, across Hybrid cloud.”
Separately, each letter in the MESH represents a broad technology category. The plan is to bring together a flexible solution to integrate distributed and decentralized technologies. MESH in this sense is just as much a thing you do, as a particular solution you would buy, because it changes the relationships of DevOps, architecture, and operations teams to the integration process…
