Get updates to your emailSubscribe
I participated in a CA Technologies webinar on the topic of API Architectures for the Modern Enterprise. It dealt specifically with existing middleware infrastructure patterns and application integration technologies such as SOA and ESB (enterprise service bus) and discussed how to extend or add value to these legacy architectures using API Management.
I won’t go into the details here but there’s one specific topic I’d like to discuss for a moment – the concept of “NoESB”, which was coined by a leading analyst firm and is now one of the most used but least understood (and most controversial) terms in the market today. Why is the term NoESB so controversial? Let me give you a behind-the-scenes example.
One thought that NoESB suggests throwing out any existing enterprise service bus architecture and starting over, which might offend IT leaders who had made a significant investment in ESBs and were maybe even happy with their current state. Another thought it would put us firmly in the ESB category, soliciting comparisons to other ESBs and moving us away from more modern interfaces and patterns. And a third simply didn’t like that one of our bandwagon-jumping competitors had blindly started marketing around the term NoESB, adding it to a long list of buzzwords and analyst concepts they had driven into the ground through misinterpretation and overuse.
If the term NoESB was causing this much internal strife, what would it do during the webinar? Well, we’re going to find out. We’re all adults here and I think it’s possible to have a pragmatic conversation about a misunderstood term without anyone losing their minds.
So let’s talk. First of all, the term NoESB was first used a few times in a 33-page report that spent significantly more time focused on SOA-centric architectures, API-centric architectures and the fundamental shift from one to the other in today’s enterprise. The gist is that in order to address the needs of both architectures, a policy-driven service gateway becomes the most important piece of service infrastructure.
While this service gateway can exist by many different names – API Gateway, SOA Gateway etc. – there is a distinction drawn between a service gateway and an ESB. In some (but not all) cases, this architecture will also include an ESB. The report suggests a NoESB architecture is an opportunity to either avoid or reduce dependency on ESBs – which tend to be complex and expensive – and focus on a gateway that is decoupled from the service implementation itself.
Relying on policy definition and enforcement rather than modification of service code allows enterprises some flexibility around deployment options, the ability to support hybrid and evolving cloud infrastructure patterns and an adaptability to future requirements not offered by traditional ESBs.
Simply calling something a gateway doesn’t mean it will fit the requirements of a sophisticated enterprise. The service gateways the report references actually cut down on new application code by mapping existing data and application assets to formats and patterns most needed by service consumers – mobile devices, partners and cloud applications.
According to the report, gateways that provide these features actually allow enterprises to reduce their use of ESBs for specific scenarios around routing, transformation, mediation and identity enforcement, in some cases removing the need for an ESB altogether.
Performing these traditional ESB tasks in a gateway does not mean that the gateway has become an ESB; it simply means that other tasks performed by ESBs are less relevant in today’s IT organizations. The gateways focus on service consumption and application velocity; the ESB generally focuses on being a service container and providing advanced application integration or orchestration functionality.
As gateways continue to separate policy from implementation, integrate with more legacy/cloud applications through standard APIs (rather than legacy wireline protocols) and provide more sophisticated orchestration, ESB capabilities should only be used when necessary to achieve a specific goal or when hosting/governing existing applications to be bridged to APIs through an accompanying gateway. A simpler, more agile architecture focused on these gateways becomes a better return on infrastructure investment.
As I mentioned before, the term NoESB seems to grab the spotlight from the rest of a report that’s a really well-written and enlightening look at a much larger topic. Even the service gateways espoused by this paradigm are by no means the only components of the architectures being discussed – developer portals and repositories, API integration and composition tools, service monitoring and analytics – these are all requirements for a complete solution, whether focused on a SOA-centric or API-centric approach to these scenarios.
And the scenarios themselves are varied and complex, including application integration, SOA, B2B, multichannel applications, cloud integration and API ecosystems. Let’s not let a controversial label cloud a very real discussion around designing an appropriate architecture for the years to come; let’s instead focus on real solutions.
View the recording and listen to us focus on these real use cases and real solutions, talk about capabilities of various parts of the infrastructure, including both ESBs and service gateways and yes, even mention NoESB. We welcome a candid conversation on this or any adjacent topics, and would love to have you as part of the discussion.
The lack of common concepts and axioms is holding the software engineering industry back. This blog post explores the need for a common distributed systems vocabulary to help with that problem.
Matt McLarty on Aug 10, 2018
How weak API terms of service, lack of transparency, and permissive API scopes led to the Facebook-Cambridge Analytica scandal
Mehdi Medjaoui on Aug 8, 2018