Submit support requests and browse self-service resources.
Microservices is essentially an ESB antipattern.
ESB is the old way of connecting applications that perform interdependent services by building an IT infrastructure. Microservices is the new way of connecting applications by using pluggable, autonomous services. Today, microservices is the path forward.
ESB stands for Enterprise Service Bus and is an architecture. In ESB, a bus-like infrastructure hosts a set of principles and rules for the integration of multiple applications.
Many of the ESBs emerged from integration platforms. The market started pushing more and more capabilities into the enterprise service bus with things like business process management and business activity monitoring.
Microservices is the new paradigm. It was born out of the need for simplicity. And it gets away from the enterprise service bus.
Microservices aligns with agile (think DevOps) and scalable (think containerization) development and deployment architectures. Martin Fowler and James Lewis defined nine core characteristics of microservices:
These are all key characteristics for microservices. But we'll focus on smart endpoints and dumb pipes in particular in this blog.
Avoid Microservices MistakesMicroservices can be the foundation to microservices — when it's done right. Watch the webinar below to learn how to avoid three big mistakes when using microservices and APIs.
Microservices can be the foundation to microservices — when it's done right. Watch the webinar below to learn how to avoid three big mistakes when using microservices and APIs.
ESBs deliver some very important security capabilities. These are often business-critical. In particular, ESBs deliver security, monitoring, and mediation.
ESB arose out of issues with SOA. The adoption of web services was delayed the first time around. Why? Original standards lacked effective security models. When the standards did evolve to address this, they became over complex and unwieldy.
This was coupled with the challenge of understanding what was happening in a distributed system. Especially when it came to troubleshooting performance or functional issues.
The enterprise service bus provided a solution to this. ESB centralized an architecture that was designed to be decentralized.
In hindsight this seems like a poor compromise.
Thus, the need for microservices.
Microservices face a different security challenge. There are plenty of security standards out there. But the questions are which one to choose and how to inform the service consumer of which standard it needs to comply with.
This lines up with the challenge of letting the consumer know where to find the various endpoint(s) for the microservices. The latter is especially important where services use dynamic scaling models.
“Smart endpoints, dumb pipes” means you should minimize the intelligence in your infrastructure. This means putting more focus on the services to implement their own functional — and non-functional — capabilities. It's also on the service consumers to understand how to consume each of the microservices.
This is essentially the enterprise service bus antipattern. It's a result of too much dependence on ESBs for non-functional requirements and, in some cases, even for business logic.
With the enterprise service bus, developers are encouraged to put:
Microservices is the present and future. And you do not need ESB for microservices. You can build microservices without having done ESB.
The microservices movement seeks to reverse this trend. In many ways, microservices gets back to the original intent of SOA. But when you compare microservices vs. SOA, microservices goes much further.
So, why should you transition from ESB to microservices? Frankly, microservices is the present and future — and ESB is firmly in the past.
Microservices enable IT organizations to be more agile and reduce costs by taking advantage of the granularity and reuse of microservices. In fact, the potential microservices business benefits are endless.
There are, of course, challenges in transitioning to microservices. That's why it's important to use the strategy to transition to microservices with APIs.
Security, as we mentioned earlier, can be a major challenge with microservices. Especially with securing the microservices mesh.
APIs and microservices are major points of vulnerability, given their ability to offer programmatic access to data. Security, therefore, is an essential element of any organization’s API strategy.
In our white paper, Securing the Edge API and the Microservices Mesh, you'll learn how to conquer security challenges and ensure a safe microservices transition.
📕 Get the White Paper More on Microservices + APIs
Explore additional resources:
This blog was originally published in 2015. It has been updated for accuracy and comprehensiveness.