DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Doin' DevOps » Top 5 Anti-ESB Arguments for DevOps Teams.

Top 5 Anti-ESB Arguments for DevOps Teams.

By: Sven Malvik on July 6, 2015 4 Comments

Unix and Mac. Developers are always in combat. My last verbal combat was a “discussions” around ESB and Microservices. They are fun because both supporters tend to have very strong opinions about what they think is best and both want to fight each other. I recently got involved in one of those discussion about ESB vs. Microservices and the ESB guy throw lots of arguments at me. “ESB is magic” got almost burnt into my mind until I started to investigate a bit: “How to fight ESB discussions in combat?”. Here are my top 5 findings that may help in your next verbal ESB combat situation.
Recent Posts By Sven Malvik
  • Continuous Delivery and The Proof of Quality Assurance
  • Top 3 DevOps Practices for Operational Stability
  • The DevOps-Price of Segregation of Duties.
More from Sven Malvik
Related Posts
  • Top 5 Anti-ESB Arguments for DevOps Teams.
  • Microservices: The Advantages of SOA Without Its Drawbacks
  • Top 3 DevOps Practices for Operational Stability
    Related Categories
  • Blogs
  • Doin' DevOps
  • Features
    Related Topics
  • devops
  • esb
  • microservices
  • sven malvik
Show more
Show less

ESB Tightly Couples Services.

JBoss in 5 minutes (from Installation to Deploy) - Quickstart - by Sven Malvik
JBoss in 5 minutes (from Installation to Deploy) – Quickstart – by Sven Malvik

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.

DevOps/Cloud-Native Live! Boston

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

Filed Under: Blogs, Doin' DevOps, Features Tagged With: devops, esb, microservices, sven malvik

Sponsored Content
Featured eBook
DevOps: Mastering the Human Element

DevOps: Mastering the Human Element

While building constructive culture, engaging workers individually and helping staff avoid burnout have always been organizationally demanding, they are intensified by the continuous, always-on notion of DevOps.  When we think of work burnout, we often think of grueling workloads and deadline pressures. But it also has to do with mismatched ... Read More
« “Show Me The Money!” – Delivering DevOps Value
Best Practices to Prevent Scrum Failure »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Building a Successful Open Source Program Office
Tuesday, May 24, 2022 - 11:00 am EDT
LIVE WORKSHOP - Fast, Reliable and Secure Access to Private Web Apps
Tuesday, May 24, 2022 - 3:00 pm EDT
LIVE WORKSHOP - Boost Your Serverless Application Availability With AIOps on AWS
Wednesday, May 25, 2022 - 8:00 am EDT

Latest from DevOps.com

DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career
May 23, 2022 | Veronica Haggar
GitLab Gets an Overhaul
May 23, 2022 | George V. Hulme
DevOps and Hybrid Cloud: Life in the Fast Lane?
May 23, 2022 | Benjamin Brial
DevSecOps Deluge: Choosing the Right Tools
May 20, 2022 | Gary Robinson
Managing Hardcoded Secrets to Shrink Your Attack Surface 
May 20, 2022 | John Morton

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

DevOps: Mastering the Human Element
DevOps: Mastering the Human Element

Most Read on DevOps.com

DevOps Institute Releases Upskilling IT 2022 Report 
May 18, 2022 | Natan Solomon
Apple Allows 50% Fee Rise | @ElonMusk Fans: 70% Fake | Micro...
May 17, 2022 | Richi Jennings
Making DevOps Smoother
May 17, 2022 | Gaurav Belani
Creating Automated GitHub Bots in Go
May 18, 2022 | Sebastian Spaink
DevSecOps Deluge: Choosing the Right Tools
May 20, 2022 | Gary Robinson

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.