Josh Twist is the co-founder and CEO of Zuplo. In this article he discusses how API management that we know today, is broken.
In the past, I’ve been a vendor and a customer of API management products. When I worked at Microsoft, I founded several services: Azure logic apps, Power Automate, Pro mobile services, and most notably, Azure API Management, which we created through an acquisition of a company called Epiphany. After that, I was head of product at Facebook, where I learned Facebook analytics and new experiences organization. Then, I was head of product at Stripe. I have a lot of experience working on APIs and have many opinions about API Management API Gateways.
The ultimate goal of API Management is to ship better APIs. Shipping better APIs serves higher-level goals, like increasing monetization and reducing support costs. Better APIs mean secure, compliant, consistent APIs and have a great developer experience, discoverable, and observable.
How do APIs get better? There are two angles to looking at this. One is governance, which is ensuring that the APIs that we ship meet a certain threshold of quality that we have defined as an organization. So that might be that the security posture is correct, the rate limiting is in place, etc. So that’s governance. But in reality, software, including APIs, gets better by having an optimized development process with a tight feedback loop. We all know instinctively, as developers, that a tight feedback loop matters in every respect, from shipping a product and getting feedback from customers at the macro scale to even just being able to run your tests and debug your code in a very tight way. So you’re getting feedback and input as tight as possible. And that’s critical to building and shipping better APIs. When we look at API management today, we see lots of focus on governance, but very little is done to optimize the development process and empower your engineers. That, I think is one of the most fundamental problems with API management today. Collaboration is another key aspect when we think about that optimized feedback loop that optimizes development. The best tools in the world today help developers collaborate. Having tools that are easy to learn is critical. It should feel intuitive; it should feel fast to learn.
As it sits today, API management gets in the way of that. It sits on an Iron Throne, defended by a team of architects or Knights of the Round Table who got access to it. Developers can’t easily work with it, and therefore, that’s going to break down collaboration. They are very hard to learn and critically, it doesn’t fit the workflow of a developer. Everything’s a little bit alien; the configuration isn’t in text files like everything else is for my code. At times it’s expensive to buy, and so it’s prohibitive to small and medium businesses. It is expensive to operate as well.
At Zuplo, we are trying to resolve these issues. We think we fix it at Zuplo by using a shift-left infrastructure to shorten the feedback loop and allow developers to engage with the gateway much earlier in their lifecycle. It is how they approach building their solution, not some afterthought they try to hone their API into. We’ve taken a very developer-centric approach. It is a fully managed solution and can seamlessly auto-scale. We run it on Edge compute.
A very important point to be considered in API management and shipping better APIs is the council problem. At Microsoft, I was appointed to lead a project called One API, sponsored by Bill Gates. They had four divisions at Microsoft, Windows, Bing, Office, and Azure, and the APIs had all been built independently. That ended up in a very bad outcome where the APIs were inconsistent. The Office API looked nothing like the Azure API. That was bad for business because a user who had learned to use the Office API could not quickly translate and use the Azure API. You want consistent APIs across groups to enable cross-selling and have happy customers.
At Stripe, where I lead the payment methods teams, we had an API council that had to review all changes to an API. That led to a high-quality outcome, but unfortunately, it was very slow, a huge bottleneck, and lengthened the feedback process.
So, you’re stuck between a choice of inconsistent APIs and bottleneck review processes. We think the answer to this is automated governance or engineering leaders defining policies that are enforced. Engineering teams can operate with complete freedom until they reach that point. They can set up preview environments and get real-time feedback about those policies. It lets them know that they’re off track and the API is inconsistent with the design of the other API or isn’t compliant with the organization’s rules but doesn’t get in the way of solving that particular problem at that moment.
When we started this product, we knew we had to build for Edge; we knew we had to build for a new paradigm of computing where you deploy to one region, it’s fully managed, and you are in 300 data centers worldwide. This makes it work great with multi-cloud infrastructures. So not only is it Edge and multi-cloud capable, but we also have many large customers doing billions of requests per month with zero downtime to date and a very high SLA.
To conclude, you might be able to improve some of your processes, and remember to focus on this idea of shifting left on your API infrastructure, empowering developers, and optimizing development workflow that is a critical part of shipping better APIs.
