See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
6 MIN READ
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.
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:
In order to achieve this goal, a platform should:
Now that we understand some of the core tenets of the platform, let’s review the operational approaches to managing an API platform.
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.
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.
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:
Most Kong customers are either operating in a federated model or have ambitions to transition to a federated model.
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
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.
Share Post
Learn how to make your API strategy a competitive advantage.