ESB versus Data Microservices
In monolithic applications, an ESB connects all the features and functionality of each application run interdependently within a single instance. The monolith contains all of the code for each of the functions and services it performs.
Monoliths start small, but as requirements grow, development teams add new features on top of each. This happens until the monolith becomes interdependent, complex and difficult to untangle. This interdependence is problematic when making upgrades or changes. The code from different development teams working on different areas of the application invariably conflicts and collides. Ultimately, this happens until it’s impossible to manage application improvements.
Eventually, it’s necessary to recode the entire application from scratch. Doing this is costly and could detract from other business priorities. Alternatively, you can dismantle the monolith into its component parts, and create a microservices architecture.
A microservice-oriented architecture is different because the application exists as a network of small, autonomously running services. These loosely coupled microservices communicate with each other to create the larger application.
In this way, the microservices application is a honeycomb of “pluggable” services. They allow you to quickly develop, add, or remove features without affecting the larger whole.
Key takeaway: The microservices application architecture breaks down the traditional, monolithic application into its component parts because doing this allows them to run securely, and independently from each other. This provides a more agile framework for enterprise IT infrastructures because you can quickly, and inexpensively make adjustments to your suite of services in response to changing business requirements.