If data is the new oil, APIs are the pipelines. APIs are no longer just the interfaces that let computer systems talk to each other — APIs are now at the center of the new business models. APIs, in the form of microservices, form the bulk of the backend systems at some of the largest enterprises across the globe.
APIs are truly ubiquitous in the digital world, outside the enterprises as well as within them. For instance, 60-90% of revenue for certain enterprises in travel and ecommerce industries comes from APIs, and data suggests that software developers spend 30% of their time building APIs. While it’s fascinating to witness the impact APIs have created, it’s essential to understand their downsides as well to understand their full potential.
Compared to traditional web applications, APIs can be more vulnerable to cyberattacks, primarily because they expose backend functions with relatively fewer abstractions. As the number of APIs increases, the threat surface for an organization increases proportionally. Adding to this problem is the fact that APIs are continuously evolving in terms of standards, design patterns, security protocols, and others, and this can make the entire API landscape immensely diverse.
This large, diverse, and unmanaged API landscape is often referred to as API Sprawl, a term used to describe the uncontrolled proliferation of APIs within an organization. While a large API estate can be an asset to an enterprise, it can very well be its most vulnerable component as well, as it can be an entry point to sophisticated and advanced security attacks.
The first step toward securing the API landscape is to manage API Sprawl, which essentially means having the right management and governance controls in place for an enterprise’s entire API landscape. While this is a vast problem to address, this blog focuses on a unique governance and operations model around API management that can help enterprises establish control over the API landscape in the right way.
Traditional Models of API Management
Traditionally, central IT teams have been responsible for the API development and management for an entire enterprise. Typically, this team owns an API management platform such as Google APIGEE, Microsoft Azure APIM, or others, and manages the entire lifecycle of APIs as per requirements of various lines of business (LOBs).
This model brings the obvious advantage of centralized API governance. It also promotes the standardization of end-to-end API lifecycle management — design templates, coding standards, documentation standards, versioning, testing strategies, deployment, security policies, monitoring and analytics, and retirement. While this certainly provides robust control over an entire API landscape, this may not be a favored model for enterprises that seek faster time-to-market, frequent releases, and multiple API deployments, as a centralized team can prove to be a bottleneck, impacting agility.
An obvious alternative could be a siloed model. Given the number of APIs being developed by every team within an enterprise, it may be prudent to empower individual LOB teams to develop and manage their APIs on their own. While this model can infuse significant agility, standardization and governance may suffer, eventually leading to a chaotic API landscape.
The Federated Model of API Management
To leverage the best of both worlds, a new federated model of API management is gaining traction across enterprises. This model stresses having a central team to establish and oversee API governance, whereas API development is decentralized and democratized to smaller teams and/or LOBs. This model strikes the right balance between the standardizations of API lifecycle management and API development agility, offering a promising solution to the challenges of API sprawl.
There are largely two approaches to achieve the federated model (see Figure 1).
The predominant approach is that LOBs employ the API management (APIM) tools of their choice, and a central IT team employs an APIM tool with connectors to APIM tools at LOBs. This means that each LOB can use the API management tool that best suits their needs, while the central team can still maintain oversight and control. Leveraging the connectors, the central team can establish a single pane of glass to oversee APIs across LOBs, and this control pane can be further used to configure security and compliances across the entire API landscape.
An alternative federated model approach is that a central team establishes best practices for managing the API lifecycle, and codes them into an Infrastructure as a Code (IaaC) template. This template is leveraged by LOBs to establish their API management platforms. This approach leads to even stronger control over the API landscape, but it can be challenging to implement it in a scenario wherein LOBs use different vendors for API management.
Adopting the Federated Model
Federated API management is garnering enterprise attention and investment, a trend that is evident as multiple vendors are releasing features around this model. For example, APIIDA, Axway, and Software AG have all released a control plane offerings which can connect to API management tools from different vendors and present the entire API landscape on a single pane of glass. Similarly, Kong Konnect offers features around the second approach described above.
At Persistent, we have proven expertise in helping our clients manage the API sprawl. We provide consulting and implementation services to some of the world’s largest banks in the US and the APAC region for managing diverse API landscapes. Learn more about how Persistent can help your enterprise with the necessary tools and strategies to rein in API Sprawl.
