For the last five years, API management products have provided the mechanism to front-end APIs. They manage access to the
API and protect the backend from unauthorized access or malicious workloads. Furthermore, API management products allow
for the separation between the functional capability and the governance of that capability, which often is handled by
separate operation teams. This is very applicable when externalizing an enterprise system of record, where the function
exists and needs an outlet with the proper protection and governance to enable partners and customers to use the API.
When API management is used, consumers request keys that represent a given entitlement expressed as a plan with a quota for
a set of API methods. Metering allows to control the usage of the API and to correlate each tenant to their subscribed
plan for billing purposes.
With the advent of microservices, decomposing functions as services is becoming more and more common. When iterating with
an agile methodology, the separation between function and governance starts to blur and both aspects are often supported in devOps
fashion by one team. In this mindset, initially, APIs are rapidly created and tested within the same team. As the API takes shape,
requirements for various API management functions arise. For example, metering allows to understand usage of individual endpoints
or to identify the invoker. In a small setting, an IP address may be sufficient, but as more tenants start to consume
the service, API keys may be more appropriate for identification. In another case, integration with a common identity provider and
authorization service allows for proper identification across service invocations and provides granular access to the
resources the API protects.
These API management capabilities are preferably activated incrementally and depend on the evolution of the API. Rather than a full
fledge API management gateway, developers may desire the individual features “a la carte”, decomposed and as light-weight as
possible based on the features required – similar to how developers consume APIs themselves.
We are starting to see frameworks that offer this path. One example is IBM API Connect, recently released, which offers a familiar API
management solution in form of its runtime gateway, and also includes the Strongloop framework to support the developer in the design
of APIs and allowing the incremental addition of API management-like capabilities. APIs will be pervasive but not all of them will require
a full-fledged API management gateway at the edge. Only some APIs will present opportunities
for monetization and thus need proper metering and access and the ability to scale as more customers consume the service.
As a counterpoint, aren’t APIs bite size functions that can be selectively used to accomplish a particular task? API management
services have APIs and could be consumed incrementally depending on the desired governance the developer wants to put in. You
would think that an API developer would want to consume APIs as much as possible and focus on the core function being built.
There is obviously a tension between consuming a service early on and finding a way to contain and control all development aspects.
Using a framework minimizes external runtime dependencies, keeps components locally, and allows for rapid iteration.
The developer will gravitate, like water, to the place of least resistance and even APIs will begin as just software.
Perhaps these frameworks should facilitate the switch between runtime environments so when APIs are “ready” they can be easily
deployed in the most appropriate environment.
How are you developing APIs? When do you bring API management capabilities to your API? What is your organization experiencing?