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.
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. 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 today.
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
In this article, which is based on my talk at VueConf Toronto 2023, we'll explore how to harness the power of Vue.js and micro frontends to create scalable, modular architectures that prioritize the developer experience. We'll unveil practical strate
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
The new Kong Konnect Dev Portal is now generally available for all users! In March, we announced the public beta version of our reimagined Dev Portal. We set out to fully address the needs of the modern API consumer as well as the needs of the moder
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross
