A New Hope for API Management
When I worked at Microsoft, I was lucky to create several new services in Azure, one of which was Azure API Management, through the acquisition of an excellently named Apiphany. It was an exciting time; everybody was talking about digital transformation, and it was clear that APIs would be amongst the most critical infrastructure at businesses of all shapes and sizes. We had big ambitions for what we could do to revolutionize this whole space. Sadly, innovating is a hard thing to do at large companies and Microsoft rarely has the appetite to build the best product in any given category; “good enough" is good enough. Exist and be part of the portfolio, and help sell the bundle!
The potential of API management felt unfulfilled. I have watched the space closely over the years and hold it to be true today, even in a crowded market with the likes of Apigee, Axway, Kong, and Tyk.
API Management’s promise was to solve many of the API challenges engineering teams have today, but it got lost along the way. This is our story…
I’m Josh - the co-founder and CEO of Zuplo. I’m a former software engineer and product manager. I’ve spent most of my career working on Developer Tools and APIs. First at Microsoft, where - as mentioned - I helped found the Azure Mobile Services, Logic Apps and PowerAutomate Pro teams in addition to Azure API Management. Then, at Facebook, I led Product for Facebook Analytics, Facebook Music, and Lasso (their first attempt to take on the mighty TikTok). Then, finally, at Stripe, leading Product for the Payment Methods team before starting Zuplo.
I’ve been lucky to work at some of the best companies in the world, and I’ve seen first-hand how well-designed tools, streamlined processes, and removing friction lead to innovation, execution velocity, happier engineers, and higher quality outcomes — who doesn't want that?
APIs are hard, challenges compound, and we all feel the same pain#
I don’t need to convince you of the importance of APIs to your business today. Whether your APIs are internal only or you’re an API-first company like Stripe, you know their criticality.
You’re likely already dealing with the challenges every business faces as it deals with “API Sprawl."
All of us — small and large companies — tend to follow a similar journey.
Initially, you’re focused on how to design a beautiful API and provide a great Developer Experience. In the blink of an eye you’re dealing with scaling your API, versioning changes, and — like Microsoft above — are struggling with consistency. All of this gets much worse when you have many teams working on multiple APIs, compounded by an explosion of micro-services.
Perhaps each team is building new frameworks to solve common problems like authentication, giving engineering leaders sleepless nights as they worry about security.
One of my last gigs at Microsoft was leading a special initiative called OneAPI, an ambitious cross-company initiative that wanted to solve the inconsistency and poor Developer Experience offered by Microsoft’s APIs at the time. For example, the Azure, Office, and Bing APIs were all different in style, authentication, and best practices, which limited their growth as a business.
Inevitably, all of this builds the urge for the organization to enforce a centralized set of processes — the dreaded Governance word. The problem is that this becomes the bottleneck in your engineering velocity.
API Management, you were supposed to be The Chosen One.#
It is possible to avoid the Governance trap, offer an amazing API Developer Experience and keep your engineering velocity but it’s a complex balancing act for engineering leaders. The right tools and automation are key, but it’s a lot:
This is why the promise of API management feels so unfulfilled. There was a golden era of API Management in the early 2010s with exciting, dynamic companies like Mashery, Apigee, Layer 7 et al building out an exciting vision.
However, the software has come a long way since, but the API Management stacks of today are stuck in the dark ages:
❌ Deployments are slow and hard to automate.
❌ Changes can’t easily be tracked in Source Control.
❌ They don’t respect the modern developer toolset (git, VSCode, popular languages I know).
❌ Prohibitively expensive
❌ They are hard to learn and dated (configuration in XML, still?)
❌ They don’t prioritize Developer Experience
We want to democratize API Management and make it a no-brainer decision for every business. We do this by solving the real problems facing engineering teams, and making API Management affordable and accessible; no need for a week of training or an army of consultants.
Building a product that thinks so differently requires a laser focus on a few product-defining principles:
1/ We build for craftspeople#
We believe engineers are craftspeople who take pride in their work and care deeply about how the creation they put into the world is perceived.
We aim for developer joy, and we want our customers to deliver the same to people who use their API.
This isn’t just about pride; it’s important for your bottom line too.
Developer Experience is the new battleground for the enterprise - you need to capture the heart and minds of grass-root developers. Your API consumers, internal and external deserve nothing less than a Stripe-quality experience.
2/ Remove Friction#
One of the key takeaways from my tenure at Facebook was the power of removing friction. Compounding small wins, created by smoothing out user workflows would yield out-sized results.
One of my favorite examples of the power of removing friction is Vercel. They have built an amazing product that removes friction for engineers and their end users. Vercel’s ability to rapidly build and deploy changes to preview environments is a game-changer for collaboration amongst engineers, and their internal customers in the marketing department. Their obsession with performance is a boost for any end-user using a site hosted on Vercel.
We obsess about removing friction at Zuplo - the most common tasks should be effortlessly enjoyable. The design should seem so obvious that users should wonder why it hasn’t always been this way.
3/ Bet on the future#
We’re building the API Management stack; we ask with every decision, are we making the right technology bets for the long term?
It’s not an easy path - it often means writing new technology from the ground up. Building for the edge, creating a truly serverless gateway that scales effortlessly with 0ms startup time. Creating a new type of infrastructure that can provision new environments in a few seconds enables a more collaborative way of working that moves your business from the bottleneck of Governance to a highly automated, decentralized tool that dovetails with your existing development processes. We do this through innovations like unlimited preview environments, gitops-enabled deployment, native programmability, built-in linting, automated testing, and OpenAPI enforcement - a joy for engineers and engineering managers everywhere.
You have to feel it, to believe it#
What does it look like to use Zuplo? I strongly recommend you give us a try for free. But imagine this.
You sign up for Zuplo and create a new project. In under 30 seconds you have a live, development gateway deployed to the cloud. You use our visual route designer to set up your routes or Import your Open API document. As you work, our customizable linting engine gives feedback on your API design and can even prevent violations from being promoted to non-developer environments.
Next, you connect your project to GitHub (or BitBucket, GitLab, etc) and, in under 20 seconds, we have deployed your main branch to your production environment at the edge - live in over 250 data centers around the world. Your Developer Portal is also live, and you already have a Stripe-quality API experience.
Soon, you add your team members to your project. They make suggested changes via a Pull Request in git and another environment, including a Developer Portal is provisioned. Your automated tests run against this deployment so you can see any failures and block the merge if necessary. You check the preview environment to make sure it’s functional and the changes in the Developer Portal read well before approving the merge.
You want to support API key authentication and use the built-in Zuplo policy you enable API keys with self-serve in your developer portal. A user accidentally checks a key into a GitHub repo - we automatically detect this, revoke the key and notify you and your API consumer.
As an engineering leader you’ve achieved API nirvana. Your portfolio of APIs are consistent, your teams are moving fast and independently and don’t have to build new frameworks that risk the security of your infrastructure that keep you awake at night because they’re all included out of the box.
Try it for yourself#
Do us a favor, try us out at portal.zuplo.com, and let us know how we did, and how we can improve.