Why is the micro-service architecture not based on Enterprise Service Buses?

Question

What are the reasons against (or for) using the Enterprise Service Bus features when building a shared service that adheres to the microservice architecture ( http://martinfowler.com/articles/microservices.html )? Why should we use dumb pipes and smart endpoints, and not use smarter pipes and be able to develop simpler services?

Answer 1

This is a huge question and it is probably not possible to answer effectively in the SO Q & A format.

It depends on what you do with it.

If you are building a single product, which consists of many small functions that can be considered independent, then maybe microservices can go.

If you are a large corporate organization where IT is not the main consideration of the board of directors as a competitive advantage, and you work in conditions of strict regulation of the industry, where new standards should be applied in global projects with their own IT departments, some of the new acquisitions, where you You cannot centrally control all endpoints and applications within your organization, then maybe you need an ESB.

I do not want to be accused of trying to list ALL the advantages of both approaches here, as they will not be complete and may be outdated quickly.

Having said that, trying to be useful for the OP:

If you look at how Spotify and Netflix perform microservices, you can find many things that they like about this approach, including but not limited to: the ease of deployment of individual services, decoupled commands, and isolation of failures.

ESBs allow you to centrally administer and apply policies, for example, legal requirements, check everything in one place, and not hope that each team will receive a note on registering everything, provide global statistics on loading and uptime, as well as much more. ESBs grew out of large enterprises where the driver was not the response time of the client on the website and the speed of innovation (among others), but agreements on the level of service, cost-effectiveness and rules (among other things).

In both approaches there is great value. At the moment, a lot has been written about microservices, since ESBs were 10-15 years ago. Maybe this is a progression, maybe it's just a change, maybe it's just that the consumer product companies must sell themselves, and large enterprises like to keep parts private. We can find out in another 10 years. So far, it depends a lot on what you are doing. As in most cases in programming, I would start simply and only go to a more complex solution if you need to.

Answer 2

The term ESB is overloaded, primarily in the Java world, to mean a large and complex infrastructure that ends up with a bunch of poorly implemented logic in the center.

Lighter weight technologies such as Apache Caml or NServiceBus do not encourage this approach and do follow the “silent pipe / smart endpoints” approach, which from the very beginning served as the foundation of the Internet.

NServiceBus specifically focuses on providing a higher-level structure than most message libraries to simplify the creation of intelligent endpoints that are more reliable through its deeper support for processing messages once and only once.

Full disclosure - I am the founder of NServiceBus.

Answer 3

The problem with using an ESB is that it creates a connection between the ESB and the services using some of the business logic built into the ESB. This makes it difficult to deploy a separate service independently and increasingly makes the ESB more complex and difficult to maintain.

Answer 4

Because services are isolated and channels are reused.

The basic idea of ​​microservices - isolation - any part of the system can be replaced without affecting other services. Smart pipes mean that they have a configuration, they have a state, they have complex (which often means difficult to predict) behavior. Thus, smart tubes are less likely to maintain their accurate behavior over time.

But - changing the pipe will affect every connected service, and changing the service only affects other services that use it.