API gates and fences
If your company is not already publishing REST APIs, likelihood is it is talking about doing so. Gone are the days when a company's internet presence was limited to an eshop or, heaven forbid, a largely static web store front. So much for the topic of my previous post. Today's cool cats are offering web APIs for consumption by both web and native applications. The explosion of APIs has led to the introduction of the so-called API gateway, AKA API proxy. Its role is to decouple APIs from back-end providers and to offer infrastructure services so that service providers can concentrate on business logic.
This is how Kong, an open source API gateway, pictures factoring out common infrastructure code:
The picture does not show how producer and consumer are decoupled by fan-out, protocol translation and data format conversion.
With micro-services trending, services are becoming increasingly fine-grained. Rather than place the burden of calling many services and aggregating results, an API gateway may present a coarse-grained view and perform fan-out on consumers' behalf.
Different types of clients may have differing requirements with respect to protocols and data formats, so the API gateway may expose APIs tailored to the needs of specific devices by doing protocol translation and data marshalling.
Other than Kong, open source API gateways include Zuul, LoopBack, Tyk, WSO2, ApiAxle, 3scale, Apigee and API Umbrella. And there are many more. Many of these products not only offer proxying capabilities, but profile themselves as API manager. While the gateway is strictly run-time and handles requests and responses flowing between clients and back-end services, the manager is also concerned with API life cycle events such as publishing, updating and retiring APIs. You could consider them as the fences mentioned in the title: they keep rogue and immature APIs out of the production environment. Where the metaphor breaks down is that sheep pass through a gate to get to the other side of the fence, whereas an API gateway does not play any role promoting from testing to staging to production.
With so many open source products, you'd wonder whether there is room for any commercial offerings. Well, there are plenty. On the one hand, there are closed source products, some of which are part of the catalog of well-established SOA tool vendors such as Tibco (Mashery) and webMethods. Cloud providers too have been jumping on the bandwagon. Azure, for example, offers API management out of the box, as does AWS.
With respect to the open source projects, on the other hand, many are part of a commercial strategy of the company behind the project. Loopback, for example, is an open source Node.js framework built by StrongLoop, a company acquired by IBM in 2015. StrongLoop had a commercial API gateway built on top of Loopback in the works, but that has now been subsumed within IBM API Connect.
3scale is another open source API manager owned by a big player, Red Hat. Interestingly, 3scale started off closed-source, but was open sourced after its acquisition by Red Hat in June 2016.
As you can see, there is a lot happening in this space, not only technically, but also commercially. The stakes are high and I would not be surprised to see further acquisitions.
This is how Kong, an open source API gateway, pictures factoring out common infrastructure code:
 |
| Kong's role as an API gateway in an SOA. © Mashape, licensed under the Apache License, Version 2.0. |
The picture does not show how producer and consumer are decoupled by fan-out, protocol translation and data format conversion.
With micro-services trending, services are becoming increasingly fine-grained. Rather than place the burden of calling many services and aggregating results, an API gateway may present a coarse-grained view and perform fan-out on consumers' behalf.
Different types of clients may have differing requirements with respect to protocols and data formats, so the API gateway may expose APIs tailored to the needs of specific devices by doing protocol translation and data marshalling.
Other than Kong, open source API gateways include Zuul, LoopBack, Tyk, WSO2, ApiAxle, 3scale, Apigee and API Umbrella. And there are many more. Many of these products not only offer proxying capabilities, but profile themselves as API manager. While the gateway is strictly run-time and handles requests and responses flowing between clients and back-end services, the manager is also concerned with API life cycle events such as publishing, updating and retiring APIs. You could consider them as the fences mentioned in the title: they keep rogue and immature APIs out of the production environment. Where the metaphor breaks down is that sheep pass through a gate to get to the other side of the fence, whereas an API gateway does not play any role promoting from testing to staging to production.
With so many open source products, you'd wonder whether there is room for any commercial offerings. Well, there are plenty. On the one hand, there are closed source products, some of which are part of the catalog of well-established SOA tool vendors such as Tibco (Mashery) and webMethods. Cloud providers too have been jumping on the bandwagon. Azure, for example, offers API management out of the box, as does AWS.
With respect to the open source projects, on the other hand, many are part of a commercial strategy of the company behind the project. Loopback, for example, is an open source Node.js framework built by StrongLoop, a company acquired by IBM in 2015. StrongLoop had a commercial API gateway built on top of Loopback in the works, but that has now been subsumed within IBM API Connect.
3scale is another open source API manager owned by a big player, Red Hat. Interestingly, 3scale started off closed-source, but was open sourced after its acquisition by Red Hat in June 2016.
As you can see, there is a lot happening in this space, not only technically, but also commercially. The stakes are high and I would not be surprised to see further acquisitions.
Comments
Post a Comment