ESB Tightly Couples Services.
ESB vs. Microservices, it’s like the holy war between Windows, Sometimes it’s hard and frustrating to make changes in a service that is tightly coupled with other services through the ESB. Whenever we make changes, we’ve side effects that needs to be investigated. And those side effects are sometimes in areas where we’re not the owners of. It’s one of the key disadvantages with having an ESB that has been pointed out on Wikipedia: “- Tightly-couples the entire system, which leads to more impactful deployments …”. An ESB has the ability to change requests and responses, for example if we want a response to be in a certain format, ESB tend to be the solution that can make it happen. An ESB also can aggregate two or more services into one, we call it orchestration. It can fulfill special needs without changing connected services. ESBs can do a lot. There is a lot of magic happening in ESBs that services depend on. It means that it isn’t enough to “just” test a service after a change. We are forced to always test the entire request/response chain through the ESB in order to be sure that all dependencies and the logic inside the ESB still work as expected. And because we’ve ownership only for our services, we depend on other people. Tightly coupled services are painful because changes and deployments are a lot more dangerous than if they would just serve independently.
Managing SOAP is Time Consuming.
SOAP uses WSDL which is a heavy-weight and verbose XML. It accomplishes its work through strong typed messages which makes SOAP feel a brittle format. Whenever you change a type, all clients will break and have to be changed to the new specification. Even a small namespace change can break the entire communication between two services. This makes also versioning extremely hard which is a core part of evolving services. Managing SOAP is hard when you need to spend time figuring out what to do. Therefore, the general rule of thumb is: “Unless you have a definitive reason to use SOAP use REST”.
ESB Experts are Bottlenecks.
READ: http://devops.town/better-off-with-microservices-or-esbs/
Busy people we depend on are always bottlenecks for us. And ESB experts are most of their time busy. They are busy because an ESB is such a complex component that it requires knowledge from very good people. It does so many different things like Routing, Messaging, Monitoring, Securing, Orchestrating and many other things. And from time to time we as the service developers need assistance from these people. We need assistance when we try to connect our services to the ESB. We need assistance when we manage WSDL files. And we need assistance when we want to track requests from one service to another. It’s obvious that an ESB with many connected services is a challenge in every organization. It’s up to us if we want this kind of challenge or if we want to move away from it and instead chose ownership of the entire value chain of our services.
Service Orchestration in ESB is Expensive.
Service orchestration is either changing business logic or it is moving users through processes. It’s the coordination of multiple services exposed as a single, aggregated service. Service orchestration is code that belongs in services, not in the ESB. What happens when business needs a change or a new feature? And some part of this feature has already been done and is available in one of the services connected to the ESB? Business will eventually ask the team that implemented the service if they can add this feature. What happens if the team says no because they got no time? Or if they say no because they cannot implement the feature because it doesn’t fit in the service? Business might talk to the ESB experts and ask if they can “just” add some logic to the service response. This new ESB logic depends now on the service and any change in the service will affect the ESB and at the end the clients consuming the aggregated response. Changes will become time consuming and expensive because dependencies are always frustrating and expensive.
Vendors Capitalize on ESB
ESB licences can be extremely expensive. Building complex software components like ESB is a business model. Andy Hedge put it in nice words. “In order to sell software licenses it was key to have something big, expensive and most importantly critical to the client once implemented. There is no greater example of this than the ESB.”. The Oracle Service Bus may be a great example. Licences cost thousands of dollars a year. What you get is a complex product and a great support. The thing is that some products are so complex that companies hire experts to manage them. And those experts often don’t utilize the vendors support. I personally like this kind of business model because it’s funny and sad at the same time, a wonderful contrast.
Conclusion
5 arguments that you can use against ESB supporters. Mix them with 5 positive arguments for using Microservices and you win hopefully every ESB vs. Microservices discussion. Even if you as a DevOps Consultant are not interested in ESBs, it’s good to know about them because discussions will come up and you better be prepared. Read all articles from Sven Malvik on devops.com
/Sven Malvik – DevOps Consultant from Oslo/Norway
