This is for the APIM nerds, the CTO perps, and the platform geeks… federated API management is the new term on the block that has made a splash with industry insiders, and now everyone and their pet chupacabra is trying to get in on it.
But WTF is it?
It’s best illustrated by a story, all about how – my life got flip-turned upside down, so come along and sit right there, as I tell you the story of how I became the prince of…. federated APIM?
// Beat drop
In the world of APIs, where data’s the craze
Managing endpoints takes up most of my days
Setting policies, governing, securing’s the rule
To ensure integration stays sharp and cool
But policy issues, all complex and unfair
Started bottlenecking our teams everywhere
We got one big challenge, and the team got scared
Said, “Let’s federate the APIM and centralize the care!”
(I’m so, so, sorry… my kids still think I’m cool, I think)
Imagine you are the CTO of a large multinational that has many subsidiaries, you’ve grown organically as a company, and you’ve always followed an API-first strategy. All of your subsidiaries have APIs and monetise them or extract value out of them in some way – yet all of them are managed by different teams, with different software, and different stacks. But you are regulated! You have strict IT and security standards you need to follow, so how can you bring all of this into line?
Call McKinsey!
No, wait. Stop! Instead, you could implement federated APIM – where instead of a multi-year, billion-dollar programme of work that centralises your API management to a monolithic solution that doesn’t fit and pleases none, you instead find a solution that lets you work with the chaos and embrace all of those different stacks? That’s federated APIM. It enables your teams to continue doing what they are doing, and being productive, while allowing you and your team to have a layer of governance and oversight into how they are doing it.
Federated APIM gives you a view over your API estate, regardless of how it is implemented and how it is managed, across teams, geographies, and jurisdictions. It enables you to ensure security, policy, and governance standards without having to centralise management, build a new team, or replace software or methods.
That’s the dream, anyway
Vendors in the APIM space take one of two approaches when it comes to implementing this:
- Consultative with software support – here you buy a bunch of professional services for a customised solution based on an existing stack.
- Off-the-shelf – here you buyanother APIM solution that then centralises management and puppeteers your federated APIM estate.
The first option is expensive, time-consuming, and most worryingly – bespoke. Great for the vendor but terrible for you, because it saddles you with mountains of technical debt to unwind should you wish to change strategies. Which you will, admit it.
The second option is “centralization-by-proxy”, where a vendor insists that your wider estate can continue working independently, but because their command-and-control federated solution also enables you to control your team’s stack, it eventually encourages centralisation, one of the factors you are trying to avoid (Or on the flip-side, offers yet another platform to manage! Relevant XKCD)!
Both options are a poisoned chalice
In my opinion, the way forward for federated APIM is through open standards and existing solutions.
For example, we already have an excellent, existing, centralized format for documenting APIs: The OpenAPI spec (and for asynchronous APIs – AsyncAPI). It is a mature and well-understood format, and is widely used as a transport format in the APIM space. This should form the backbone of any federated APIM governance solution.
For policy enforcement, there already exists an excellent policy engine, that is open source and well understood: it’s called the Open Policy Agent, it even comes with its own generalised, policy-focussed scripting language for writing policies for any type of artefact called Rego.
The way to really make federated APIM a reality that isn’t a horror-show of vendor lock-in is to embrace both of these things in your wider APIM strategy.
APIM vendors should embrace the OAS spec, and should stop hiding their API specifications behind proprietary formats. Getting an OAS spec out of any vendor (shameless plug – except for Tyk, Tyk uses OAS as its default configuration format) is like trying to eat nails.
Secondly, APIM vendors should embrace cloud-native tooling that already does a great job and can deal with this work for them in a generalised, shareable, and re-usable way.
A single pre-save callout to an OPA agent would enable a governance team to quickly and effectively enforce standardized governance and security policies across any API stack without further need for vendor integration, or risk centralization drift.
If you’re talking about federation, then use federated and open tooling to make it possible, anything else is just centralization-by-proxy and a con.
