Have you ever heard someone say “I already have an Enterprise Service Bus (ESB) so I am all set for APIs”? The implication is that API middleware is “just another ESB” … An assumption that I personally disagree with.
APIs are ideally defined by configuration rather than coding. This preserves the light weight nature of the API proxy and supports the fast turn-around for new and changed APIs. General purpose ESB tooling is flow or code centric and service implementations are part of the enterprise Software Delivery Lifecycle. Even with continuous delivery, a code centric approach is challenged when attempting to keep up with the need for opportunistically changing APIs.
API runtimes need to be lightning fast, 100% secure, very robust and highly scalable. Ideally an API gateway has router like network characteristics so that adding an API proxy as part of an interaction never presents response time or latency issues. The fastest and most scalable API gateways are based on domain specific (light weight) configuration languages with stateless execution. While general purpose ESB runtimes do need to be fast, robust and scalable, by definition the execution engines must take into account full scale composition and some amount of statefulness. Consequently ESB runtimes cannot be as highly optimized for throughput.
APIs have policy driven business and IT controls, ranging from authentication through traffic controls and business plans (terms and conditions) under which the API may be consumed. While some of the more comprehensive ESBs include traffic management policies, few if any have the security policy capabilities (and certification) of a full scale API gateway and none have the separate business controls embodied in an API plan. Furthermore, the software nature of ESB executables typically means less room for operations to independently control runtime objects post deployment.
APIs must be made available to app developers in a self-service fashion. Any kind of post-deployment approval process will slow the adoption rate and ultimately, at scale, incur significant organizational cost. The preferred sharing mechanism, and one that has proven highly effective, is to publish APIs to developer portal environments. In particular for internal API use, sharing is preferably managed on a community basis, making sure that a given developer community only sees the APIs that they are supposed to use. General purpose ESB’s include none of these features, and even service management solutions are aimed more at development time and operational controls than at optimizing the developer sharing process.
Finally, API owners need business statistics about who uses their APIs and how much. These statistics are measuring success against the business objectives for the portfolio of APIs, rather than focusing on IT concerns such as the operational dashboards typically included in ESB platforms.
Parts of the industry will argue that “you only need one bus” which is repurposed to support classical integration needs, SOA and also API management. Yet without a dedicated experience for the API developer, the API owner and the app developer using the API… and yes on a separate platform an experience for the integration developer… you risk that the middleware is being engineered to a lowest common denominator. Not to mention that if you only need one of the two, why pay for both API management and general purpose integration capabilities? Modern enterprises need API management as well as enterprise integration…. but as two separate platforms aimed at different target audiences.
Btw, if you are already doing SOA then you have a good set of assets that you can assemble into APIs and expose through an API management platform. How to best leverage that advantage is a topic for a later blog.