We want our engineering teams to move fast and be agile, yet many organizations confuse ownership of the infrastructure with ownership of the policies. The latter is what engineering teams want to rapidly iterate and develop their APIs. The former is the responsibility of the platform team.
In this post, we'll talk about how to empower engineers with a secure API infrastructure strategy. This is part of a series on becoming a secure API-first company. For a deeper dive, check out the eBook [Best Practices for Becoming a Secure API-First Company](https://konghq.com/resources/e-book/become-api-first-company)Best Practices for Becoming a Secure API-First Company.
The engineering team’s responsibility is to build captivating products and user experiences while being able to [iterate fast on API policies and ship them out quickly](https://konghq.com/blog/engineering/how-to-manage-your-api-policies-with-opa-open-policy-agent)iterate fast on API policies and ship them out quickly. Typically, they need a subset of capabilities that a modern API infrastructure can provide:
On the other hand, there are some components that engineering teams shouldn’t own:
As the buyers of API infrastructure technology, it’s important to assess that the technology allows for both infrastructure and configuration segregation to simplify the deployments across the organization. This ensures simplified deployments across the organization with a unified control plane, while still compartmentalizing the data plane infrastructure and the applied configurations:
Without a solid strategy in place, engineering teams will go ahead and develop their own customized solutions for managing API infrastructure. In doing this, teams will unknowingly promote shadow IT bad practices, a lack of control and scale, inefficiencies across the organization, and an increased risk for security vulnerabilities. It’s a bad move.
Obviously, we can all agree we don’t want our teams to be slowed down by inefficiencies and bottlenecks. But it doesn’t have to be this way. The solution? The platform team gives engineering teams some autonomy to apply policies while still managing the underlying infrastructure on their behalf (at the API management and service mesh layers). This requires planning. And sometimes it may seem easier to just delegate the whole setup to the engineering teams, but that will inevitably lead to catastrophe.
It’s our corporate responsibility to fully own the API infrastructure without delegating to our people a massive area of responsibility that they won’t be able to properly address in conjunction with their other tasks.
As our applications evolve from monolithic to microservices, networking requirements become more critical for our applications. We’re essentially replacing the reliability of the CPU in monolithic applications with the unreliability and security issues of the network in microservices. Of course, this is in exchange for better scalability, resilience, and agility.
The evolution of our applications to microservices has created more API traffic than ever before, at an unprecedented scale.
Kong provides both infrastructure and configuration segregation for hundreds of top Fortune 500 and Global 2000 organizations that have deployed a single pane of glass to manage API infrastructure across every team, while still allowing developers to be quick and agile in their rapid iterations.
Want to see how Kong can help your organization balance agility and security? [Get a demo](https://konghq.com/contact-sales)Get a demo today.
The challenge: A disconnected world Consider the typical enterprise architecture in a relatively mature organization, an API management layer defines and deploys services to an API gateway, an Identity Provider (IDP) manages human user identities, a
[](https://konghq.com/blog/enterprise/api-management-and-identity)
APIs have become fundamental to the digital economy, enabling integration and communication between different systems and services. A mature API platform is not just a technical achievement but a strategic asset that can drive innovation, efficiency
[](https://konghq.com/blog/enterprise/api-platform-engineering-maturity-model)
In the rapidly evolving world of API management, the conversation around "the great unbundling of API management" has recently gained traction. This movement, highlighted by industry experts and analysts, including a recent Forbes article , reflect
[](https://konghq.com/blog/enterprise/incremental-buy-in)
As API adoption continues, early autonomy incentives often have led to shadow IT and infrastructure sprawl. To secure our growing API attack surface, technology leaders must implement organizational accountability through security oversight, platfor
[](https://konghq.com/blog/enterprise/culture-accountability-application-development)
Imagine 47 million requests hitting your platform last month. Can you prove who made each one—and invoice with confidence? If that question tightens your stomach, you're not alone. Metered billing for APIs promises fair, transparent pricing that s
[](https://konghq.com/blog/enterprise/guide-to-metered-billing-for-apis)
In large organizations, platform architecture tends to be more historical artifact than intentional design. At the foundation of the stack sit monoliths that predate modern API standards; many of them are too risky or too costly to decommission full
[](https://konghq.com/blog/enterprise/api-composition-packaging)
This is the pitch to the board and the C-suite. It must be brutally concise, focused entirely on your business outcomes, not the technology. If the first page doesn't articulate value, the strategy dies. Why? It immediately frames the initiative in
[](https://konghq.com/blog/enterprise/enterprise-api-strategy-legacy-modernization)