As the need for speed in business can seemingly be at odds with the need for control, organizations developing APIs today face a critical challenge: how can you empower developers to build and deploy APIs quickly while maintaining enterprise-wide governance and security?
More traditional API deployment approaches are often to blame for why API initiatives fail to deliver the promised benefits as complexity and scale increase.
In this post, we'll explore three API platform deployment models — siloed, centralized, and federated — and dive into why federated API management may provide the optimal balance between developer agility and organizational control that disruptive organizations seek. Plus, learn more about the practical steps to transform your API strategy from a bottleneck into a business accelerator by enabling self-service API infrastructure.
Federated API management offers a middle ground between rigid centralization and chaotic decentralization. Watch this on-demand webinar to learn more!
Let's start out by considering the motivation for building an API platform. The fundamental goal of an API platform should be to raise engineering standards and build higher-quality APIs.
Raising API engineering standards comes with many noteworthy benefits:
In order to achieve the benefits covered above, an API platform should do the following:
With some of the core tenets of the platform now laid out, let's dig into the operational approaches to managing an API platform.
Looking to find the right API platform or gateway for your needs? Check out 5 Questions To Ask Your Vendor.
Organizations commonly relied on two organizational models for deploying API platforms in the past: centralized and siloed. Each approach comes with its own unique set of advantages and disadvantages. But in recent years, a hybrid federated model has emerged that offers more of the benefits with fewer of the drawbacks. Let's first look at the two traditional API deployment models: centralized and siloed.
Watch this on-demand webinar to learn more about how a federated API model promotes enterprise-wide API consumption and adoption, democratizes platform innovation, and liberates business units to build applications in the environment of their choice.
In a siloed (or decentralized) operational model, each line of business has complete control over its development stack. It's really a true DevOps shop. We see this often with conglomerates with 10 or more business units.
In this model, a central team (at most) 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.
A siloed model can come with some major risks for the business.
For example, if you're doing a SOC 2 review, it's going to be hard to get to know what each service is doing and it could take months (or longer) to go and collect every single thing that you need because there's no standardization.
This can become a big security risk too, if you don't have, for example, rate limiting or API keys automatically added.
Another big negative is that sometimes if you switch teams, it's like joining another company for the developer because they do things completely differently — it may be a whole new onboarding process. This makes it hard to become an agile, innovative organization as you lose the ability to easily adjust talent and resourcing depending on the needs of the business.
Lastly, reuse goes down because not everyone's documenting the same things — if they document at all. This can be frustrating for developers who often just end up writing their own stuff to work around not finding those other services.
The centralized model is a top-down approach. This is where a centralized IT team owns everything — a shared services team is responsible for the ownership of the platform, including infrastructure, configurations, policy, and governance. Each line of business delegates these things to that centralized work. Sometimes they're known as "centers of excellence."
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.
This is better for standardization compared to the siloed model, but it can be really painful for development teams. Imagine you want to change the rate limiting for your application — you can't just do it yourself. Often you're going and writing a ticket and then waiting for the centralized team to make those changes for you.
If you need a new API provisioned or you want something unique but you're not the most important line of business at the company, you might be stuck waiting for a long time (or indefinitely).
Both siloed and centralized have their pros and cons. You either have more of a developer-focused model or a more corporate standardization / security-focused model looking at the overall organization but being much slower. A federated model attempts to strike a balance between both with minimal downside.
Instead of one team spinning up infrastructure, configuring policies, and so on, the federated model enables individual stakeholders — developers or dev teams — to stand up their own runtime infrastructure . . . with some caveats that we'll get into later.
Want a deeper dive into how a federated model and self-service could work in your organization? Watch our on-demand Guide to Federated API Management webinar.
When we think about self-service API infrastructure for developers like we need for a federated model, a potential challenge could be governance. How does the central IT team or platform team retain control? Guardrails ensure that the distributed activities all consistently meet the governance policy and compliance requirements of the business.
Let's consider an example that helps illustrate the need for both a federated model and self-service. Developers have different API use cases. For example, say you have a developer who has a backend REST API. They're looking for an API gateway to protect this API — to enforce a rate limit and use JWT authorization. This developer could build all that logic themselves, but they want to rely on a prebuilt API gateway and prebuilt API authorization and rate-limiting logic.
In the centralized (or central) API team model, that developer might then ask someone on the central API team to spin up gateway infrastructure. And along with that gateway infrastructure, the team might go ahead and build a gateway service or a gateway API for that dev gateway service with the proper logic.
This becomes a real bottleneck for organizations as they scale. This is just one developer with one API use case. Multiply that single developer's use case by hundreds of requests from multiple developers, and the central API team can become a bottleneck where devs have to end up waiting days, weeks, or months to get their specific requirements met by that central team.
This is where the federated API platform model comes into play. There's still a central team — typically, now you're talking in terms of your platform team — and they build a central API platform.
In this API platform, self-serve options for gateway infrastructure. Developers can now use this platform to spin up infrastructure for themselves. While this could sound scary; the whole reason the centralized model became so prevalent was to have some level of control. But it doesn't mean you're embracing API anarchy.
The right API platform includes guardrails to make sure that any piece of infrastructure that is spun up is done so based on corporate standards and security policies and in the environment of their choice.
As a massive bonus, the API platform can also grant shared services and central IT teams a real-time, centralized view of all their services and runtimes — offering visibility into things like error rates and throughput for each runtime, service, and route.
While developers are now tasked with serving themselves, it enables developers to spend more time writing code and less time maintaining the infrastructure — which in turn cuts time and effort in getting services into production.
In this 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, a central team is 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: The 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 section, we’ll touch upon how Kong Konnect delivers on the promise of the federated API deployment model.
In the ever-evolving world of digital transformation, APIs have become the backbone of modern applications and services. As organizations embrace microservices architectures and distributed systems, managing APIs effectively and securely becomes a paramount concern. Enter Kong's Konnect platform, a cutting-edge solution that empowers enterprises to achieve federated API management at scale.
At the core of Kong Konnect lies a powerful control plane that serves as the central configuration hub for your API landscape. This control plane enables you to define and enforce enterprise-wide policies, security standards, and operational guardrails, ensuring consistent governance across your APIs.
Complementing the control plane are the runtime components, known as data planes. These data planes are infrastructure-agnostic, allowing you to deploy them seamlessly across on-premises environments, public clouds, or even as a managed service from Kong. This flexibility ensures that your APIs remain in close proximity to your applications, optimizing performance and reducing latency.
Kong Konnect is packed with features that streamline and simplify API management. Embracing the "everything as code" philosophy, it enables declarative configuration management, ensuring consistency, auditability, and reproducibility across your API lifecycle.
Role-Based Access Control (RBAC) and control plane groups strike the perfect balance between centralized governance and distributed ownership. Global policies and standards can be enforced across teams and environments, while still granting teams the autonomy to manage their API configurations independently.
The platform also boasts a rich ecosystem of out-of-the-box plugins and third-party integrations, covering authentication, security, traffic control, serverless, analytics, transformations, and logging. This extensible foundation empowers you to tailor the platform to meet your specific requirements.
Moreover, Kong Konnect seamlessly integrates with popular automation tools and CI/CD pipelines, enabling you to automate various aspects of your API lifecycle, from design and validation to deployment, testing, and monitoring. This automation capability accelerates time-to-market and ensures adherence to best practices across your API landscape.
With Kong's Konnect, organizations can embrace the power of federated API management, unlocking agility, scalability, and consistent governance for their digital initiatives.
Ready to dive in? Get a demo and see how Kong Konnect can transform your organization.
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
In February 2024, Kong became the first API platform to launch a dedicated AI gateway, designed to bring production-grade performance, observability, and policy enforcement to GenAI workloads. At its core, Kong’s AI Gateway provides a universal API
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross
Unify the API and Eventing Developer Experience with the Kong Event Gateway and API Platform Introduction: The EDA and API worlds are converging . . . finally For the past several years, there have been murmurs of an incoming convergence between API