(Photo : From Pexels)
If you weren't convinced already, there is now a Gartner Hype Cycle report specific to Platform Engineering. This makes it clear that it's more than just a fad - it's here to stay.
And, while there are many different types of technologies and methods listed in the Hype Cycle report, there is only one that made it into the "Plateau of Productivity:" Full Life Cycle API Management. Why is this? In this article, I'll give my personal take on:
-
Why FLAPIM made it into the report
-
Why FLAPIM should be a top priority for any Platform Engineering team
-
What Platform Engineering teams should consider when evaluating FLAPIM solutions
-
Why I think Federated API Management could very easily end up somewhere else on the report in future years
Full-lifecycle API Management is on the report, but why?
Disclaimer: Thoughts are my own and have not been approved or endorsed by Gartner.
(Photo : Gartner)
I have strong thoughts on why Full Life Cycle API Management- or "FLAPIM" as it's casually referred to - made it not just into the report, but made it into the report as the only stakeholder in the "Plateau of Productivity" section. It boils down to the fact that you can use FLAPIM for at least seven other methods/technologies mentioned in the report, e.g.
-
Internal Developer Portals
-
Internal Developer Platforms
-
Developer Experience
-
Observability
-
Infrastructure automation
-
AI-augmented Software Engineering
-
Product-centric delivery models
There's a lot here...and I could absolutely make the case that it could be used to address other areas (microservices, anybody?), so I won't dig too deeply into each, but here's a quick primer on how FLAPIM can be used to address these areas.
Internal Developer Portals
This one is easy. The API Developer Portal is a core component of FLAPIM (external portals, too, by the way). The API Developer Portal offers a simple, one-click API publishing solution for your APIs that you create and expose via the API Gateway.
Internal Developer Platform
This is another easy one. While internal developer platforms will include much more than just APIs, Platform Engineering teams are already leagues ahead with a functioning API Developer Portal that can be worked into their larger IdP strategy.
Developer Experience
When it comes to APIs and FLAPIM, the developer experience is typically all about the API consumer. This often includes speed to finding APIs, better API onboarding experiences, having API documentation, and having options for self-service API subscription-all of which is mediated and enabled by an API Developer Portal.
Full-lifecycle API Management solutions that have introduced a federated approach are drastically improving the Developer Experience for Platform Engineering teams by enabling them to manage, govern, and publish APIs from across the organization using a single API Management solution-no matter which API Gateways and/or event brokers those original APIs are deployed to. This eliminates the need for context switching between different API Gateways and Event brokers, and eliminates the need to build custom Developer Portals that can span heterogenous API Gateway and Event Broker ecosystems.
Observability
API Observability is one of the "final frontiers" for monitoring and observability practices. The Datadogs, Dynatraces, New Relics, and Prometheuses of the world have already done a great job of enabling monitoring of your applications and underlying infrastructure. However, there has been an "API blindspot" in much of the observability world, and the API Gateway and API Management universe has begun to solve this via two main approaches:
-
Native API monitoring solutions that enable you to set up observability and alerting within the API Management solution; this is typically driven by consumption metrics captured at runtime by the API gateway
-
Integrations with existing APM providers, where the API Gateway ships API consumption data off to APM providers, such as Datadog, for easy visualization and seamless integration into where the rest of your Observability practice is being implemented
Infrastructure automation
If you're thinking about the API Gateway as critical infrastructure (and you should-it's the layer exposing and protecting all of your APIs), then FLAPIM is important here. FLAPIM enables platform teams to use things like Management APIs and Kubernetes Operators to automate the provisioning of APIs and API Gateways as a part of a larger GitOps workflow. Eventually, it should become easy to add "API Gateway generation" as an asset into a larger Internal Developer Platform and have your FLAPIM solution spin up a Gateway exactly where you want it when your consumer clicks "Generate a API Gateway for me."
AI-augmented software engineering
FLAPIM plays two roles here:
-
Using AI as a force multiplier during the API creation, security, and exposure process, making API development and management a seamless part of the larger SDLC
-
Helping organizations better leverage AI via solutions such as AI and LLM proxies, prompt guards, and AI API generation
As the AI space continues to evolve, I imagine this will change and evolve as well. That said, LLMs-which will be exposed as API products-will need protective middleware, too, and FLAPIM has already proven itself in this arena. Solutions will just need to continue expanding into AI and LLM use cases.
Product-centric delivery models
"API productization" and "API as a product" methodologies are king here. FLAPIM will be the main driver here of taking a product-centric approach to API delivery, especially as it pertains to AI as API products. This will be enabled mainly via API subscription control, the ability to expose broad sets of backend services (such as event streams and LLMs) as APIs, and Developer Portals, where APIs can live as cataloged products for self-service discovery and subscription.
What's next? Federated API Management
Federated API Management is an approach to API Management that abstracts much of the core API Management functionality away from using any specific API Gateway or event broker. This enables organizations to centrally manage and govern their APIs within a single solution-no matter which API Gateways or event brokers are being used across the organization.
I wouldn't be surprised to see Federated API Management on a future hype cycle about Platform Engineering.
