Lighter Integration

Over the years, organisations have invested heavily in IT and, consequently, accumulated large portfolios of IT systems comprising of hundreds, possibly even thousands, of separate IT applications.  A single organization might use separate systems, developed either in-house or licensed from a third party vendor, to manage their supply chain, customer relationships, employee information, and business logic.  This modularization is often desirable.  In theory, breaking the task of running a business into multiple smaller functionalities allows for easy implementation of the best and newest technological advancements in each area, and quick adaptation to changing business needs. 

New Era of Lighter Integration

We could break up the enterprise-wide centralized ESB component into smaller, more manageable, dedicated components. Perhaps even down to one integration runtime for each interface we expose. This makes each individual integration easier to change independently, and improves agility, scaling, and resilience.

Agile integration architecture requires that the integration topology be deployed very differently.

Key Features:

• Installing a modern integration runtime takes a handful of minutes at most. Indeed, if using a pre-built Docker image, it could take no more than the few seconds it takes to start up a Docker container.
• Administering a cluster of integration runtimes no longer requires proprietary knowledge, because they would be running in a standard container orchestration platform such as Kubernetes or Docker Swarm.
• Scaling up and down, and setting up resilience policies, routing policies, and secure communication channels would be done in a standardized way, the same as all of your other application components.
• Command-line interfaces and template scripts are provided to enable standard continuous delivery tools that can be used to automate build pipelines.
• Integration tooling has improved to the point where most interfaces can be built by configuration alone, often by individuals with no integration background. With the addition of templates for common integration patterns, integration best practices are burned into the tooling, further simplifying the tasks. 

You are no longer restricted to one language or runtime, which means you can have a polyglot runtime—a collection of different runtimes, each suited to different purposes