Federated API Management: Balancing Speed and Control
Agility Meets Governance: Choosing the Right API Platform Deployment Model
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!
Why build an API platform?
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:
- 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
What to look for in an API platform
In order to achieve the benefits covered above, an API platform should do the following:
- 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 (e.g., 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)
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.
Models for managing an API platform
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.
Siloed model
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.
Pros and cons of a siloed model
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.
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
Centralized model
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.
The pros and cons of a centralized model
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).
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
Federated model
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.
The need for self-service API infrastructure
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.
The pros and cons of a federated model
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:
- 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, 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
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 section, we’ll touch upon how Kong Konnect delivers on the promise of the federated API deployment model.
Power up federated API management with Kong Konnect
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.
Robust components for seamless integration
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.
Feature-rich capabilities for agile API management
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.
Unleash the power of APIs with Kong Konnect
