Federated API Management: Balancing Agility and Governance

Looking to develop more APIs faster (and securely)? Then you have some different API platform deployment models to consider. In this post, we'll define and compare the siloed, centralized, and federated API platform deployment models — and dive into why federated API management is key to striking a balance between agility and governance.

Introduction

Let's start out by considering the motivation for building an API platform. The fundamental goal of an API platform should be to raise the engineering standards in order to build higher-quality APIs.

The benefits of raising API engineering standards include:

• Faster time to market as developers will be able to build APIs faster based on better standards
• Robust security as the risk of an unsecured API being published is minimized due to application and enforcement of consistent standards
• Higher resilience as fault tolerance and reliability are among the primary considerations in building well-engineered APIs

In order to achieve this goal, a platform should:

• Use modern engineering tools and techniques including infrastructure as code and APIOps as well as inner sourcing
• Provide a low ramp for new internal teams to onboard onto the platform
• Minimize IT's operational and governance burden, and allow developers to focus on delivering core business value
• Evolve continually based on consumer feedback. For example, if an organization builds a platform designed for REST APIs, and a new team wants to develop with GraphQL, the platform should be flexible enough to support these new use cases.

Now that we understand some of the core tenets of the platform, let's review the operational approaches to managing an API platform.

Centralized Model

In a centralized model, a shared services team is responsible for the ownership of the platform. A single control plane exists for all teams inside the organization, and data planes are provided as a shared service to all teams. The central team is responsible for the platform’s operation, maintenance, and evolution.

Pros

• A single place for all API assets inside an organization helps to promote consumability and re-use of APIs
• Development teams do not need to be concerned with the infrastructural aspects of data planes
• Economies of scale as the central team is responsible for the maintenance and enhancement of the platform

Cons

• Shared service teams can quickly become a bottleneck as the single point of support for LoB users thereby slowing down innovation to further innovation
• Business continuity concerns with all APIs being deployed onto shared infrastructure
• Potential latency due to gateways deployed away from where APIs are implemented
• Limited ability to implement strict isolation between different business units

Siloed Model

In a siloed operational model, a central team creates a platform blueprint, which is translated into infrastructure as code. Business unit teams then consume this infrastructure as code to instantiate a fully contained environment including a control plane. Each business unit team becomes fully responsible for the maintenance of its specific platform.

Pros

• Fully isolated platform for each business unit
• Each business takes on the responsibility and overhead of running its own platform
• No dependence on a central team
• Each business has the flexibility to make modifications to the base platform according to its own needs and use cases
• Business units can drive innovation in the organization by submitting their enhancements as pull requests to be incorporated into the main codebase

Cons

• Siloed by design
• Limited ability to effectively socialize APIs for consumption and reuse throughout the organization as there is no longer a single place for all APIs to be cataloged
• No economy of scale due to shared infrastructure and operations
• Potential operational complexity due to enforcing group-wide upgrades / patching

Federated Model

In a federated operational model, a single control plane exists for all teams within the organization. For some small-scale users of the platform, data planes are provided as a service so that they don't need to be concerned about how their gateway infrastructure is deployed as a pipeline is provided to the teams that is capable of deriving gateway configuration from an API specification.

However, if we follow one of the core tenets of platforms as practiced by Kong, the shared data planes will be created using infrastructure as code and teams will be onboarded to the platform in a fully automated manner. This means that this infrastructure as code can be made available to other users of the platform who do want to manage their own infrastructure. In the federated model, the golden organizational image must be:

• Hardened
• With certificates installed
• Employ a universaL base image (UBI)
• Patched centrally and then rolled out automatically
• Connected to central control plane

Most Kong customers are either operating in a federated model or have ambitions to transition to a federated model.

Pros

• Single API catalog for all internal API assets to promote enterprise-wide consumption and adoption
• Economies of scale for small teams that wish to continue using shared service
• As all infrastructure components are delivered as infrastructure as code, business units can submit pull requests to the code base to democratize innovation of the platform
• Gateway patterns can be coded, exposed, and consumed in the environment of choice for each business unit (e.g., as a virtual machine, a container, or a K8s deployment)

Cons

• Operational complexities can be potentially introduced to ensure that the business unit teams update infrastructure in line with the organizational policy
• Requires a central platform function to maintain the golden images and control plane as well as to ensure consistent governance across the organization

How federated API management works

With federated API management, you have a central team responsible for creating the technical assets that can be consumed by developers. These assets may include API management best practices, tooling, and frameworks.

The central team essentially delivers infrastructure-as-code in the form of standardized patterns or templates that developers can consume.

For example, your organizational standards for APIs may include disabling HTTP, restricting certain SSL ciphers, and adding certificate authorities (among others). The template or the golden image delivered by the central team to the service delivery team in each line of business would already have these configurations enabled.

By simply deploying this golden image in the environment of their choice — whether that happens to be Kubernetes, public cloud, VMs, or hybrid — the service delivery team would ensure it has met all the governance requirements that the central team has mandated and now its instance is aligned with the single source of truth with regards to API configurations and telemetry data.

Federated API Deployment Model: Central team provides shared technical components, know-how, best practices, and enablement to service delivery teams

Benefits of federated API management

The federated model of API management balances standardization and DevOps principles that are desired by the central team with the flexibility craved by developers to deploy the APIs in the environment of their choice and according to their business requirements.

In the federated model, the developer becomes the operator by following the DevOps principles and utilizing the best practices and golden image provided by the central team.

The federated API deployment model delivers value for both central enablement and service delivery teams.

Under this model, the central enablement team produces infrastructure-as-code as the guardrail to ensure consistency, standardization, and compliance. But at the same time, it reduces its operational burden because now this team doesn’t have to run the data plane and the infrastructure as a shared service. The individual data planes are run and managed by their respective LOBs.

With the federated model, the central team also gets comprehensive visibility through aggregated analytics. Another advantage for the central team is that it helps them with continuity of operation.

For the service team responsible for consuming infrastructure-as-code, it’s all about architectural freedom and the flexibility to operate their gateway close to the APIs and microservices.

This reduces latency and provides flexibility to operate on the infrastructure of their choice.

The federated API deployment model also enables the service team to be more productive because now developers have to perform a smaller number of configurations to deploy their APIs because the majority of them have already been included in the golden image that they are consuming. The same golden image allows the service delivery team to be aligned with APIOps principles and follows standard development methodology and documentation.

In the next blog, we’ll touch upon how Kong Konnect delivers on the promise of the federated API deployment model.