API Gateway – a Rapidly Changing Landscape
Note: Below is Chapter 2 from the recently released book “Kong: Becoming a King of API Gateways” written by Alex Kovalevych, Robert Buchanan, Daniel Lee, Chelsy Mooy, Xavier Bruhiere, and Jose Ramon Huerga. Posted with permission from Bleeding Edge Press. The full book can be purchased at Bleedingedgepress.com
When the Internet started there was only the concept of an HTTP Server that would serve up static web pages. That quickly grew into having application servers that served up web applications or servlets using HTTP Servers as reverse proxies to the applications. While these applications were great for the time, they became too large to allow integrations in a Service Oriented Architecture (SOA) with other applications/services, which lead to the creation of an Enterprise Service Bus (ESB).
All of the code for the sample project in this book can be found here.
What is an ESB?
An ESB implements a communication system between mutually interacting software applications in SOA. As an architecture, an ESB can be thought of as a central platform for integrating applications in an enterprise. It can also be thought of as an architecture that allows communication via a common communication bus that consists of a variety of point-to-point connections between providers and users of services.
An ESB promotes agility and flexibility with regard to high-level protocol communication (XML to JSON, and vice versa) between applications. The main goal of this high-level protocol communication is Enterprise Application Integration (EAI) of complex service or application landscapes in a maintainable manner. Some of its primary duties of an ESB are to route messages between services, monitor and control routing messages between services, control the versioning of services, and provide commodity services like data transformation and security. An ESB is generally used to facilitate the internal communication between services, but isn’t limited to this use case.
What is an API Gateway?
API Gateways are essentially glorified reverse proxies that offer more customizations and flexibility to reverse proxies. An API Gateway acts as an API frontend that orchestrates API Requests, enforces traffic policies (i.e. throttling, caching), security policies (i.e. authorization, authentication), gathers analytics on traffic, and orchestrates transformation engines for modifying requests/responses on the fly. An API Gateway is generally seen as the entry point for communication between the external requests and the internal services, hence its name. Using an API Gateway internally, however, can facilitate great rewards in terms of the standardization of policies.
Is an API Gateway a new ESB?
Are API Gateways a re-invention of the ESB? Yes and no. Although an API Gateway may provide a lot of the same functionality (security, data transformation, routing), it does it in an orchestrated way instead of a point-to-point or broadcast way. An API Gateway and ESB can live side-by-side because their primary duties overlap their intended purposes and they are separated by concerns of internal and external communication.
The equivalent of an ESB to animals is the nervous system combined with the circulatory system. When an organ needs to communicate with another specific organ, it uses the nervous system to send a point-to-point message. When an organ needs to broadcast a message to other organs that might be interested, it releases a hormone into the bloodstream to send a multicast message. When a message comes into the brain from anywhere in the body, the brain tells the body how to react. For example, if you accidentally touch a hot stove, the nerves in your skin shoot a message of pain to your brain. The brain then sends a message back telling the muscles in your hand to pull away. The API Gateway is equivalent to the brain in the way that it orchestrates interaction.
Although the API Gateway can be thought of as a brain, it doesn’t mean that it doesn’t need or isn’t enhanced by the nervous system. So, when looking at the current landscape, API Gateways are not a new ESB, but an enhancement of the original concept of an ESB.
API Gateway present
Back in time there were Neanderthals who discovered fire, and from fire they discovered cooking, and from cooking they were able to live longer. As they lived longer they started to want more than just a cave and they started building. First we had houses (HTTP Servers), then tribes (Reverse Proxies), then villages (ESB), and then we built towns. A town is small enough that everyone knows what is going on and can help out while being big enough that there is a need for a centralized way to manage the developments happening in the town. Most companies are the size of towns, and they have a lot of domain knowledge and offerings that a centralized API Gateway can fulfill their needs with, and they won’t need to be concerned with what is happening in the other towns.
In the present landscape there are a lot of well established offerings for API Gateways such as Kong, APIGEE, KrakenD, Tyk.io and IBM API Connect (previously Strongloop). Each one of these offerings has their advantages and disadvantages, from price, maintainability, scalability and customization.
API Gateway future
Although a lot of companies enjoy their peaceful town there are companies that are evolving into cities. While evolving from a town to a city the amount of buildings grows exponentially and planning the city becomes too big of a job for a single centralized contact, so the mayor has to employ a team to handle the planning.
With the orchestration of services in the microservice architectures becoming increasingly difficult, new developments into the API Gateway space have emerged to leverage other recent developments in tech.
Serverless
Functions as a Service (FaaS) (i.e. Amazon’s Lambda, OpenWhisk) were created not too long ago but have most recently become stable and a selling point to leverage as an API Gateway. When you breakdown an API Gateway it is really a stack of functions that chain off each other to fulfill a request. Thinking about an API Gateway in this fashion led to the use of FaaS platforms to facilitate API Gateway functions. There are several out there but one in particular that has been used heavily is the Serverless framework. This has been proven to be a good use case for simple API gateways, especially if you are already using FaaS technology for other business needs. It does mean that every aspect of your API Gateway needs must be coded, generally by your company. With Serverless the idea is that you do not have to run your own infrastructure. This can be a selling point to some, but it also means you are at the mercy of your providers network, policies, and operational capabilities. Using FaaS from a big provider like Google/AWS is ideal, but not every company is comfortable with having other people host their data, especially since any data breaches are a PR nightmare causing the demise of a company.
Service Meshes
As containerization became popular for the purpose of removing the overhead of running a full operating system just to host an application, it quickly became abused and now everything is its own container. This problem of every app as its own container spawned companies to have several thousand containers running at any given time. During a conference a speaker mentioned that in production they had over 4000 containers, but only 400 engineers, meaning that each engineer was responsible for 10 production systems. This would be considered a problem for an API Gateway, since in the current stance most gateways are hand registering each service it communicates with and how to handle the requests to each service (security and traffic policies).
With this massive growth in the number of containers a company creates, container orchestration evolved to start enabling service meshes. The term service mesh is often used to describe the network of microservices that make up such applications and the interactions between them. With the evolution of service meshes to orchestrate the number of containers connected in a logical service, the need to automatically register them into a gateway was desirable. Istio was developed as an orchestration tool to manage service meshes as well as Envoy.
There is definitely some overlap between API Gateway and Service mesh patterns, i.e. request routing, composition, authentication, rate limiting, error handling, monitoring, etc. That being said, the purpose of a service mesh is for an internal service-to-service communication with policy enforcement, while an API Gateway is primarily meant for external client-to-service communication. Much like an ESB being used as an API Gateway, a service mesh can be used as an API Gateway, but is more suited to replace the work of an ESB and work along side the API Gateway to expose the services to external consumers.
Sidecar Gateways
A trending pattern across all technology is the component movement. In this movement each and everything developed is analyzed to be either a component or a high-order component that is composed of several components. These components are the building blocks of modern applications. This component-based software engineering (CBSE) has even found its way into, what normally is centralized infrastructure, the API Gateway space. This pattern allows an application to get the primary functions of an API Gateway while living side-by-side, instead of having a historical top-down infrastructure. This approach to things allows a distributed method to enforce policies that are at an organization level.
Some examples of sidecar gateways would be Ambassador, Istio, and even Kong has adopted the sidecar approach as a capability.
API First: Weathering the storm
API first design is a strategy in which the first order of business is to develop an API that puts the target developer’s interests first and then build the product on top of it (website, mobile application, or a SaaS software).
This design strategy allows the product to enable full flexibility in how the users (developers) decide to utilize the product. This use may be outside the scope that it was designed for, but because of the flexibility new use cases are continually discovered. This strategy is taken into consideration by many engineers in software, construction, and more. Let’s take primitive shelters, for example. Their intended use was to allow humans to weather the natural elements. Eventually humans started using shelter to house their possessions, which was outside the provided use case for shelter, but didn’t violate the design aspects of a shelter. This use case for shelter led to a redesigning of the house to add more functionality without leaving its original intent behind as a shelter used to weather the natural elements.
To simplify, think about it like this: You built a primitive shelter, and it protects you from the natural elements. The world is a warmer and dryer place.
Now, another person in your tribe starts building an attached room, which interacts with your shelter. Then a third person sees the warmth and dryness the shelter is providing and decides to build a second story to your shelter. Soon, you have multiple people all building attachments with horizontal dependencies that are all on a different build cadence. What can happen if no discipline is applied to this in the realm of APIs is a nightmare of integration failures.
To avoid these integration failures and to recognize your shelter as a first-class artifact of the build process, you’d like others to be able to work against the shelter design contract without interfering with the original space that was developed.
Summary
You know have good examples of the use of API Gateways and why you would want to use Kong. In the next chapter we will look more closely at Kong and also compare it with competing API Gateways that are available.