Why API Gateways?
APIs are driving force behind many applications big and small. Whether your publishing a public API or building a new integrations marketplace, APIs are becoming the way business is done. Just like the web era had HTTP servers to serve those websites in production, APIs have API Gateways in order to serve APIs in production. One can leverage API gateways to help deliver the API with high availability in mind to your customers and partners. They are a type of proxy server that sits in front of your API and performs functionality such as authentication, rate limiting, routing publicly accessible endpoints to the appropriate microservice, load balancing across multiple internal services, among other things.
Enterprise integration middleware
Historically, the need for API gateways rose from integration challenges. Before REST and GraphQL APIs, companies were building SOAP and XML based APIs consisting of structured or unstructured data. API Gateways can provide a unified interface and link multiple legacy applications together. In such use cases, API gateways can take a legacy SOAP service, apply data transformation to the API such as transforming from SOAP to REST and JSON to XML). These type of transformations are usually not automatic. For example, RESTful APIs have very different core principals than SOAP, and thus it isn’t as simple as converting XML to JSON.
Breaking down the monolith
Microservice Architecture is the strategy of building and deploying independent services to compose a larger application. The pro and cons for microservice vs. monolithic architecture are beyond the scope of this article. From a high level, microservice architecture is becoming the way to build APIs. It enables multiple independent teams to work on a large application without stepping over each other or dealing with long deployment times.
Beyond microservices, there are even smaller units of compute such as nanoservices and serverless computing. Due to the complexity of managing hundreds or thousands of services and the requirements to provide a unified interface or contract to your clients, API gateways are becoming common place in architectures where microservice and serverless computing are used.
Benefits of API gateways
Regardless if you are using microservices or serverless computing or your API is internally used or publicly accessible, there are many benefits to using API gateways:
- Decoupling: If your clients which you have no control over communicated directly with many separate services, renaming or moving those services can be challenging as the client is coupled to the underlying architecture and organization. API gateways enables you to route based on path, hostname, headers, and other key information enabling you to decouple the publicly facing API endpoints from the underlying microservice architecture.
- Reduce Round Trips: Certain API endpoints may need to join data across multiple services. API gateways can perform this aggregation so that the client doesn’t not need complicated call chaining and reduce number of round trips.
- Security: API gateways provide a centralized proxy server to manage rate limiting, bot detection, authentication, CORS, among other things. Many API gateways allow setting up a datastore such as Redis to store session information.
- Cross Cutting Concerns: Logging, Caching, and other cross cutting concerns can be handled in a centralized appliances rather than deployed to every microservice. In fact, Moesif provides plugins for many API gateways like Kong and Tyk so you can obtain modern customer and API analytics without installing any SDKs.
Additional benefits for API platforms
Besides the benefits listed above, there are additional benefits for companies who are building publicly accessible APIs for customers and partners. Such API platforms are built by API first companies like Stripe or Twilio and also companies with developer platforms such as Github or Twitter. These days, its becoming far more critical for B2B companies to transition to platforms as customers and partners demand more customization and integrations.
Additional benefits using API gateways are:
- Manage API keys for developers, including providing a consistent way of authorization and authentication
- Rate limiting and billing which can be quota or usage based.
- Providing a developer portal for customers and partners to create API tokens, deprecate tokens, etc.
What is Moesif? Moesif is the most advanced API analytics platform used by Thousands of platformsto understand what your most loyal customers are doing with your APIs, how they’re accessing them, and from where. Moesif has plugins for popular API gateways such as Kong, Tyk and more.
Variables to compare by
Is it a single node appliance or does the gateway require running many types of nodes to get going and setting up database? Some gateways require multiple types of databases.
Open source vs proprietary
What happens when you want to extend the gateway with additional functionality. Are there plugins? If so, are the plugins open source?
On Premise vs cloud hosted
On-premise can add additional time to plan the deployment and maintain. However, cloud hosted solutions can add bit of latency due to the extra hop and can reduce availability of your service if the vendor goes down.
Some gateways are more of a bare bones HTTP server modified for serving APIs. Whereas others include the whole package including developer portals, security, and more. If the gateway includes such features, are features like the developer portal have a good user experience and design or enable you to adjust the design to fit your needs.
Are developers building additional functionality on top of the gateway? Just like Apache Tomcat and NGINX have huge open source followings. Some of the API gateways have large developer communities building scripts, questions answered on Stack Overflow, etc.
If you’re a small start up, do they have a good free tier or open source versions? Whereas if you’re an established enterprise, does the company have the support that you require.
Major players in the API Gateway Space
Kong is an open source API gateway that is build on top of (NGINX.) which is a very popular open source HTTP proxy server. Even though Kong is open source, KongHQ provides maintenance and support licenses for large enterprise. While basic features are had with the open-source version, certain features like the Admin UI, Security, and developer portal are available only with an enterprise license.
Deployment: one of the biggest advantages of Kong is its wide range of installation options, with pre-made containers such as Docker and Vagrant so you can get a deployment running quickly. NGINX is the most popular HTTP server after Apache and IIS and also very high performing even at high request rates. NGINX has a huge community of Lua scripts and extensions so you won’t be left in the dust when looking for some customization. Kong has moderate complexity when it comes to deployment. It does require running Cassandra or Postgres. Some plugins such as the rate-limiting one optionally require additional data stores such as Redis. However, a production deployment isn’t as complicated as Apigee.
Feature Completeness: Kong out of box provides many expected features of API Management, such as creating API keys, Routing to multiple microservices, etc. It doesn’t have a lot of transformation layer (mostly HTTP based transformation, no SOAP or to XML). However, if you don’t have many legacy apps, you probably don’t need the extra weight of data transformation layers anyway. Even though it comes with rate limiting, it doesn’t have billing integrations. The administration and management task can be performed via CLI or curl commands to a REST API which makes management easier to integrate within your existing devops playbooks.
Kong has the concept of services, routes, and consumers which provide a lot of flexibility when dealing with hundreds microservices that compose your API and different types of consumers calling your APIs. This enables plugins and transformations to be attached to a specific route or even a single consumer.
Kong is one of our highly recommended API gateways. If you don’t need the legacy baggage and want a popular open source API gateway, you can’t go wrong with Kong. It’s modern, designed for managing modern microservices rather than just adding a transformation facade to legacy monoliths, and has a rapidly growing community of plugins from API analytics like Moesif to caching layers and and verifying JWT (JSON Web Tokens).
Like Kong, Tyk is also open source, but it is under MPL license, which is less permissive than Kong’s Apache 2.0 license. At the same time, Tyk’s enterprise user uses exactly the same gateway as a community user. You don’t have to pay extra for certain enterprise features. Instead of relying on extra plugins and Lua scripts, Tyk is more of a batteries included API Gateway. Authentication schemes like OIDC, OAuth2, Bearer Token, Basic Auth, Mutual TLS, HMAC are all supported out of the box without requiring plugins. It also has support for XML->JSON, JSON->XML, JSON Schema Validation.
Deployment: Tyk offers both a cloud hosted SaaS solution or deployed on premise. You can deploy instances on Heroku or AWS. Their website offers tutorial on how. The open source version is relatively simple to deploy and only requires Redis, whereas Kong requires running both Cassandra or Postgres clusters.
Tyk has features such as Key Management, Quotas, Rate Limit, API version, access control, but no integrated billing features. Tyk has both a REST API and a web dashboard to do administrative tasks. While they do have an extension list, Tyk doesn’t have as large of a community or the plugin hub that Kong has. However, they do keep their gateway well designed and attempt to keep it lean.
Apigee is the oldest API Gateway listed in this article. It was founded in 2004 and acquired by Google in 2016. It is not open source, and is built on enterprise Java. They initially started as a XML/SOA app, but pivoted to the API management space. Apigee was designed to turn legacy monoliths into APIs that can be consumed by third parties. They have less focus on microservices and internal APIs.
Because Apigee has a complex multiple node architecture, the deployment has a far higher level of complexity relative to the open source API gateways. Apigee Edge requires running 9-nodes minimum on-premises and includes running Cassandra, Zookeeper, and Postgres forcing deployment to be planned by a centralized infrastructure team spending many months planning the deployment.
While majority of Apigee customers use the on-premises version, after joining Google, they have introduced a Cloud hosted solution. However, it’s closer to IaaS and has to be deployed to a specific Google Cloud data center rather than pure SaaS. Like the other hosted versions, the hosted proxy version will add latency and requires securing your own services.
When using hosted API Gateways, unless it’s in the same data center as your upstream services, it can add a bit more latency.
Unlike from other, Apigee supports end to end integrated billing for monetizing your APIs directly. The management portal is built on top of Drupal. Depends on your perspective, Apigee can seem either bloated feature wise or be the full solution. At same time being proprietary, it doesn’t have a big developer community contributing plugins or extensions.
Amazon AWS API Gateway
Amazon AWS, as the biggest cloud vendor, also has AWS API Gateway. It is a cloud only option. If you already are using AWS Lambda or EC2, you can deploy AWS API gateway in the same data center region as your upstream services so that the added latency will be less of an issue. AWS API Gateway is fully managed and can be deployed with a few clicks in the AWS portal.
When used in conjunction with AWS Lambda, AWS API Gateway provides a nice solution for Serverless APIs. Serverless is like microservices on steroids and requires immaculate management of your API endpoints to route incoming API calls to the appropriate serverless function.
Besides AWS Lambda, AWS API Gateway has the best one-click solutions to route incoming API calls to other AWS services such as Amazon Kinesis and Amazon DynamoDB. In addition, you can use your existing IAM infrastructure to provide authentication to APIs without much overhead.
Feature wise, it is comparable to Kong. However, AWS API Gateway doesn’t have a large developer community writing extensions or plugins. One of the biggest concerns using AWS API Gateway is vendor lock in.
Above isn’t an exhaustive list, here is a quick summary of some others:
Azure API Gateway is very similar to AWS’s offering. Of course, more suitable if you are using Microsoft Azure and has good support for Azure functions.
Express API Gateway is a new entry build by LunchBadger, it is completely open source and based on extremely popular Node.js Express framework. Their design philosophy is to keep it minimal and declarative. If you are building a lot of your core infrastructure on Node.js and familar with express middleware, worth taking a look.
KrakenD is also an open source product built in GoLang. we haven’t used this one yet. if you have any feedback, let me know.
Below is a quick summary of the findings in tabular format:
|Many nodes with different roles
|Cloud vendor PaaS
|Cloud vendor PaaS
|Data Stores Required
|Cassandra or Postgres
|Cassandra, Zookeeper, and Postgres
|Cloud vendor PaaS
|Cloud vendor PaaS
|Yes, Apache 2.0
|Yes, Apache 2.0
The usage of API gateways will only increase as more companies deploy more elaborate mciroservice and serverless architectures. In addition, more and more companies are launching developer programs of their own after seeing the early success of companies like Twilio, Salesforce, and Stripe. We are super exited to see how the API economy and developer platforms evolve and glad to contribute to it.