Software at Scale - Software at Scale 48 - API Gateway Management with Josh Twist

Episode Date: June 9, 2022

Josh Twist is the co-founder and CEO of Zuplo, a programmable, developer friendly API Gateway Management Platform.Apple Podcasts | Spotify | Google PodcastsWe discuss a new category of developer tools startups - API Gateway Management Platforms. We go over what an API Gateway is, why do companies use gateways, common pain-points in gateway management, building reliable systems that serve billions of requests at scale. But most importantly, we dive into the story of Josh’s UK Developer of the Year 2009 award.Recently, I’ve been working on the Vanta API and was surprised at how poor the performance and developer experience around Amazon’s API Gateway is. It has poor support for rate limiting, and has very high edge latency. So I’m excited for a new crop of companies to provide good solutions in this space.Episode Reading List* Amazon’s API Gateway* Stripe’s API - The first ten years* EnvoyThe Award This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

Welcome to Software at Scale, a podcast where we discuss the technical stories behind large software applications. I'm your host, Utsav Shah, and thank you for listening. Hey, welcome to another episode of the Software at Scale podcast. Joining me here today is Josh Twist, the CEOo and founder of zooplo an api gateway management platform did i get that roughly correct is that the right way to say zooplo yeah i mean it's a it's a decent description you know we say call it the programmable api gateway or the developer friendly api gateway but yeah you you covered it i think yeah and you used to lead product at microsoft facebook and stripe for a little while and you were the uk

developer of the year in 2009 so i really didn't know countries give out awards like that so i need to know the backstory on that one yeah i mean it's a pretty funny story actually the whole thing is pretty funny if you want a comedy anecdote to open up the podcast um so yeah there was a magazine in the uk called computing magazine if you remember when things were printed out and everything wasn't online and it was associated with a thing called the british computer society and they would run this annual competition where they give out awards to people who work in tech and one of the awards was developer of the year and i was working at microsoft at the time as a consultant in the uk then before i moved to the year and I was working at Microsoft at the time as a consultant in the UK

then before I moved to the US and they they they submitted me for this award so it was a big surprise and then the next stage was to go to the interviews and I remember thinking you know what do I wear to a developer interview and I thought well I'm gonna wear what I were to work which is like jeans and I think I wore a button-up more in the UK is a little bit more formal it's a bit more east coast you know and I showed up at this stadium and there must have been I don't know 700 people there all of them in suits everyone looks so smart and like people were passing me cups because they thought I was a cleaner or something I don't know I was so embarrassed I actually think it probably went in my favor honestly but the interview went quite well I apologized for not dressing up for was a cleaner or something I don't know I I was so embarrassed I actually think it probably went

in my favor honestly um but the interview went quite well I apologized for not dressing up for the event and then I find out I'm in the final which is this big honestly to me it was like the Oscars though thankfully they don't let people give speeches because it would have been the most boring Oscars in the world obviously a bunch of developers and so on but um and my award was the last category of the evening and I'd been watching everybody who won like what what what is the right behavior I mean I really didn't think I was going to win to be clear I really didn't think it but I thought you know I should look at what people do and I noticed that they stood up calmly and shook hands with their colleagues and then calmly walked down the red carpet to the to receive their award and it came to my category at the end and then calmly walked down the red carpet to the to receive the reward and it

came to my category at the end and then they did the third person and the second placed person and my name wasn't in it I thought oh I didn't get anything and so I really my hopes had just fallen then because I didn't think there was any hope I would win and then they announced my name as the winner and I jumped out of my seat and I waved my arms in the air and I screamed at the top of my voice and I ran down the red carpet I didn't say you know I was with like the managing director of Microsoft UK and so on and I just ran off I ignored them all and ran down to the front and the person giving the awards was this comedian called Sean Locke who was one of my favorite comedians so I was you know just super excited to meet him and they gave me this glass trophy and it was like a curved piece of glass and when the press

took pictures I was stood between Sean Locke the comedian and the sponsor of the award some some executive at some big company and I'm holding the glass with sort of my thumbs behind it and the flash or the photography made it look like there was no award in my hand so it just looks like i'm stood there with the biggest grin in the world sticking two thumbs up stood in between these two you know one executive and one person it just looked ridiculous so anyway it was um it was very flattering thing to win it was very nice but um um yeah i don't know i've never seen anything like that in the in the in the US but it was a it was a really cool experience for sure yeah that's funny that reminds I think Forbes 30 under 30 and stuff are like kind of like that where you have to apply to get in but but that's a fun story do you know

what criteria they use to decide your develop did they actually interview you on like the kind of work you do yeah so they they don't think i'm the best developer in like i am the best at algorithms or bubble sorts or that kind of thing actually the interview tended more towards some of the contributions i'd made um so i'd done a couple of things at microsoft like create this thing called the dfa the developer foundation assessment and it was a a question or effectively, I think there's a video about this on YouTube somewhere. It's very old because I built a version of it that worked on the Microsoft surface, if you remember that. And, you know,

it would ask you questions about different approaches you have to software development, and it would give you a rating and give you suggestions of how to improve. And I'd done a bunch of projects like that, which we um as part of the microsoft consulting uk um and so i think that was the kind of thing that tipped them right it was like a um contributing back to the to the community was perhaps you know it should have been open sourced really but we weren't talking about open source quite as much then this was 2009 i mean there was still plenty of open source stuff going on but it wasn't it wasn't as obvious as it is today yeah it would have been hilarious if like the only criteria they used was like, can you write bubble sort and then whoever gets it done the fastest wins. And then after that, you led product at a bunch of different companies and like microsoft and facebook and you had like these

divisions i saw on your linkedin you were in charge of like a product line that was more than 100 million dollars a year in revenue how did you find yourself yeah yeah but that's that's like the ipo milestone or the threshold you need to hit right like oh my startup is successful and i can like do an ipo at least that's what i've read so how did you find yourself in that position um so my career has nearly all been intrapreneurship um that means like starting new things at big companies which is not the same as entrepreneurship you know I'm not trying to suggest that like it's very very different doing it in a small company the resources are very different the challenges there's some opportunities though as well. Yeah, so I moved to Microsoft US.

That's when I became a product manager in 2010 and founded a product called Azure Mobile Services, which was, you know, like a pass or a Firebase backend. It's still going today. And people loved it. You know, it was certainly internally, actually Satya Nadella wasn't the CEO at the time, but he was its biggest fan. He would email me regularly with questions about it. And, you know, that kind of visibility is always great. So

I got offered new opportunities. And then we recognized actually partly through the work we'd done with Azure mobile services about what people were trying to do with APIs. This mobile service backend was basically very similar to Superbase today. It's like an API for mobile apps. And it just took us deeper into the API space where we started to pick up on this big digital movement. And so we then had the idea to do API management at Microsoft which I led that team and we did it through an acquisition we acquired a company called Epiphany and that was us entering the

API management space which actually is I kind of compete with it today at Zoopla which is fun when my old team come and sign up on our wait list and I don't let them in that's kind of amusing but then the API management space has so many sort of intersections and adjacencies to integration and so I guess I was promoted and they asked me to take on the whole integration portfolio and that included BizTalk server which was I think you know the the one you're talking about was doing 100 million dollars a year it's not really that much money at microsoft scale now but um and we founded all the new stuff in the integration space as well whilst i was there so products like logic apps and um i think it's called power automate pro

today used to be called microsoft flow which is a zapier compete so you know it was just um you know a result of sort of continuously executing quite well and doing a good job and showing awareness of spaces and so they kept rewarding that with more scope really that was how i i got to that position at microsoft and then and is that where you start first started thinking like this could be productized or like did you just like let's move around like you went you went to facebook i think after that right where you were doing something different and now you're kind of back into the api space so yeah i mean i nearly most of my career has had some touch point with apis like at facebook and at stripe as well uh with just one brief hiatus um um so when you said productize like the idea that i could make something like zooplo

absolutely was in my mind back at microsoft in fact fact I I hope they're listening to this but I left these guys with some of the ideas that I'm implementing now that they should do it at Microsoft but you know doing doing interesting or unusual things at a big company is really hard you have to convince everybody and everybody in a chain and if any one of those people in the chain don't agree then the idea dies and i think that's what's a bit different about doing a startup like i have to convince some people like my co-founder obviously um investors if i want to raise money but the nice thing about investors is if one doesn't get your vision i can just move on to the next set and talk to them until someone understands what i'm doing gets me and is

willing to back me you can't do that at a big company it's why it's so hard to do anything innovative because you know everybody's got to agree everybody's got to be a supporter and that's it's just incredibly if you're doing anything interesting by definition that's going to be hard because some people are not going to agree with it yeah i sometimes wonder like is the corporate hierarchy really the right way i know that the Google founders tried to famously manage like a flat organization with like hundreds of developers and no managers and that crashed and burned. So I wonder if you've just not gotten to the right point or like the right

trade-offs. Cause I think right now the whole idea of like one-on-ones and having managers and stuff is like pretty good for career development. But as, as you mentioned, right? Like if you come up with something innovative everyone has to sign off on prioritization is this the biggest thing we can do it's pretty risky etc etc i mean i kind of believe in the evolution of market systems and organizations and and so so i don't think i mean i've seen some companies try some really innovative

corporate structures um i was just chatting to a friend yesterday who works at steam and you know they have no managers um but steam whilst it's achieved some scale it's not mega scale you know it's not microsoft or google scale and you know i was at stripe as well for a little while um before i started zuplo and i'm told i didn't know this but just a few years before i was there there was no managers at stripe either so you know um kind of everyone reported to patrick i guess i don't think he had a one-to-one with them all um and that again it worked well to a point until it didn't and then it failed and they've gone the fairly classic sort of like managers and you know organizational structure um i think that is it the optimal way for a big

company to be probably not and there's a question of company scaling that i know we talked about at facebook is it's not a matter of if this culture will change and become you know it'll become harder to do innovative new things it's a question of how if this culture will change and become, you know, it'll become harder to do innovative new things. It's a question of how long we can stave that off, how long we can stay a great, innovative, fresh company that isn't, isn't becoming more corporate for want of a better description. I think Facebook did it very well, but certainly I felt, you know, honestly, I felt sniffs of it towards the end of my time they're partly driven by increased regulatory you know overview and so on and just a massive drive towards process which i think

slows everybody down and again makes it hard to push new ideas through if there's a lot of you think you think the moment you you have an idea let's have and you know you're like i want to do this thing and then you realize how many hurdles it's going to take you to get something done like let's say it's at vanter or something which you know is a young and i'm sure aggressive company and then you go to take that idea to a place where it's just infinitely harder and more bureaucratic like those ideas die so quickly on the vine in a place like that um but having said that that, does that make it the wrong architecture? I don't know. Um, I, I, I think it's kind of evolved this way where

those companies have a lot to lose and a lot at risk, whereas startups don't. And so they can do you know more crazy things and pursue them and bigger companies just can't do that for a number of reasons but yeah no but that doesn't you know what I see as an ecosystem now is that often well the larger companies will um will acquire the smaller companies that that have proven that this is something of interest and that's like a pretty healthy market um sometimes larger companies copy the startups as well i won't name any names here um there's one company in my history that's very famous for that um in fact multiple but um but it's not an unusual thing and i think it's just part of that that ecosystem it's part of that sort of there's this primordial soup of startups and then these mega predators hanging around

um it doesn't put me off at all i found it quite exciting quite thrilling yep like as a startup also you don't have to prove that your first market is going to be like a 10 billion dollar market and like you're going to get 100 million err in like three years or whatever you're just experimenting right so even the stakes are don't have to be extremely high no it might be an even more culturally subtle thing as well um you know when we were talking to investors raising money for zuplo there was there was i hope investors aren't listening there was there was you know there were certain questions that would kind of make me worried about whether this was the right investor for us and it reminded me of when i worked at you know big co you you picked the name

and i'd be doing some i said i've done entrepreneurship my whole at you know big co you you pick the name and I'd be doing some I said I've done entrepreneurship my whole career you know I've basically been launching new products at big companies and some leaders in in big companies get it that that like small companies aren't measured by the same metrics small ideas aren't measured by the same metrics you're really looking for early green shoots of growth and promise and maybe adoption or excitement about a product with a few small number of users and what's alarming is if you're in a larger company and you're working for a leader who is asking similar questions or asking their mature teams like you know what's your cost structure or how are you going to displace

this mega competitor that you're going after like that you don't worry about how you displace the mega players at the beginning of your journey you know i i firmly believe nobody was asking stripe in the early days of stripe how do they go and displace world pay from ford which they just did recently i don't know if it was world pay but ford motor company just switched to stripe i doubt they were thinking about that in the beginning because they were very focused on their target customer and their audience and like building out from that point. And so I really was nervous of investors that gave me that sense that they're,

you know, they're more focused on downstage, mature products and wouldn't be giving us the right support and the right guidance and asking the right questions. That's one of the reasons we haven't actually announced it but um we were excited to partner with bold start which is a a small seed focused vc out of um new york um and i would say they just get it is how i describe them they just get it what it's like to be a scrappy upstart um startup and the attitude and the culture that takes and how different it is from, you know, later stage. Exactly. And there's so many nuances of the whole ecosystem, right?

Like you need to know, you need to figure, you need to talk to all of these people like regular software engineers or like product leads don't have a network with like hundreds of VCs where you know exactly who's the right fit for you. So I'm guessing all of this just takes time and you have to find someone whose vision aligns with yours or at least they're seeing or thinking about the things you're thinking about and not thinking about like P&Ls at this stage.

So yeah, let's start with Zooplo then. What exactly is the product? What does the product do? How does it help me so um let's imagine um it's ironic because we've had this conversation let's imagine vanter has an api that you share externally then you have a lot of problems to solve and let's say that the um the gold star example of how to do this well is Stripe, maybe. You want to have a Stripe quality API experience for the developers that are going to be using the Vantr API.

And I talk about there's at least three pillars you should think about before you launch your API program. Let's call it that. First is authentication you know we recommend api keys for for public apis but but we support jot as well the second is protection because it's you know it's not hackers that are going to take you down it's your customer a customer is going to write a clumsy for loop and um they're going to hit you much harder than you expected and take down your whole service and then you need some way of teaching developers how to use that API that you've written. So documentation.

Zooplo is a Stripe quality API experience out of the box. So you can take any API you've implemented and put Zooplo in front of it. And basically get all those features you know within within minutes for a demo honestly we've got customers live within hours like i think one customer we got live in about two hours and they've been running on it ever since um and that's really what we're what we're trying to do now there are other products in the market that help with one or more of these problems you know like readme is famous for its documentation and there are other gateways out there that can deal with this but we call

ourselves the programmable api gateway because we come at it with a very a very singular focus on we are building this product for developers engineers are the only user we think about um when we build this product and so one of the things we found when we were researching the space was many of the gateways in the market today, well, first of all, they tend to have a fairly low NPS. Like there's plenty of gateways in the market, but we've not found many engineers, certainly, that love the gateway they're using. And we also found that what they would often have to do is they have an api that

they want to share right perhaps they built it internally for their own react backend or something and then what they need to do to share it is they write another api that does a bunch of transformations and changes that sits in between the original api and the gateway and that just seemed crazy to me it's like why isn't the gateway itself programmable? Why isn't writing code a first-class tenant of the gateway? And so whatever you're doing in Zooplo, you're only like a click away from being able to write code to do that yourself.

So if you want a custom API key policy because you don't like ours, write a custom policy. If you want to do some orchestration across the back end then you can use one of our function handlers um so this whole idea that it's extremely programmable and designed for developers is kind of our major differentiator i'd say okay and do you run that code which like the the programmable parts, like a developer sends you like a Node.js script or like a Python script or something like that, and your platform runs that code? That's right. And the way we achieve isolation is interesting because what we don't want to do

is, you know, a gateway has to be extremely performant. We don't want to do multi-process hops. So, you know, traditional architectures, this is hard to do. So what we actually do is we take your code and we bundle it all up and we bundle it next to the gateway itself. And so it runs in process with our gateway, but every customer gets their own isolated instance of that gateway. By default, we deploy to the edge. So, you know, we make ops devops or get ops whatever you want to call it very easy as well so you know it's kind of a one click deploy to the edge and you'll be at you know 100 plus data centers around the world in in like four seconds

and um and it scales effortlessly so you know we have um one customer that grew very quickly with us and is doing like a billion calls a month almost and they've never sneezed they've never you know they've never thought about it after deploying so that's another thing we think is really important like you don't want to when i think about a gateway i don't want to think about the infrastructure and i but i want a gateway that runs at the edge that's where a gateway should be close to my customers ideally so yeah that makes a lot of sense and it is surprising to me how bad, as you mentioned, the provided API gateways are out of the box.

I think on our previous call, you mentioned that Zupro is faster than API gateway or probably is faster than API gateway. And I certainly think so because API gateway, the Amazon one is slow. And I think part of that is this whole idea of just doing too many hops and you want this

gateway to be performant like you don't want the gateway to be a source of latency no absolutely it needs to be fast but almost as important as being fast as it needs to be consistent so has consistent performance time and doesn't spike so you know we've designed our architecture to run on isolates and workers as well as kubernetes and the the advantage of these environments like denno and cloudflare workers is that you get zero millisecond startup time which is kind of rare in serverless tech so that was something we really bet hard on when we built our gateway so the like a gateway is a fairly essential part of an api program right if the gateway is down then you can't use the system it's as simple as that right or like the api gateway is

authentication logics slightly off or something then you might have a security breach how do you convince your first customer or how did you convince your first customer like you know this is a product that's good enough for you to use what was that process like yeah that's a great question i think um you know selling mission critical is hard um i think in this case we had to find some some customers that had the right risk threshold honestly they were early they were themselves not perhaps crazy reliable at first and so it seemed like low risk profile um you know one customer actually used the programmability of zuplo to to make them appear more up than they were they um they actually had a sort of flaky back end they would go down

and they wrote a custom policy we we parted with them wrote a custom policy. We, we partnered with them, wrote a custom policy in Suplo that would back up all incoming requests to S3 storage. It took like 20 minutes. It was like, you know, six lines of code, very easy. Um, this is what I mean by the programmable gateway. It's like, it's like your get out of jail free card. It's like, we abstract you from your, your customers, you know, your customers craziness or whatever. Um, you know we we just found customers with the right the right risk profile and then it becomes like how have we performed historically so now you know you mentioned we just crossed the threshold of over five billion api calls handled we have had in in production we have had zero downtime um so far we had one customer incident of which we thought

might be downtime but it turned out their customer was doing something something um wrong and we helped them debug it which was kind of uh another feather in the cap actually um but yeah it's uh it's a tough it's tough it's a tough space to buy yourself into you know if you're going to do a startup there's i sometimes regret i wish why didn't i do a startup where i am not mission critical um i don't know like a sneak or something which is like a great product um a company i very much admire but you know if sneak goes down nobody nobody really goes down right um but yeah no i think we've proven our record though so far so that's helping now in ongoing conversations the more history the more time we put behind us with this solid track record and if people start performance testing as they see it scales it works um so

the conversation has evolved but it initially began with finding customers with the right risk yeah yeah the flip side is that you are doing something extremely important and then switching away from you is going to be really hard because like i don't know if the new provider is going to be as good right so there's there's like that flip side because i work on a product that's like not extremely mission mission critical but then people think of it as more like transactional right like oh i can just use something else if it's like half the price so that that's that's one interesting piece at least that i've learned like you never get it there's always like downsides to each part but that's great to hear at least, that I've learned. Like, you never get it. There's always, like, downsides to each part.

But that's great to hear, like, the fact that you've not had any downtime. I have to talk to one of your engineers now to understand exactly how... Because it looks like there's, like, a lot of interesting technology. There's, like, Cloudflare workers. All of this is, like, relatively new, and you have to be, you know, in the loop to know exactly how you can manage this stuff, like easily deploying to the edge for like over 100 data centers and stuff.

Okay, and why is API gateway management hard? As you mentioned, some customers have this layer between a gateway and their internal service. But generally, what do you see as like the biggest features that your customers have ended up using this the programmability piece, which is certainly great. But what else makes managing your own API gateway tricky?

Yeah, it's a good question. I actually think the biggest problem is the complexity of these platforms and the learning curve so if you're you know let's say you're an engineer which is who we describe our target audience as and you're looking at a number of gateways as potential solutions for you we think the time to successfully have an api up and running and ideally writing a little bit of custom code is it's kind of a critical measure um we're very focused on you know a PLG a product-led growth um motion because we believe that's how we're going to win we're going to win the market by winning developers and we think that starts with like they can try it they get it it makes sense to them it uses concepts that are not in alien that are not alien to them and it's very easy to get started and so

you know like the zooplo challenge is seriously if you're if you're if anyone listening is is about to adopt a gateway i don't really want to drop names of competitors but we all know who the the usual suspects are i'd say give zooploro a chance. You know, I did an experiment where when I was starting the company, I went through all of the competitors in the space and I tried their products. I was like, and I timed myself. I tried to be as objective as possible.

How long does it take me to set up this gateway, proxy an API, add a little bit of custom code? I don't care what it's doing. It can like change a header or it can, you know, be a custom policy, just anything. How long does it take me to achieve that scenario? And honestly, the fastest I did it with a combination of tools from one of the big cloud vendors, it took to achieve that was an hour and 45 minutes. the zooplo challenge is if you try this you'll have this end-to-end going in two minutes and so that's i think our our biggest selling point is you know

who we're built for what the design feels like and what the experience feels like the features people are using are you know they're pretty obvious to begin with things like rate limiting uh our rate limiting is programmable though so so you know if you want to do like ip rate limiting is not that interesting today it's fairly easy to set that up with a it's just easy to set that up where it gets interesting is what you really want to do with rate limiting is rate limit on a per customer basis so not just every customer gets 100 requests per second but but surely you treat your free customers differently to your premium. And we just did a blog post on Thursday, actually,

where we showed how easy that is in Zooplo, because you get to write code that talks to the rate limiter. It's like three lines, I don't know, five lines of TypeScript that tells the rate limiter how you want to handle this particular request. And that can, if you want, that can include things like database lookups that you can cache. so it's insanely flexible so yeah it's the programmable aspect applied with all the common features you would expect from a gateway it's that marriage of the two that makes this such a great fit for developers um and the fact you can

just you know i know what it's like as a i mean i guess i'm not technically an engineer anymore i did write a lot of the gateway but um i know what it's like when i'm trying a new sass product these days like we're trying them so often right the great thing about starting a business today is like there's so many tools lying around that can help you accelerate your time to market and one of the key ways i pick which one i'm going to use is which one do I feel I can be successful with? And so we've been very, very focused on that. And then to expand it, I know the current focus is certainly like developers trying to get an API gateway up and running

with some programmability as quickly as possible. And that makes a ton of sense to me. What is your like longer term like vision? Like, you know, if everything works out, if you have a ton of early adopters and like you know if everything works out if you have a ton of early adopters and like you see your business doing well what would you like to eventually get at and like solve yeah i mean it's a very savvy question actually because the programmable gateway was a slight i wouldn't call it a pivot but a slight, I wouldn't call it a pivot, but a slight adjustment to the original

germ of an idea that became Zooplo. To tell the story narratively during 2020, I'm British if you haven't guessed from the accent, although it's been quite Americanized now. I would spend a lot of time hanging out with my family in the UK, my sister and her family in the UK. We'd hang out for like five hours because they were in strict lockdown and we were in strict lockdown. What else could you do? And we really wanted to play card games, but you can't pass them through the TV. We were using Facebook portal, by the way, which the portal TV product for hanging out with your family is amazing. I'll totally drop a pitch for that. You just put this little box on top of your TV and then you get a full screen sort of zoom like experience. It's, you know, it's almost like

being together. It's really great. So we did that a lot, but we couldn't play card games. So being a former engineer, rather than go and find something in the app store, I decided I was going to build a card game that we could play on our phones. And then the deck would be synchronized in the cloud, obviously. And, you know, we could like deal cards. So we, I built like a cards against humanity. It's actually still available. It's not safe for work folks but i think offensive.cards is still running if you want to go and try that um that url and you can play with your friends and family for free um and so i decided to build it and i built it using react um i was quite excited to try some ui tech i hadn't coded in for a while so i'd never really done much react

uh next.js and for a cell i was very impressed with all these changes in the UI stack you know it was like super easy and I needed a back end for it to synchronize the cards and I you know I went to firebase sorry to beat up on the firebase folks but I built it in firebase and I ripped it out because I reminded myself why I hate the back end as a service paradigm because all my logic ends up on the client and it's a real mess and so i threw that away and then i rebuilt it you know we're just a custom express server and i was kind of stunned at the state of the api landscape i'm like wow i've been away for a few years and it doesn't feel like it's advanced at all like the back end um like why why can't i go to a web browser and it be as easy as google

docs like why can't i go in and file new api and write a little bit of code and there's my api live and you will notice i mean you've seen the product itself so you know it actually feels a little bit like that right you can go and file new in api so we're very focused on the gateway scenario for now i think it's really important but i can certainly imagine a world where we broaden the scope of zuplo and it becomes a great place to actually build an api because then i get all of the the features of a gateway for free right the documentations there are the rate limitings there are the jot authentication or whatever you know whatever authentication scheme i want to use is a matter of configuration. It seems kind of crazy actually that those aren't

more integrated services into however I'm building an API. Now there's lots of libraries and packages that can help with this but they don't always work in a very scaled way. Take rate limiting. If you're going to deploy to the edge, which everybody's going to do at some point, how do you do rate limiting when you're in 100

data centers? That is a complex problem because you don't know where these requests are coming in from and you have to distribute them and so we've kind of tackled that problem um amongst others but yeah that's part of the vision um certainly i'll give us an example the management plane like the management api for zooplo that sits behind our web portal is actually built mostly on Zooplo. Some of them we proxy calls to different tech because we're not good at running ML models or certain things. It's not what we're really designed for. But if you're doing simple orchestration between databases and writes, it's actually a pretty cool place to be and so we do we do a lot of that in zoopla we have a lot of micro services most of them are written in zoopla

and then they're all coordinated through zoopla itself so you're basically talking about like services talking to other service and stuff that can all be kind of managed by zoopla today and just just before you mentioned that i was thinking yeah like zoopla's. And just before you mentioned that, I was thinking, yeah, like Zoopla was, I've seen the product for an external API, right? But even for an internal RPC system, let's say I have two Node.js services today that have to talk to each other. And I work in a full AWS stack. There's not a super easy way for me to just say,

service A should only be able to talk to service b and you figure that out through like https or something like i have to install envoy i have to do all of this mess it would be so interesting if there was like a product that helped me manage like my internal rpcs as well i very much agree and i think that is something we would be excited to go and tackle at some point. But obviously when you start a new venture, you have to pick a scenario. The great thing about this is,

I actually mentioned at the beginning of my time at Microsoft, I kind of went from API gateway into integration because of the adjacencies. There's so much overlap. If you're doing integration, you needis and they become so you know so dovetailed there's a lot of um scenarios that are that are adjacent and interesting but we've got to kind of pick the one where we're really focused on right now and that is the hey you want to you want to you're sharing an api and you want to stripe quality experience we will our promise is we will save you time and money in both the

setup and the maintenance um because you know engineers are expensive and they're scarce and you really shouldn't be building stuff um that adds risk to your portfolio and it's going to take your engineers time to maintain if you can if you can outsource it to someone who's reliable and part of that is like the developer documentation piece right like there isn't any documentation product and we just did a vendor review for this like a few months ago so there isn't any documentation product and we just did a vendor review for this like a few months ago so there isn't any product out there at least from what i can tell that has like developer documentation as cleanly described and like you know with the whole api playgrounds

of this this parts of that but nothing ties it well as well as like the stripe api documentation like it still feels like their internal tool for documentation is better than any product out there which is kind of sad that you would think that the free market would have pushed forward by now readme comes close but i still think stripe documentation is just so much better than any other product that can provide like a similar experience at least so far it's interesting that isn't it like yeah why hasn't there been more because there there were a number of players there now who are doing some great work here very focused on this scenario um you mentioned one of them read me um but they're all based on that first mile i remember read me being around when

and it's a great company you know i'm a i'm a big fan actually um when i when i launched when we launched api management at microsoft which was like 2013 they were that we had an eye on them going wow they're interesting um and they've done great like they've grown the business and they're they're everyone knows about them now you know they're like a household name kind of thing in this space if you deal with apis but yeah it still looks kind of similar there hasn't been a ton of innovation maybe stripe real and at the time they were like the stripe of api documentation you know that's what they were trying to be um unashamedly i think so stripe set the bar in 2013 and no one's really raised it since it's kind of interesting and yeah we were talking about graphql like graphql is coming up

but there's not enough tooling for it. Like the AWS managed one, like AppSync or whatever, it's just, it's not a gate bits. It tries to get rid of your business logic in the middle. So there's really nothing that like syncs well with GraphQL and stuff. So I feel like there is definitely a lot of space here for people to build things as you see more and more companies

like linear launched GraphQL API, GitHub has a GraphQL API, Shopify, Vantr released its graphql api so i think the space is kind of increasing right now um there's an interesting product by like netlify which is like a cloud cloud graph and the idea is that netlify similar to versat right it's just like front-end deployment system and then you have to think about the back end that has to be somewhere else like we can provide a set of like one unified graphql api to you that can call all of these different services like use the github field and the graphql api configure an api token on our dashboard and you can just make calls to github you don't have to

think about managing a back-end or proxying those requests i think there's a lot of interesting ideas like that in the space that are kind of marinating. I don't know how many of them will last and how many users there are, but there's a ton of innovation here. Yeah, obviously we're looking at it all closely with an interested eye

and a question as to what we do next in this space. But that's why when asked, what does the what you know what's what's the v2 of zooplo it's like we have a lot of options um you know there's a lot of adjacencies here of things we could do beyond just what we're doing today that i think especially the way we've built the platform and its programmability um makes it very interesting um in terms of how quickly we can move into those adjacencies what was the most surprising piece of feedback that you've seen like a surprising theme of feedback or like what were you not expecting that you've clearly experienced in

the space and you've been looking at stuff for a while what was something like interesting to learn um you know the product feedback actually i will say has kind of gone pretty as we designed um i laugh because i just got off a call today um i don't really like beating up on competitors um i don't think it's a good strategy but uh someone on a call today said it's like insert name here very famous very famous api gateway but not awful was the description so like generally that's what people seem to say a lot like they kind of get it um i think the the part, um, really comes down to the sales process and the surprises there. So, you know, obviously selling mission critical is hard. That takes a long sales cycle. Sometimes, you know, I mentioned we've got people live in two hours, but they were, they

had a very different risk profile. And then we've got other customers that want to go through penetration testing and, and so on but probably the hardest thing is timing you know um if you meet someone six months after they've implemented their role their own solution or they've picked another competitor and they're comfortable with that it's not broken then they ain't gonna touch it right um and so the challenge for us is driving enough awareness getting better at spotting timing etc um so that we can um so that we can you know we can actually close that deal so the timing piece was an interesting

one as you mentioned like nobody wants to rip and replace a solution that works yeah but yeah not not entirely unexpected right like it's just one of those things where like the way i'm thinking about it is even if the people who originally wrote the system are still around they'll be very low to like get rid of it but as soon as they leave the company nobody wants to manage like a hand-rolled Terraform config of like 200 lines when they need to add the next big feature. Like, oh, now I need to add rate limiting to this gateway. Well, I need to write like a Lambda

and like come up with a custom authorizer and stuff. I don't know about that. Yeah, no, it's interesting. Like what we've seen is, first of all, if it works, even if it's a like like what we've seen is um first of all if it works even if it's a massive terraform script and it's like stuck together with spit and kleenex um people will will not want to touch it um what happens though is then they suddenly need to make a change and then they're terrified of it and the conversation starts to open up or they realize

that you know because they built their own gateway or they built the features into their api they don't have the abstraction you know one customer poc we're doing um i presented them zuplo and they're like oh this is cool you know they gave all the good feedback i talked about like yeah i wish i'd seen this six months ago before i built my own and then you know i assumed it was like a dead prospect for now there'd be no um there'd be no follow-up but then they came back to me about four days later and was like hey can we do a proof of concept and i was like why sure of course yeah happy to help and what had changed was they had a customer come to them and say um look we need to be on this new version you've been promising us of your backend, this beta.

And they, you know, they were under a lot of pressure. So what they had to do was they routed this one special customer to a different backend implementation to all of their other customers. The API was not a breaking change. It was the implementation of how the thing worked. So the API signature was exactly the same, but they weren't ready to give the beta to everybody else. You know, they, this one customer that won it was going to get it. And so by having Zupro, they had this programmable abstraction layer where they could now, you know, be abstracted from their customers' nonsense and they could break out of jail free. So I think, you know, i'm hopeful

that many of those conversations were the timing wasn't right are not gone forever they're just a question of until they start to feel the pain of the fact they rolled their own or they're using a less capable solution and then they'll come back to us so patience is definitely something doing a startup i mean patience and not patience like patience in this situation is definitely something doing a startup. I mean, patience and not patience. Like patience in this situation is definitely something doing a startup. You need plenty of, you know, nothing. I am a very hungry, motivated, like to move fast kind of person.

But obviously you can only push your customers so quickly. But yeah, I think, you know, a lot of people, a lot of people seem to be pending us in. We're doing quite, you know, we're doing okay winning customers. But I'm excited to see whether how many of those folks actually come back in the future when they start to feel the pain of what they've done. And I'm excited to like talk to you again in like a year and see, you know, how have things changed and like how, what have you learned that's new in the space?

Because I'm sure that would be like an interesting conversation to like play back what we're talking about right now yeah um and maybe as like a slight wrap-up right like what is the next thing that you're currently building that you're excited about like what is like the next feature that you're like oh this is gonna help people so much it's a good question um there's a couple of things that i think are are interesting so actually we're doing a retake on our developer documentation with a view to making them look even more like stripe actually uh or more like i think like you know the cutting edge of that industry um we have talked about um trying to you know it's funny you mentioned it because it's something we've talked about quite a

bit is what if we, what if we could find a way to level up that bar? Like what if we really leaned into this product experience of developer documentation and tried to take it to the next level, you know, and worked with some great designers and, you know, my co-founder is so passionate about the space. He built out the, he was an early employee at auth zero that's a company we really admire um he built out their documentation and sdk team in the early days there so it's like it's super passionate about this and that's something you know that's something where where this isn't just yeah it's another option for getting my documentation it's fairly on par with the industry but hey at least i get it out of the box and it's like i don't have to think about it or you know it just comes with the gateway it's

just included to being like an actual real strong selling point um and just contribute that back to the industry actually that like look stripe has been the bar here for so long like can we raise it i think that would be awesome um some of the other stuff we're excited about is thinking about open source tooling actually you know there are a lot of there are a lot of open source specifications that I don't know if the specs are open source I guess they are that people use when building and designing apis today so things like open api and json schemer is the most commonly used specification for API developers according to the Postman 2021 state of the API report. And then GraphQL.

And so we're very interested in, you know, what can we do in this space that we can kind of raise the bar in multiple ways, not just documentation. And ideally contribute that back to the open source community as well and make these open source projects you know a bit selfishly obviously we're a business we do need to to make money and so on but um with a view to just driving up awareness of zoopla like i want to get to the point where if you do something with apis whatever it is let's graph ql or you write jason schemer or you know whatever you're doing you know about this team and this

product called zooplo that's trying to put a huge dent in the api verse like those are some of the projects we're excited about about starting and not just be marketing it'll be you know actually trying to put something meaningful back into their community yeah that's an exciting vision like i think there's so much like one pain point we've already had for example there's like coming up with like an api cookbook like we want to share the work that like maybe our solutions engineers or sales engineers are doing day in and day out it's like how what's the best way to do that is that just like another wiki page like maybe there's something better like can we publish like five of the most popular api

calls and how people use it especially with like graphQL like how would you do a certain thing with our API like a script maybe that you can use to do x or y there's there's just so much in the space. Totally yep I agree it's the hard actually there's a saying isn't it that the hardest thing in software development is cache invalidation and naming right I? I've never agreed with this. And maybe it's because I've got like a bunch of product management experience. The hardest thing in software development is prioritization. It's like, what do I prioritize?

There's so many things to do competing for my attention. How do I effectively prioritize and work out how to place resources? If you try doing everything, you'll get nothing done. Well, Josh, this has been an excellent conversation thank you so much for being a guest and i'm gonna take you up like a year from now

say how are things going and how how is the conversation you've had like that i'm sure like zoopla is going to do extremely well thank you yeah i first of all i really enjoyed the conversation thanks for inviting me and i hope the conversation in a year's time.