Serverless integration is the next logical step in the enterprise application integration world. This concept builds on the foundations and learning of the previous EAI and ESB programming models and implements them through the use of architecture patterns with serverless technologies.

What we saw earlier was that not all integration components are used equally. Some connectors or transformations will always be used more than others, and their use will continue to change as consumers evolve their systems. So, what we need is something much like a microservice type model—something that is modular and can scale independently from other things.

Let's start with the previous example. In the serverless paradigm, we could have a lambda per client and completely decouple the internal workings of the ESB. In the past, you would have had different components spread across multiple distributed containers; today, though, we can build even smaller components that serve the specific function of interacting with consumers or producers:

Now, not only can components be built smaller, they are also only triggered and executed as the result of an event. For example, in the previous example, we had System A using a Java SOAP-based client that created events infrequently. In a traditional ESB, this would have required an internal SOAP-based component to be sitting there, waiting for an event. Now, with the use of serverless technologies, the Functions as a Service or AWS Lambda service would only spin up when messages were being produced. This drives a more efficient event-driven integration application and saves costs because we only pay for the compute we use and not for when the system is idle.

Now, let's take this one step further. Previously, an ESB would have had many different components and used various different methods to transport messages or events internally within the ESB to other components; it would then have passed these on to the consumers. One way to do this is through the use of various messaging technologies, which will involve hosting a message brokering system alongside the ESB to help facilitate the internal workings of the ESB. This has now changed, with message brokering systems being turned into serverless services as well, which once again means you don't have the overhead of hosting an entire message brokering system yourself.

The following diagram applies this example to AWS services, with Kinesis hosting a data stream and the Lambda service acting as our event consumer:

What all of this means is that, through the use of serverless technologies, integration architectures are now significantly more efficient and require less overhead to manage and implement.

That concludes this section about integration patterns. We covered EAI at a high level and ESBs, and moved on to integration applications using serverless components. In the next section, we'll apply a serverless and event-driven mindset to automation.