The 2025 LEAP 2.0 API governance conference looked at API governance from all angles – including in relation to developer autonomy. We gathered together professionals from across the industry to consider how platform engineering can strike the right balance, putting much-needed guardrails in place without tying developers’ hands.
Tyk’s Sedky Haider and Carol Cheung, along with Syntasso’s Abby Bangser and tech journalist Jennifer Riggins, led a fascinating panel discussion examining this topic. We’ve pulled together key insights from their session below. Read on to find out:
- Whether platform engineering is just a bigger, better DevOps
- What the pain points of excessive develop autonomy are
- How organizations can choose the right governance model
- How to manage governance across multiple API vendors
Is platform engineering a better DevOps?
The discussion began by looking at DevOps, site reliability engineering (SRE) and platform engineering – three philosophies that have increasingly turned into much-needed roles in recent years. All three are lenses on how to build and operate software, approaching the task with different criteria and priorities in mind.
DevOps is all about how to enable a team to work independently – to give them full control over the development operations process. Think full stack, with a team that can be fully autonomous in building and running the things they need to, and in delivering value.
At the other end of the spectrum is SRE – a modern version of a “throw it all at the wall and see what sticks” mentality. Things have to meet a certain threshold, then there are operators who can support that.
Platform engineering sits in the middle, balancing things out. It takes DevOps and tries to make it sustainable at scale, shortening the stack that the team has to build and run – of what they’re focusing on to deliver value for. Instead of starting thinking at the networking level, they can start from existing networks, existing compute and existing data storage. It means they can focus on the part of their application that delivers most business value.
At the same time, the people providing that compute, networking and so on (the platform team, usually), are also employing DevOps as a methodology to build and run their services.
Will platform engineering absorb DevOps and SRE?
Looking ahead, does the rise of platform engineering teams signal a move to ultimately absorb DevOps and SRE into the same function, or can the three continue to exist independently?
The approach of most enterprises seems to be to have both a platform team and an SRE team. These functions seem to help fulfill the promise of DevOps, even though there might not be a specifically named DevOps team. The titles and perspectives are evolving, but the DevOps process continues, with platform engineering, SRE and DevOps each bringing their own value and nuance. DevOps brings autonomy, platform engineering shortens the stack and SRE supports the operating model in production.
The pain points of excessive developer autonomy
An imbalance between these three elements brings risks. For example, the explosion of tools and cloud native computing gave developers enormous autonomy in API design (and microservice design). Many of these tools were open source or free, leading to both tool sprawl and API sprawl. This resulted in financial cost and cognitive load, with many developers spending large parts of their day just looking for things.
Excessive developer autonomy also brings the risk that developers may not understand the business alignment behind the APIs they’re creating. This can eventually lead to a lack of awareness about what data is going in and out of the organization, why things were created, who owns what, which API does what and so on. The result is a loss of reusability, lack of consistency around error codes and a lack of standards and enforceability.
Better API governance not only combats this, it gives you a competitive advantage. Developer autonomy is no bad thing, but API platforms provide the golden paths and easier-to-follow standards that support autonomy within a robust governance framework. It enables you to automate mundane, repeatable tasks that you can reuse when creating APIs, to have a database, to know who’s doing what and much more. A decent platform provides a searchable interface with excellent discoverability, which enables developers to focus on creative problem-solving and differentials.
How to enforce API governance
You can enforce API governance through policies and approval request flows or embed it into developer workflows through automation and tooling.
The automated approach is popular with many developers. After all, when you’re shaping code quickly you want to remove all blockers, so automated checks can help. They can build in transparency and improve confidence around shipping code – because developers can know they’ve built it in a way that complies with all mandatory security and compliance regulations. Yes, you can use menu checklists or code reviews to achieve this, but that doesn’t scale easily, so automations and tooling make sense.
Automated, immediate feedback right in the IDE means developers can correct any mistakes while they’re writing an API service or configuring their API or API management platform. It takes care of mistakes before the API is deployed. This turns automated feedback into an important educational loop and supports developers to comply with policy documentation and to learn the requirements of that documentation without constantly rereading it.
A platform engineering team is perfectly positioned to set up these golden paths, automated checks and tooling. They can build guardrails that enforce policy rules and ensure everyone complies with all mandatory requirements.
This serves to close the feedback loop that is so important to the developer experience. Having to wait around for feedback breaks developers’ cognitive flow and their workflow. Faster feedback helps them succeed, with all the positivity that feeling successful delivers.
It’s important to remember that a lot of what we’re talking about here is a people problem, not a technology problem. Rate limiting is a technology problem, but governance, federation, sprawl… these are people problems.
A centralized platform also provides for effective monitoring, with feedback going to the team setting up the policies. This measurable data supports the platform team to evolve those policies over time, in response to both shifting team needs and changing regulatory requirements.
How do organizations choose the right API governance model?
Different governance models work for different businesses. After all, while APIs are everywhere, each organization and its approach to how to manage its APIs and get value from them is unique.
When it comes to choosing between centralized and distributed/federated governance models, factors such as organization size and regulatory requirements make a big difference.
A small organization, for example, can absorb a lot more rework across teams because there are only so many teams doing the rework. This is where the DevOps model really thrives because every team can do what they need to do in an unblocked and autonomous environment. They can be excited about their work while absorbing the duplication of effort due to the organization’s smaller scale. For larger enterprises, this approach is more problematic.
Similarly, lower regulation environments have less urgency when it comes to (for example) hatching a new security concern or changing to meet a new government regulation around personal data. For those that are more highly regulated, the ability to track what’s happening and where, to enforce changes and to meet new regulations from a position of central access is far more important.
When it comes to choosing the right API governance model, consideration of these elements – control and access, and managing them over time and at the appropriate scale – will ultimately drive much of the decision-making. If the decision is for a centralized approach, the conversation then needs to shift to how you can implement a centralized model without blocking people.
As companies mature and scale, many move towards a federated model, though not always on purpose! A centralized platform team can support this approach, providing a foundation that different teams can build upon to meet vastly different needs, and potentially even with different guardrails for different teams.
Managing governance across multiple API vendors
Looking at a practical example, Tyk often works with customers who need to enforce robust governance while managing multiple API gateway vendors.
In these situations, the first need is to understand why there are multiple gateways; whether it’s the result of organic growth, because of integrations, needs or acquisitions, or a deliberate choice.
Next, it’s time to visualize the data and build an inventory of all the API gateways the organization is using, and which APIs are running on which gateway, along with any unique use cases for any of the gateways. This might reveal an opportunity for consolidating everything into a single platform, or it could show a real need for adopting a mixed vendor approach. In most cases, simplifying operations and reducing costs through consolidation makes sense.
Deciding to move to a federated API repository can bring key benefits in this situation. It can help organizations to discover all the APIs they have running on different platforms, understand each gateway’s strengths and weaknesses and consider security enhancements, integrations and other factors. A universal governance tool that helps set and track compliance status across all platforms can also be really useful here.
Consolidation can also help platform engineering teams navigate the complexity and fragmentation of the API management landscape. Across the sector, there are no common standards and no common language that apply to all security standards, middleware, observability, performance or documentation. So, it places a great burden on platform engineering teams if they are expected to implement high-level organizational governance requirements across a whole bunch of vendor-specific configurations and specifications.
A centralized management tool that can provide federated API gateways certainly makes sense in terms of abstracting all those complexities and managing the different platforms underneath. *cough* Tyk *cough*
Want to find out more about balancing effective, robust API governance with the ideal level of developer autonomy? Then it’s time to speak to the Tyk team.
