LinkedIn
Twitter
At the surface, API Management seems like a really easy concept to grasp. Using a proxy middleware layer, an IT infrastructure team can intercept API requests. This position in the architecture allows IT organizations to enforce business rules like ensuring that a valid access token is provided, or to account for quotas and consumption, and even to get some visibility into how frequently an API asset is being used.
While all this is true, the myopic view that the API Management layer is only necessary for technical and functional requirements implementation ignores the decoupling function an API proxy offered along with the transformative capabilities enabled in modern API Management tools like Apigee. Let's explore the table stakes features, and layer on the transformative capabilities of API Management.
Table Stakes - The Technology
Certain aspects of API Management are just expected. Any API Management solution from any vendor should be able to offer these capabilities, even if you've built your own. Broadly, these fall into three main categories - Access Control, Traffic Shaping and Quota Enforcement.
Access Control
An API Management solution needs to be able to ensure that only authorized consumers can make API calls. At the simplest level, API Keys can be used. API keys are a basic form of identification that helps assert the identity of the API consumers. In a highly trustworthy environment, such as transactions inside a datacenter, this can be a reasonable way to validate consumers.
As the level of trust of a consumer request decreases, the necessity for a more robust challenge is required to restore that trust and balance the trust equation before execution of an API. A sophisticated API Management infrastructure must be able to understand and validate these trust mechanisms to be ready for truly transformative programs.
|
Level of Trust (example) |
Implementation (example) |
|
Highly Trusted Applications |
API Key |
|
Moderately Trusted Applications |
API Key+Secret |
|
Trusted Users |
Username+Password |
|
Low Trust + Internally Managed Consumers |
3-Legged OAuth or SAML |
|
Low Trust + 3rd Party Consumers |
OAuth Federation and/or Open ID Connect |
|
Zero Trust |
Open ID Connect + Hardware Token + Client Certificate |
Traffic Shaping
The unique position in the architecture allows an API Management solution to be an active participant in traffic management. Traffic can be controlled by the gateway to enforce throughput maximums, protecting the backends from sudden spikes in traffic or sustained heavy loads. This "Traffic Cop" role helps ensure services remain accessible for most users even when under strain, helping improve service reliability.
Quota Enforcement
With some kind of application identification, the API Management proxy can also help enforce quotas for specific applications. Consumers can be granted specific consumption levels, and requests to the API endpoints can consume from those quotas. This helps enforce business contracts, and provides a basic mechanism for a commercial agreement between API consumers and API producers. Furthermore, quota enforcement helps to prevent abuse of the API endpoint in case the credentials are compromised, in that a quota ensures a maximum number of calls that can be made.
Transformative Capabilities - The Gravy
Beyond the basic functional requirements we expect from enabling an API Gateway, a full API Management system should be able to enable a variety of transformative capabilities. These capabilities can help transform the development process, operations management, and core business of an organization.
Development Transformation
Because API Management decouples consumption from production, it's possible to make changes in an API layer more rapidly than would be expected in a core IT system. This starts to unlock innovation options that do not exist in a traditional core IT system.
For instance, an API development team can make rapid changes to a set of APIs to respond to market needs by orchestrating multiple back-end API calls and consolidating responses into one logical response. This allows the consumer to be less concerned with the IT application estate, and more concerned with the data that the API represents and satisfy their users needs without having to understand the relationships between various IT system backends.
Teams can also rapidly onboard trading partners who have inflexible consumers, by rapidly deploying API facades. Consider a warehouse fulfillment center who needs to onboard a large, inflexible retailer. Without changing the back-end systems, an API Management system can help a development team create APIs that conform to this new partner's requirements without impacting any other trading partner's use of existing APIs.
Due to the decoupled nature of the API Management layer, development teams are free to innovate, unlocking velocity and enabling developers to support new businesses without risking change to the back-end systems.
To enable this transformation, your API Management layer should include features for multi-backend orchestration, payload transformation, header manipulation, and custom business logic execution.
Loose coupling and developer velocity are key to innovation and unlocking business opportunities.
Operational Transformation
The API Management layer, by virtue of its position in the architecture stack, provides operations teams new visibility into the health, performance, and security of the applications that rely on APIs.
Operations teams can use real-time and collective analytics to analyze traffic patterns and performance not just of the proxies themselves, but also gain additional insight to the usage of the overall system. A mature API Management layer should allow analytics that measure the response times of proxy logic execution at each step, backend response times and error rates. A fully realized API Management system will also be able to segregate traffic by consuming applications, such that an operations team can see typical traffic flows over time.
These metrics, when properly instrumented with outlier detection and alerting controls, can help keep operations teams proactively aware of the health of the overall system, such that system issues can be addressed before they impact the consumers and partners using the APIs for their business.
Smooth operations translate to higher levels of trust with your business partners, and greater consumption of your services.
Business Transformation
A fully realized API Management layer will have capabilities to package sets, subsets, and capabilities of APIs into salable packages that consumers can purchase. This allows commercial agreements to be based on a combination of consumption levels, capability sets, quota limits and other business arrangements. Furthermore, an API program will rely on infrastructure called an API Portal to document, promote, and allow the creation of application keys, secrets, and configuration of payment agreements.
When viewed through this lens, APIs are not integration methods, but rather revenue generating products. These API products allow an enterprise to monetize valuable systems, data and processes that exist, requiring no new feature development. A mature API Management system will allow safe, secure, metered, measured and monetized access to backends, effectively putting the business at the center of an API Ecosystem.
Furthermore, a mature API Management system will be able to enable business leaders to understand how API products are used through reporting. Product managers can see which services show growth potential, and which services lag behind. Account managers can track which developers are growing, and build outreach to growing clients. Executives can better track the value of investment in the API Ecosystem.
API productization and business-level visibility can enable new channels of business and new streams of revenue while reducing the friction of consumption.
The Transformation Process - The Work
The process of transformation must start with the decision to pursue APIs as a driver of the business. With this mindset, the creation of APIs becomes a function of product development. This point of view allows the API development team to be considered for longer-term program funding based on the business value of the API program, rather than as a typical IT oriented short-term project designed around cost savings or capability enhancement.
Next, a product owner needs to be identified to own the direction of the API product suite. The API Product Owner surveys the market, and works to understand how consumers would best make use of the product, and uses this information to prioritize features and functions to be sent to the development team. Simultaneously, the API Product Owner will organize API offerings into packaged products and ensure the documentation is properly displayed in an API Portal.
Using prioritized features from the product owner, an API Architect can specify resource pathing, and uniform design principles to create requirements for developers. The API Development team acting on these designs will create API proxies to back-end systems that fulfill requests and ensure the necessary business rules are met when accessing and returning data.
Finally, a mature organization will have an API Evangelist that creates buzz about the APIs that are being offered, and help developers (both internal and external) make use of the API ecosystem.
How to Get Started - The Beginning
Getting started has never been easier. Anyone can also create an Apigee Evaluation project, which is a trial Apigee installation with zero cost for 60 days. With Apigee Pay-As-You-Go pricing, there's no subscription negotiation or special licensing requirement. Just enable your Apigee infrastructure in your GCP project and start developing.
For more comprehensive help, see our Getting Started documentation and the Apigee - Google Cloud Community. See Apigee API Management pricing for more details.
