Guest post by Andrew Stiefel, Manager of Product Marketing for Secure API Connectivity Solutions at NGINX, part of F5
By now, most Platform Ops teams are familiar with API sprawl – shorthand for the compounding challenges enterprises face from the rapid, unmanaged growth of APIs. To combat API sprawl, many teams implement an API gateway, which acts as a central point to manage, monitor, govern, and secure APIs.
Unfortunately, even the best solution can spawn its own problems. Enterprises often end up managing API gateways from multiple vendors (e.g., from a cloud provider or on-premises API management vendor). Sometimes, we even see “shadow API gateways” deployed as individual teams roll out their own API gateways without clear governance.
With APIs as the data plane and API gateways acting as multiple control planes, countless problems can emerge in security oversight, performance monitoring, API schema, structure, and developer experience.
You Need a Consistent Management Plane
To address these new challenges, Platform Ops teams are creating an additional management plane that operates across their API infrastructure. While these tools go by different names, they all seek to manage API connectivity and security across the entire enterprise while providing a single viewpoint for all API traffic.
In theory, this is a good solution. In practice, many platforms and vendors tightly couple their management plane capabilities with their API gateways. This adds to the sprawl chaos – unless the management plane embraces open standards for API operations.
Innovation Leads to Standards
APIs have been around for decades and are a ubiquitous part of the software landscape. According to statistics shared by Mark O’Neill of Gartner, 98% of organizations are currently building private APIs (up from 88% since 2019).
API sprawl suggests we are entering a new phase of standardization to simplify API design, operation, governance, and security. However, as innovation and adoption accelerate, and the technology reaches scale, new problems arise: How do you ensure interoperability? How do you reduce complexity for end users?
As an aside, it’s worth noting that standards are distinct from regulation. The traffic light is a good example. Borrowing its red and green signals from railroad switches, the first traffic light was manually operated with a switch. By 1930, most US cities had at least one traffic light. Over time, varying traffic light regulations emerged at the state and local level, but the standard (red and green lights to operate traffic) had already taken hold.
In the case of APIs, standards develop at multiple levels, from teams to enterprises to industries. Forward-looking management plane solutions and API gateways incorporate the following three principles into their products.
1. Contract-Driven API Operations
More components are at play in the typical enterprise API landscape than a Platform Ops team can be expected to keep track of day-to-day. Embracing and adopting a human and machine-readable API standard (or, in this case, specification) helps teams understand, monitor, and make decisions about the APIs currently operating in their environments.
At the heart of this approach is the API contract, a document outlining how an API will function with defined specifications and requirements. It embodies the agreement between the API provider and consumers. By necessity, this document often uses one of three common API specifications, depending on the type of API:
- OpenAPI – JSON or YAML descriptions of all web APIs and webhooks
- AsyncAPI – JSON or YAML descriptions of event‑driven APIs
- JSON Schema – JSON descriptions of the schema objects used for APIs
Critically, standards like the OpenAPI Specification (OAS) can be reused throughout stages of the API lifecycle – including design, documentation, testing, deployment, and security. This simplifies collaboration as different stakeholders (API owners, QA, DevOps, SecOps, etc.) interact with the API.
Although many organizations are still in the early phases of their API-first journey, moving quickly to adopt contract-driven API operations can increase the efficiency, reliability, and security of their APIs.
2. Policy-Driven API Gateways
One of the biggest challenges teams encounter when operating multi-vendor API infrastructure stacks is dealing with inconsistent approaches to applying policies for security and governance. For example, your cloud provider might use one set of admin APIs and policies for their gateway, while your on-premises API management tool has its own set of admin APIs and policies.
Fortunately, new solutions are available to enable Platform Ops, DevOps, and SecOps teams to configure and apply policies regardless of the underlying infrastructural components. For example, Open Policy Agent (OPA) is a policy engine that allows developers and platform operators to apply rules that govern how different pieces of infrastructure work together. It creates a single policy layer that can interface with the various tools present in your infrastructure.
OPA is a Cloud Native Computing Foundation (CNCF) graduated project, While support for OPA is most widely adopted within the Kubernetes ecosystem, it is increasingly being adopted for other use cases, like REST APIs and GraphQL APIs. Additionally, it can be configured at both the API gateway and the service level.
3. Industry-Driven API Standards
Over the past decade, new industry standards have started to emerge. The financial services and healthcare industries have been among the first to develop industry-wide standards to facilitate the interoperability of data via API.
In the financial services industry, the Revised Payment Services Directive (PSD2) was implemented by the European Commission. It provides a set of rules that banks must adhere to when building and using APIs and is designed to create a more cohesive payments market. PSD2 is supported by a variety of technical API standards, although the most influential might be Open Banking UK. While it’s not an official standard in the United States, many U.S. banks and financial institutions are adopting open banking standards.
The healthcare industry has also embraced technological standards. Development of Fast Healthcare Interoperability Resources (FHIR) began in 2012 to meet needs for faster, easier, and more secure methods for rapidly exchanging healthcare data between systems. FHIR is an API-focused standard built on REST APIs. Since the REST architecture does not directly address privacy and security elements like authentication and authorization, the FHIR standard sets additional requirements.
FHIR also opens the healthcare industry to data sharing and innovation while giving consumers more power to manage their health records across providers. Standard definitions for each API help ensure that the information being shared is accessible to others by mandating regulated data elements, all secured with OpenID Connect and OAuth 2.0 identity and access controls.
Industry-driven standards encourage interoperability and provide a standardized approach to ensure security and privacy safeguards are implemented. But they also require developers and organizations to invest in additional work to meet those standards. For example, how do you cache APIs that may contain Protected Health Information (PHI)? And how do you securely expose APIs to developers through portals, or other tools as they are building integrations, without displaying health information?
Cloud providers are already working to build services configured to work with FHIR data, but platform-agnostic API gateways and management providers should also provide policy-driven approaches to help customers quickly configure their tools to meet emerging industry standards.
Conclusion: Standards are the Future of API Operations
In summary, adopting API standards can benefit Platform Ops teams by reducing complexity and efficiently scaling API operations across different teams and infrastructure. Many of us prefer to reinvent the wheel rather than adopt existing standards or implementations, but standards help elevate our work so we can tackle more interesting problems.
By establishing common standards for working with APIs (such as the OpenAPI Specification) and tool-agnostic standards for applying policy (such as Open Policy Agent) enterprises can start to build a single management plane that ensures interoperability and consistency across complex architectures.