How organizations deal with gateways and management platforms has changed over the years — in some cases, quite dramatically. To bring together the often disparate systems and frameworks in an organization, some have turned to a concept known as federated API management.

The latest Postman State of the Report found that one-third of API publishers use multiple gateways. Federated API management has emerged to unify these gateways, making APIs more centralized, visible, and governed while also providing flexibility to individual teams.

Today, we’re going to look at this approach, as well as other approaches it competes with. We’ll look at why federated API management is appealing and give you some best practices to get started with this approach today!

The Problem of API Platform Management

The problem with API platform management is that a platform is necessarily a singular entity that is meant to fit across a lot of different use cases and deployments. There is a perpetual struggle between ensuring you can support a wide variety of development cycles and needs while still maintaining a certain amount of control, a high-quality framework, and a center of organization that can ensure this system is managed.

To resolve this issue, organizations have taken a lot of different tacts, each with its strengths and weaknesses. These various approaches are justified by focusing on specific attributes that need to be bolstered, but in many cases, these differences have led to increased confusion and complexity.

The Central Model

In this model, the platform is controlled centrally by a team whose sole job is to make sure the platform is managed and maintained. This is often referred to as a corporate model, as this is the traditional model for large organizations. A central repository of control is offered as a shared service, and any changes to this shared service must be approved and managed.

This approach has some significant advantages but is largely focused on governance, security, and compliance. Having everything centralized means it’s much easier to control and enforce standards, and additional reductions in redundant or one-off functions make this even more streamlined.

Of course, a purely centralized model removes control from smaller teams. When everything is centralized, you have very limited autonomy, which can make even small API decisions subject to a cycle of approvals, implementation reviews, audits, and so forth. This dramatically reduces velocity and, ironically, often results in a deviation from central control to get basic tasks done.

Self-Service API Model

The self-service model is a movement away from centralized control based on the idea of a decentralized user flow. This approach allows individual teams or developers to manage their APIs on a self-service basis with minimal oversight from a central authority. By using templates and documentation, the central body can guide usage, but they ultimately are just that — guides, not controllers.

This has some huge benefits for the smaller teams. This approach is exceptionally lean, making it fast to complete a task and easy to scale to the immediate needs. This can often result in increased velocity and greater flexibility for innovation and iteration.

Unfortunately, this process does have major downsides. While it removes the blockers inherent in the centralized approach, it introduces a lack of stability and governance at scale. This can lead to security faults, vulnerabilities, and a lack of stable, predictable consumption and development patterns.

Another huge issue here is the duplication of efforts and tooling. When an organization does not have centralized control, additional tools, resources, servers, and staff can be a regular part of the organizational spending. Shadow IT resources are the most common result of this, but adopting different tools for the same process is a close second, especially when teams are tracking the same metric but for different purposes.

Platform-as-a-Product

In an attempt to make a hybrid solution, the platform-as-a-product, or PaaP, model has developed as a complementary solution. This model treats the API management process itself as a product, with the API team providing the guidelines, documentation, and support for other teams to utilize the platform. This leads to pretty revolutionary perspectives on the platform, converting internal users into a sort of customer and prioritizing ease of use while standardizing governance and security.

This has some huge benefits, such as granting autonomy with a certain amount of control. This approach allows you to set a governance policy while allowing for iterative and innovative use of the core platform.

As with anything, however, this comes with costs. In the case of the PaaP model, these costs can be quite significant. Treating the internal platform as a product means high resourcing, investment in the platform, and a much larger team for support. You’re basically creating a product inside a product, which generates requirements like internal marketing and education, which don’t exist in other paradigms.

Another Option: Federated API Management

Faced with these choices, a new paradigm has emerged in the form of federated API management. This approach takes the best of all these models and attempts to present a paradigm that reaches teams where they are and with the tools they need to iterate and develop.

Salesforce defines federated API management as follows:

“API Federation is the set of design principles, tools, and infrastructure that make it possible to expose a set of services and event streams within a particular bounded context as a unified and consistent API for external customers, while allowing individual services within the bounded context to evolve and change without additional restrictions.”

Federated API management is a semi-decentralized approach in which APIs are managed by teams and departments within an organization. This management is similar to the central model, but is distributed to the teams actually using the product. Put another way, instead of centralizing the power into a single authority, the teams are made autonomous and given their own authority over their use and management.

This ultimately results in largely autonomous teams that are nonetheless aligned at the central level. Individual teams, such as development, security, or monitoring, can manage their own platform and tooling aligned against a central paradigm, allowing for greater flexibility while sidestepping many of the issues of decentralization.

Benefits of Federated API Management

Federated API management has some key attributes that set it apart from other solutions. Let’s examine some of the positive outcomes of a federated API management model.

• Decentralized autonomy: Each team or department can independently manage its own API, applying governance that is formed around its specific requirements and real-world environment. This allows for a greater fit to function and control over the deployment in situ.
• Global governance: Governance is based on guidelines and policies collectively formed by the teams and departments, but individually deployed as governance proper at the team level. This allows for some continuity between services and a level of standardization across the board, even when teams operate vastly differently.
• Highly collaborative: Because this process is decentralized, teams must work together, sharing best practices and data governance to ensure that each element works appropriately in the given use case but is extensible for other teams. This focus on flexibility instead of rigidity is built into the process itself.

Drawbacks of Federated API Management

The federated API management approach does have some specific drawbacks that need to be managed to make for an effective solution.

• Inconsistency and complexity: This approach is more complex than other solutions, and there is a chance this introduces additional inconsistency due to decentralized autonomy. Accordingly, you’ll need to spend some time to ensure that you are standardizing and setting some baseline governance and rulesets.
• High coordination needs: Federated API management means you’ll need to invest in high coordination and collaboration to make low-friction cross-functional efforts work with any level of quality.

How to Implement Federated API Management

There are a handful of different strategies for how an organization might deploy federated API management at scale. Still, broadly speaking, you can separate this process into a few common steps.

Establish the Centralized Gateway

Firstly, you must deploy a centralized API gateway, monitoring, logging, and so forth. Many solutions can handle this complexity of traffic, and they largely depend on what kind of infrastructure or paradigm you currently use. AWS API Gateway and Azure API Management are quite popular for teams sold on those specific ecosystems. At the same time, solutions such as Apigee or Kong offer agnostic solutions that integrate well with different flows and systems.

Once you have your gateway up and running, you’ll want to set up distributed access control. This will allow individual teams to have control over their aspect of the gateway, allowing for endpoint routing and service iteration for individual attributes from the distributed API services.

Set Up Your API Governance

Now that you have your base centralized gateway, you’ll need to start building a cohesive API governance strategy. Establish and document your practices for design, security, versioning, and so forth, and ensure that you have adequate documentation around data formatting, access control, and authentication as part of the core gateway interaction controls.

From here, you can look to adopt automated compliance checks using a variety of specifications and tools. It’s important to note that decentralized API development doesn’t mean decentralized security — this will be as much something you need to communicate as a development culture as it is a hard and fast rule, so setting your style guides and rules now will help establish that throughout the collection of services and endpoints.

Implement Decentralization

With our groundwork laid, we can get to the real work of federated services. Deploying decentralized developer portals where each team can publish their APIs will deliver your decentralized paradigm, allowing teams to own their iterative process and development space. Solutions such as Postman or SwaggerHub allow teams to publish their APIs as a part of the complete whole, and when governed by centralized style guides, you should be able to hit the right balance between centralized rulesets and decentralized development.

As part of this process, you’ll need to effectively deploy a distributed authentication and authorization system across your services. Next-gen identity management solutions can help get this up and running, and implementing general security policies such as OpenID Connect will allow you to ensure a corporate standard at the enterprise level. Most importantly, you must set the minimum secure expectations across the board, as any security system is only as good as its weakest part.

Provide Controls and Visibility

With your federated process going strong, it’s essential to add centralized tools back in where needed and where appropriate. A unified monitoring platform such as New Relic or Datadog can help you monitor the ongoing data across all teams, and you can use a variety of toolsets to generate central dashboards showing the overall health of the service. This will significantly increase your visibility across all teams while enabling them to develop according to their own needs and metrics.

You can also start to centralize data aggregation by examining how data is ingested. Using a proxy or simply logging interactions will allow you to collect data seamlessly without impacting downstream systems. You can also have data stored in a central lake but accessed via a shared services API. While this makes for a more complex data relationship, it does centralize data as a service rather than as a secondary attribute of each individual API.

To ensure the longevity of your system, you might consider shared CI/CD pipeline templates. Shared templates that enforce best practices will allow you to provide a basic starting block for all teams that can be altered and extended for specific use cases, establishing and enforcing best practices in areas such as security or deployment. These will have to be considered on balance, as too much central control through templating is just centralization with extra steps.

Document and Share Knowledge!

One major drawback of federating API management is that it trends toward siloing. When each team is left to its own devices to develop, only governed by templates or best practices, it’s possible to end up siloed and isolated at the team level. To get past this, teams will need to document their APIs and their ongoing work within a cultural expectation of sharing knowledge.

API documentation can take a few different forms, from weekly standups to ongoing knowledge documentation, but the process itself is what is more important than the format. By establishing a culture of documenting and sharing information and context, your organization will prioritize surfacing work rather than keeping it isolated, contributing both to the overall efficacy of your federation efforts and mitigating the potential siloing that can occur.

Final Thoughts

Federated API management is a powerful solution that can work in many contexts and business environments. With a bit of planning and forward-thinking, this approach can result in more empowered teams while also implementing central governance that is more effective at scale.

What do you think of this approach? Let us know in the comments below!