Andy KofodAn API Gateway is an essential, and often misunderstood, piece of an organization's API architecture. The massive number of clients that need access to data, from mobile apps to single page applications to IoT devices, have caused an explosion in the number of organizations relying on APIs. There are various types of gateways available, and numerous features provided by each. There's no one-size-fits-all solution, and the correct choice depends on each organization's unique needs.
What is an API Gateway?
An API Gateway provides a single point of access to your backend services. Similar to a reverse proxy, it receives all incoming traffic and directs it to the proper service. This provides a layer of abstraction over your backend services, allowing clients to contact a single interface, rather than querying each service individually. But unlike a simple proxy, it can provide a variety of other features to help improve the security, efficiency and monitoring of the API. The image below shows some of the features available in the popular, open-source project, Kong Gateway.
Authentication
One of the most important features of a gateway is how it handles authentication. By authenticating all incoming requests in the gateway, you eliminate the need to perform authentication in each individual service. This can significantly improve your API's performance, and it reduces the available attack surface.
The authentication methods that a gateway supports is an important factor to consider when evaluating your options. What type of authentication do you want to use? Some will support a wide range of methods (basic authentication, API keys, OAuth, LDAP, etc.), while others may be more limited. Do you need to allow anonymous requests? Do you need to support multiple authentication methods to a specific service?
Authorization
Once a request is authenticated, the gateway may restrict which services the request has access to. This is generally done through policies that are setup in the gateway's configuration. For example, your API may have some services that are available to partner organizations, while others are restricted to internal use only.
To understand the type of authorization support you need, consider if your API needs to support different levels of access for different users. Do you offer subscription plans where higher tiers have access to additional services? Are your services configured in a way that allows you to handle authorization in the gateway, or does that logic need to be handled at the service layer?
Traffic Control
Another major feature of API gateways is the ability to manage the traffic accessing your services. You may want to limit the number of requests by IP address, or for a particular API key, for example. You may also want to limit the size or type of requests that your system will accept. This feature can also help alleviate stress on lower resource services. This can help stop DDoS attacks, prevent abuse of your API, and help prioritize system responses.
When evaluating your gateway options, consider your organization's needs for regulating traffic. How much traffic can you backend services handle? Are some services more susceptible to overload than others? If you offer different access tiers for your API, do you need to allow higher rate limits for your higher tiered customers? Do you have specific applications or customers who should receive priority during heavy load times?
Logging and Analytics
Gateways can also allow you to consolidate common functionality like logging and analytics. This can reduce duplication across services. Most can also be integrated with third-party solutions to provide complete monitoring for your systems.
You'll need to consider what type of monitoring and logging your organization needs. What security or analytics tools do you need to integrate? Do you need to correlate gateway logs with service logs?
Payload Transformations
The ability to transform payloads is another common feature for gateways to support. This allows organizations to support services that use mixed protocols, while providing a consistent interface to their API. Additionally, legacy services can be exposed with minimal effort, even if they use different response types.
Think about the services your organization currently has in place. Do the responses need to be modified to match your API's responses? Do you need to support multiple protocols?
Comparing Gateway Options
Beyond the feature questions above, there are several other points that need to be considered when selecting a gateway solution.
Self-Hosted vs. SaaS
While different gateways may vary drastically in the features they support, they can all be divided into two basic categories: Self-Hosted or SaaS. There are numerous self-hosted gateway options available, and the features they support can vary widely. This type of gateway can be deployed either on-premises or to a cloud platform. If you're hosting your gateway yourself, you have much more control, but you also have the responsibility for ensuring that your systems are configured correctly, and for keeping the software up-to-date.
SaaS gateways, on the other hand, are offered by all of the major cloud platforms. While they may differ slightly, they're all fairly similar in the features they offer. This type of gateway shifts some of the management responsibility off of your organization, like keeping the software updated. However, you will still need to ensure that your gateway is configured correctly to protect your backend services. One of the primary benefits of this type of gateway is its ease of integration with the cloud provider's other services.
Your choice of gateway type will depend on the features your organization needs, and on how your backend services are deployed. If you're already using a cloud platform for hosting your services, it may make sense to use the platform's gateway, since it can easily integrate with your other services, such as authorization, logging and monitoring. On the other hand, cloud gateways may not provide some features, such as payload transformation and their traffic control functionality may be more limited. Additionally, it may be more difficult to integrate with third-party services that you use. If your services are mostly on-premises, or you're using other third-party tools for monitoring or logging, it may make more sense to use a self-hosted option. Additionally, self-hosted solutions may offer the ability to create your own plugins if you need very specific custom functionality.
Deployment Complexity
Another factor to consider is how easily the gateway can be deployed. How complex is the initial configuration? What other resources are required by the gateway software? How difficult is it to redeploy the gateway when changes are made? Can deployments be automated?
In general, cloud gateways are going to require less initial setup. They will generally provide a developer UI, as well as an API, and can usually be easily integrated with the platform's automated deployment tools, such as Cloudformation or Google Cloud Deployment Manager. With a self-hosted solution, you will need to handle configuration and deployment on your own.
Different self-hosted solutions will also require different resources to be deployed, configured and maintained. For example, Apigee requires Cassandra, Zookeeper, and Postgres to run, while other solutions like Express Gateway and Tyk.io only require Redis. This won't be an issue if you choose to go with a cloud gateway, because they abstract the additional resource requirements, so you can just focus on the API itself.
Open Source vs. Proprietary
You'll also need to decide if you want to use an open source solution or a proprietary gateway. Do you foresee the need to make changes to the gateway's source code? What level of support do you need? Does the solution allow you to build custom plugins if needed? Are you already using other products from a vendor that offers an API gateway solution? There are both proprietary and open source options for self-hosted solutions, however all cloud gateways will fall into the proprietary category.
Obviously, if you go with a proprietary solution, you won't have access to the source code, and won't be able to customize the software if it doesn't meet your needs. However, some may allow you to create plugins to provide some custom functionality if you need it. Open source solutions, on the other hand, allow you to have complete control over your gateway. If it doesn't include all of the features you need, you can add them. One thing to remember though, is that if you fork and customize an open source project, you'll take on the responsibility of ensuring that your version gets future changes made in the project. If the custom functionality is something others might find useful, this can be resolved by contributing your changes back to the project. Another problem with open source solutions is that there may be a risk of the project being abandoned. When evaluating your options, make sure to determine if a project is under active development and has enough community involvement to keep the project going.
Usually, you'll have far more technical support if you go with a proprietary solution. When you're paying for a product, the company has a vested interest in ensuring that you're happy and can use the product successfully. The only support you can expect for open source solutions is from the community. This is another reason to make sure that a project has strong community support. That being said, a lot of open source projects are backed by larger companies that offer support packages, for a price.
Price
Finally, you'll need to consider the price for each solution. Most self-hosted proprietary vendors are not transparent about their pricing, so you'll need to contact their sales team to get accurate pricing for comparison. Cloud gateways, however, do provide pricing details. They generally run on a per-call pricing model, with additional charges for the amount of data transferred. In order to figure out which solution is more cost-effective, you'll need an estimate of the amount of traffic you expect your API to receive, and the average response size. While a cloud solution may be less expensive for low-volume APIs, if you are expecting a lot of traffic, there will be a tipping point where it becomes more expensive to pay per-call than to license and host a solution yourself.
Available Options
With all of these factors in mind, here are a few popular options of each type to get you started in your research:
Cloud platform gateways
Proprietary, self-hosted solutions
Open source, self-hosted solutions
While this certainly isn't an exhaustive list of all available options, these are some of the most popular API gateways. The best choice will depend greatly on your organization's needs. Hopefully, the factors above will help guide you as you evaluate your options.
