API Gateway capabilities and features

By now most enterprises have heard about the concept of full life-cycle API Management (FLAM), but it is not uncommon when discussing the components of an API Management platform to have some initial confusion around the concept of the role of an API Gateway (APIGW) to a full solution.

Creating a repository for reuse and discovery, and exposing it through a developer portal or a Unified Catalog is often understood, but when it comes to the API Gateway capabilities and features, there is often still some uncertainty.

In the past, I have often tried to help my customers by comparing and contrasting APIGWs to other components within their enterprise. For example, when it comes to choosing a shield for your enterprise resources, how does it relate to a Firewall, IDS, IDP, or WAF? When using it for application integration and orchestration, where does it fit with a traditional ESB strategy?

Those details can certainly help once you have a handle on the idea of an API Gateway, but more and more I seem to be getting asked exactly what the features and capabilities are that define the technology. To help answer that question, let’s take a small trip back through time.

I dislike the name “API Gateway” — it is so limiting in describing its features and capabilities. It might come as a surprise to find the technology has changed names quite a few times over the last decade and you may have come across them before under one of their other aliases, such as an XML Firewall, RESTful Gateway, SOA Gateway, etc.

Other people have even given it such monikers as a “lightweight ESB.” Whatever the nomenclature of the day, API Gateways started back in the XML and Web Service days as we began the initial transition away from self-container monolithic applications to a more decomposed architecture.

In the past…

In the past, it was adopting SOA, with today’s evolution of that pattern, including microservices and event-driven architecture.

Either way, the core concept was the same — decomposed components with high cohesion and loose coupling, with the goal of increasing flexibility and interchangeability to make enterprises more productive and flows less brittle.

While ESB’s are great for building those concrete and reusable flows, there was a need for something that allowed for lighter weight application integration with more agility. From this arose what we know today as the API Gateway.

Okay, history lesson over — context is given. So now, what is it? Well, for any of you that have read my Digital Transformation article, you should know I, a self-proclaimed sorcerer of simile and metaphor master, love describing these things through wacky comparisons to more consumable concepts and topics. With that in mind, API Gateways are like the Panama Canal.

Let’s take a look at what the canal does

• Connects two separate bodies of water together to facilitate a new flow.
• Connects different bodies of water at different levels are mediated through a series of locks to allow the flow of traffic between them.
• Implements a series of gates are deployed as barriers to control passage through the channel.
• Implements contextual controls and tolls are implemented based on the vessel, size, and type of cargo.
• Enforces upper limitations and constraints are implemented on the traffic flow.
• Uses Maritime registries to track histories and travel of all cargo and shipments.
• Enables security forces to work with other Maritime bureaus to combat malicious actors through observability to all traffic.

Much like the Panama Canal, firstly and most importantly API Gateway’s focus on bringing capabilities and features enables two dislike components to work together and create a new flow or Application Integration. This could be authenticating users with passwords and creating SAML tokens for backend services, taking a RESTful JSON request, and transforming it into an XML/SOAP-based web service request or anything of the sort.

API Gateway capabilities and features

An API Gateway’s primary duty is to enable the connection of anything to anything where transactional consumption is concerned, including mediation of security credentials, message types, protocols, and more. Today we have seen the emergence of higher productivity models, such as Application Integration iPaaS, to enhance productivity and time to market.

But… as any enterprise architect knows, there are always atypical, nonstandard, and legacy systems and protocols that still need another layer of finesse to tie things together. The first true rule for API Gateway capabilities and features is enabling all your applications, endpoints, technology domains, and user personas to integrate where pre-built connectors and modules leave off.

Of course, you can’t just have any ol’ steamboat floating down your channel, can you? Just because the channel has been established and enabled does not mean it is open for all. Just like the Panama Canal used gates to control access to the canal and the flow of traffic, API Gateway’s act in much the same fashion.

Within API Management solutions, you will often find pre-established and selectable policies for securing API calls, but one policy does not rule them all. In much the same way that the canal uses the vessel, size, and type of cargo to make determinations on traffic flow and tolls, the API Gateway also provides the functionality to not just apply the policy, but to extend it to contextual policy.

Maybe for a single API, you want to enable different factors of authentication for internal users or partners. Maybe internal users working remotely must use a second factor of authentication. Maybe you wish to apply different SLAs or quality of service rules for different tiers of customers.

Whatever your use case, the API Gateway has the capability to enable the creation of contextual-driven policy and decisions, which can then be enacted for all traffic passing through, much like the canal.

What’s more, this is the true heart of what this brings. By being able to adapt any rule set in digital policy, you can allow developers to focus on business logic and embrace hyperactivity to threats by having a single point of administration to react at the speed of attacks, not just at the speed of software development.

Visibility and reporting

Finally, there are visibility and reporting. Analytics, alerting and logging is critical to security, continuous operations, and decision making. In much the same way as the canal enables the capture of information about vessels and a single point to watch for flagged vessels, an API Gateway controlling the flow of traffic across your enterprise enables a one-stop show for not only governance but also observability.

By seeing the full picture of your connected components and flows, you can easily identify bottlenecks and support the intelligence-driven defense of your environment.

Many features

An API Gateway brings many features and functionality sets to the table. Using its security and integration functionality, we can enhance our capabilities around governance, acceleration of development and time to market, lessen disruptive effects of digital transformation and modernization, enable service virtualization and policy enforcement, and more.

Call it an API Gateway, XML Firewall, SOA Gateway, or whatever you will. API Gateways are feature-rich tools that are powerful and necessary for any modern enterprise API Management strategy.