In summary, the article talks about how in the digital era requirements have changed when it comes to getting access to information. Fact that modern applications demand information in real time and expect it to be available 24x7, and also the side effect of cloud adoption which is causing information to become more and more federated amongst multiple cloud applications (from different vendors) and on-premises systems -as they won't go away that easily.
The article continues by explaining that although REST APIs play a critical role in providing such critical access, the underlaying technology stack that have traditionally enabled SOA architectures, typically based on monolithic middleware, will struggle to satisfy the aforementioned needs. The article concludes by explaining that a new form of platform, one that is light-weight, portable, hybrid and cloud-agnostic, REST/JSON native, Microservices Architecture ready, a 3rd generation, is ultimately required.
You might recognised the following picture from some tweets and articles:
|2nd vs 3rd Generation API Platforms Conceptually|
- An investment has recently been made in an API Management stack and there is a desire to understand if it is 2nd or 3rd generation, or at least verify if the desired capabilities are in the product roadmap.
- The need for a more sophisticated API platform, one that can go beyond traditional use cases (i.e. API Gateway in DMZ) but also easily satisfy hybrid (cloud/on-prem) scenarios, has been recognised.
- A Microservices Architecture initiative has been kick-started and the need for an API Gateway has been identified, however individuals within the initiative favour modern, lightweight, scalable, and affordable solutions over traditional, monolithic , heavy and also expensive API gateways.
|Characteristic||2nd Generation API Platforms||3rd Generation API Platforms|
|What is it?||Based on a monolithic stack. Most-likely derived from an ESB or an adaptation/extension of XML-based appliances. Support for Web APIs (REST/JSON) and associated technologies comes as an ad-on as capability wasn't originally in the product.||Built from the ground up to support Web APIs and modern API requirements such as API-first, hybrid deployment models, elastic scaling and Microservices Architecture. They tend to be lightweight and portable. Many based on async I/O based engines which makes them extremely efficient and scalable.|
|Business value of APIs||2nd Gen API Platforms pre-date the rise of the API economy therefore capabilities available in this space (i.e. monetisation) will be, as earlier said, an adaptation/extension of the tooling, not out of the box.||Built from the ground up to help organisations realise the business benefits that APIs have to offer. 3rd Gen API Platforms are rich in capabilities to help the business (not just IT) realise benefits. For example, better discoverability of APIs via API developer portals, API specific web-pages, developer self-service and API monetisation.|
|Deployment model: Centralised vs Federated||Typically centralised -most likely in on-prem DMZ infrastructure. Deployments with multiple instances across many different data-centres and geographies are not the norm.||Design with federation in mind. Deployment of gateways in multiple data centres and geographies fairly straight-forward, not a massive and complicated engineering undertaking.|
|ESB-less / XML appliance-less||As earlier said, 2nd generation tend to be extensions/adaptations of monolithic stacks such as ESBs or XML appliances. For this reason, satisfying modern requirements such as independent runtimes, rapid scaling and elasticity, rapid installation, multi-cloud and on-premise (hybrid) deployments, will be difficult to satisfy.||API platforms built from the ground up to support modern API requirements. Not an adaptation of old technology. Supporting requirements such as rapid scaling, use of Docker containers, infrastructure as code (meaning automating the entire setup/config/maintenance process) and hybrid deployments are one of the key differentiators.|
|Fat vs light middleware||Comparable to a Swiss army knife, 2nd generation platforms can do a lot. From message routing and data transformation, to complex service orchestrations and business rules. Thus in order to deliver such diverse capabilities, the footprint of the platform tends to be large. Such rich capability also means that the Gateway itself is used for all sort of things, including implementation of business logic implementation -considered a bad practice in modern architectures (smart endpoints and dump pipes).||Laser focus on satisfying API mediation requirements such as HTTP routing, Authentication/Authorization, API throttling, rate limiting, API load balancing and a few others, but certainly not to satisfy complex data transformation, orchestration or business logic requirements. For this reason amongst others, 3rd Gen Gateways are lightweight (definitely lighter weight than 2nd Gen).|
|Native Hybrid (any cloud + on premises)||On-premise technology by birth. Cloud (if supported) resulting from an adaptation or a cloud-wash. Several constraints most likely imposed by vendor if cloud deployment is supported.
Also note that 2nd Gen gateways claim to be docker-container ready, however when digging deeper one may find that use of containers is either not recommended for production, or the size of the container itself is so large that makes them impractical for use.
|Can be deployed in any infrastructure, cloud (any vendor) and/or on-premises without much complication. Straight forward deployment. Docker containers support out of the box.
|Native end to end /JSON||Not native, in fact many 2nd generation Gateways will convert JSON to XML (or something else) internally for processing and then back to JSON. A good sign that an API Platform is a 2nd Generation one, is the rich support available for XML-based standards such as SOAP/WSDL and WS-*.||Understands/handles JSON end to end natively because it was built for this. Full support for standards such as OpenAPI (aka Swagger) and API Blueprint in place by default.
XML support rare (perhaps just for converting SOAP to JSON).
|API-design first||As an extension, not native. In many cases simply not available. There tends to be a lack of proper API design and documentation capabilities which means that many of the APIs are not properly documented. Which means developer experience is not the best.||Fundamental part of the product. Rich support for API-design first therefore supporting open standards such as OpenAPI and API Blueprints for defining and mocking APIs. Capabilities to create API dedicated web-pages and publish them in self-service developer portals is the norm.|
|Microservices Archiecture||Precedes Microservices Architectures. Wasn't built for it and therefore there is a natural mismatch in terms of what a Gateway should and shouldn't do. For example, in Microservices Architectures, one would expect the heavy lifting to be implemented in the service, not a Gateway. Therefore most of the capabilities of 2nd Gen Gateways wouldn't (shouldn't) be used.||Microservices Architectures one of the core use cases for 3rd Gen API gateways address. For example service discovery and client-based load balancing is a core capability of such gateways. Also 3rd,Gen API Gateways are very lightweight and won't force any specific service implementation stack. Ideal for polyglot programming which is one of the fundamental principles of Microservices Architectures.|
|Software release||Traditionally an on-premise offering, therefore not cloud-first. Typically software patches/upgrades/new releases or have to be downloaded and installed -which could be a complicated task. For this reason software can rapidly become outdated. Also major updates/releases not too frequent (some times once a year).||Cloud-first. Release cycles are frequent (monthly or quarterly), and rollout process straight forward. In most cases happens automatically and fully executed by cloud vendor. In other cases new patch/releases are container-based.|
|Licensing model||Typically CPU-core based. Very expensive when it comes to large deployments.||Subscription model based on used (i.e. throughput based). Not CPU based.|
|Full API lifecycle||Partly. Requirements such API-first, control-planes (see next point), API-spec validation, Registry-based Service discovery (in a Microservice context), not typically available into the product but require extensions. API lifecycle tends to be fully separated from the Service lifecycle.||Either already out of the box, or easily extensible to be combined with other solutions or already considered and visible as part of the product backlog (roadmap)|
|Control plane API / DevOps ready||If control plane APIs (also known as management APIs) exist, these were built afterwards and not all functionality available via UI consoles is available via APIs that can be used for a control plane.||Products tend to be API-first, meaning that all sort of functionality is also accessible via the product API. Therefore ideal for Infrastructure as Code and DevOps.|
|Centralised management and analytics||Each domain and/or cluster would typically have its own central management and analytics console. So in large deployments, additional software, one that can plug into all these domains and clusters, would be required.||Part of the product architecture by design. 3rd Gen platforms are built for federation and scalability. Many|
Also developer-centric tools such as developer portals, tend to be an add-on of the core offering, they are installed and configured separately, not an intrinsic part of the platform.
|Built with Developer Experience in mind. The tooling usability is meant to make the life of the developer easier. Does not require product SME's to set up, use and/or configure -just good developers. Developer centric tooling such as API documentation and developer portals are fundamental components of the product architecture.|