At 3scale we’ve always been fairly opinionated about the right way to architect API Management, and since founding have had a hybrid architecture at our core. So with Apigee today announcing an architecture with some similarities we figured it would be a good time to talk about those choices and why they matter.
API management in essence is about control and visibility of API traffic. In other words, it is knowing what is flowing through API pipes and making sure it is:
- A) the traffic you want
- B) doing the right thing
This involves all sorts of issues from security and identity to performance, uptime and fulfillment of business goals.
When architecting 3scale, we saw the same concern over and over again: API traffic should be deliverable from many locations, over different technology stacks and with different delivery needs but it needs a consistent, uniform management layer. This lead to the central tenant of our architecture:
Separate the management and control from the traffic delivery layer
This pattern is as old as networking itself with a separation of the control plane and the data plane, but it is different to the way most vendors apart from ourselves have architected API management today. These other approaches have essentially fallen into two camps: 1) “route all API traffic through our cloud” or 2) “deploy numerous individual on-premises gateways with a cost per gateway”. Both of these cause single points of failure, deal poorly with scale and end up with oversized costs.
When considering APIs for Microservices, IoT and many other modern challenges, it becomes even more obvious that separating how traffic is tracked and controlled from the point of delivery makes even more sense. Control and Data planes should be separate but talk to each other.
Apigee announced that the Edge product now has preview support for an new “microgateway” component which is a lightweight version of their cloud gateway that can be deployed outside the Apigee cloud system to route traffic. This is a good step towards a hybrid architecture and it is good to see another vendor making moves in this direction.
Hybrid Architecture taken further
We’d argue though while this is a useful step, there is a lot more to unlocking the true value of a hybrid architecture. To illustrate, 3scale’s architecture is below and shows how the individual pieces fit together.
- Allow multiple kinds of traffic delivery from NGINX or Varnish gateways, to global CDNs, our own APICast cloud proxy, all the way to lightweight code plugins
- Ensure that each of these can function autonomously to deliver traffic while syncing with the core management layer out-of-band
- Have a full set of APIs to enable anybody who wishes to write new traffic management clients
- Are not priced per node so API teams can mix and match as many nodes of different types they like to best suit their traffic patterns and not be forced to take risks under-provisioning
Together this means that management can be wired into wherever traffic flows to deliver control. It also protects customers from lock-in to a specific API gateway. Although many use the excellent and highly scalable NGINX powered gateway we provide, others may choose different mechanisms based on their needs and can do so easily.
The architecture buys our customers:
- 10’s of thousands of API transactions per gateway node (via NGINX)
- Unlimited, fully hardened gateway nodes
- Integration with caching and distribution power of full CDNS
- The ability to hook up custom traffic sources via API
- Very cost effective solutions
So it’s great to see architecture innovation in the space, but for a true hybrid architecture that boosts performance, we’d suggest looking further to include:
- Support for multiple traffic delivery mechanisms including open source
- Ensuring full API support so users can hook into the management layer from anything
- Removing per-node costs