An ESB is a specific implementation of the EAI concept and is a modern method of achieving system-to-system communication. The key differences are that ESBs are broken down into smaller components that all work together to provide a single bus to facilitate interactions between different systems. ESBs forced communication from systems to align with Service Oriented Architecture (SOA) patterns to establish a common and standardized way of sharing data.
The main advantage of using an ESB for integration is the idea that connecting new systems only requires configuration and minimal coding. For example, system A produces events on the ESB using a Java client and a SOAP-based transport but system B consumes the events with a .NET client using REST. If we add system C into the mix, and these systems also want to consume events using a .NET client and REST, we already have a component within the ESB that facilitates this; all we would need to do is implement some configuration to establish a working connection. Over time, we can build up our standard library of connectors, which gives us greater flexibility about the systems we integrate and also reduces the overhead incurred:
On the other side of the coin, one disadvantage of this implementation is that ESBs are always on. When they're not busy, they are sitting idle, waiting for messages to be produced and published on the bus. ESBs are often built on large vertically-scaled infrastructure sizes to make sure that a bottleneck doesn't spike or a peak load doesn't occur. This is inefficient, especially if the quantity of messages being produced is minimal or sporadic. Digging into this further, using the previous example, let's say a new system is introduced (system D) that uses a .NET client and SOAP to produce messages. If system D produces significantly more data than the Java client using SOAP, then this component is spending most of its time waiting, whereas the .NET SOAP component receives most of the load. This highlights the inefficiencies of an application that is modular from a code component perspective, but not separately deployable by design.
That's where serverless enters the picture. In the next section, will explain how we can achieve the same result but with more efficient use of our infrastructure.