ALU (Alcatel Lucent) has done something interesting in the API Gateway space with their latest announcement. They’ve open sourced their API Management platform, it’s called apiGrove. So rather than offering freemium access to an API gateway, they’ve taken the route of allowing developers to use apiGrove and do it themselves. ALU have done open source projects in the past, for example their SIP application server, but apiGrove has been done professionally, using the advice of companies such as Voxeo Labs.
There are a number of API management platforms available, including but not limited to: 3Scale, Aepona, ALU, API Axle, Apigee, APISpark, Ericsson, Huawei, IBM, Layer 7, Managed Methods, Mashape, Mashery, Oracle, SOA Software, Webservius, and WSO2. Within this list the capabilities and business focus varies widely. There is currently no clear taxonomy for this space, each vendor has their own diagram, I hope to get an article out on that shortly, based on the discussion taking place in the Linkedin Telecom API group. At a high level there are 5 main functions within the API gateway:
- API Management – core functions of protection, metering and scale
- Mash-up (also called composition engine) – use one API to call multiple APIs
- Business Management – business model support
- Reporting and Analytics – knowing what’s gone wrong and why
- Console – across all functions is the user interface to manage the platform which does have a big impact on the usefulness of a platform, hence I break out as a separate function, as consoles vary greatly across vendors.
The focus of apiGrove is API management so its functions are:
- Protection: HTTP termination, authentication and threat protection
- Metering: API on-boarding / route definition, RESTful APIs, caller authorization, usage quotas & rate limits, and transaction data records
- Scale and management: supporting different deployment models, load balancing, high availability, caching, and management of all of the above functions.
apiGrove is available on GitHub under an Apache 2 license. Its 100% Java and is based on Fuse ESB (Apache ServiceMix, Apache Camel, Apache CXF, Apache Karaf), Jetty and Hazelcast. It’s been tested on Red Hat Enterprise 5.8 and should works on other Linux distributions (i.e., CentOS). So anyone considering an API business model can “dip their toe in the water”. Once experience is gained, they can then opt to migrate to ALU’s commercial API Management solution or to continue with the open source option.
Developers can contribute to the code adding for example adapters to other open source projects. I think this is a good step by ALU in differentiating their approach in the market. It is to be seen if open sourcing the API management function is enough, but there’s no reason they could not add functions down the line if the project does not adequately address that.
It was back in December 2009 that I wrote a whitepaper for Apigee (then Sonoa Systems) on the important of API Management to Telecom APIs. Since then operators have adopted those ideas relatively quickly on a telecom timescale, and today ALU has open sourced some key functions to implement API Management. Hopefully this will allow much more experimentation, and encourage telcos to use APIs internally and with partners rather than obsessing about long tail developers that have shown they are not interested in operators’ attempts at offering APIs.