Peter Shafton, grok

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore the world of APIs through the lens of business and engineering leadership. Joining me today we have Peter Shafton, CTO at ngrok. Peter’s just joined ngrok, but he shared with me his view of the API economy from his experience leading architecture for Twilio over the last decade.

Well, let’s start with the basics. Who are you, what do you do?

Yeah, so my name is Peter Shafton. I am currently the CTO of ngrok, but in a previous life, the last 10 and a half years, I was a VP of architecture and technology research at Twilio, which was an API-first company as well.

What brought you to APIs? What brought you to Twilio? Did you go there thinking you were going to do APIs, or how did it work?

Yeah, I knew it in a sense. I think I’ve always been a big fan of developer tools, things that enabled developers to get their jobs done, from the early days at SGI where I was basically working on OpenGL, which was the graphics APIs to enable you to build interesting things with graphics, and then later digital media, video libraries and things like that. I always loved enabling developers. And so one of the things I thought was really slick about Twilio was how easily and quickly you could take that tool set and solve a problem that otherwise would be very challenging for you to solve. Something that seems trivial, like sending a text message, turns out is not that truly trivial to do reliably. And the same is true for phone calls. I could probably initiate an outbound phone call that sent you an audio file, but it would be much harder for me to wire that up inbound to something like my web page or some logic. And so I think it’s very empowering. I like building tools, I like doing things that enable me as a developer to do things more easily. So effectively I’m building tools for myself, I am the audience, but it turns out other developers find that useful.

Yeah, Twilio really is kind of the pinnacle of what we showcase when it comes to making developers’ lives easier, from the resources, SMS, voice, to the onboarding experience, to the overall developer experience, it working well reliably, all those things. So what’s the biggest challenge doing APIs for you during your time at Twilio? What did you see as the hardest problems?

Yeah, I think there’s a few problems. One is the APIs are sort of forever. Once you put them out there, you don’t really know who’s built against you, more or less, and you can’t easily get them to move. So if you made a bad decision, you sort of have to live with it for a long period of time. It’s sort of the equivalent of like where you decide to put electrical outlets or network wiring in your house. You can do it after the fact, but it’s pretty painful to go back and change that. And so APIs are the same way. I think that’s the hardest part. Have I thought of something, did I over-promise, did I give out something that was too complicated to support? A lot of good examples. As an example, we allowed you to do something called deep paging at Twilio early on, which basically meant, hey, here’s your result set—I know you like a list of all the text messages you’ve sent in all your time of using Twilio—I’d like to jump into the 10,000th page sorted by time. That was an API that was really useful to developers but almost impossible for us to implement internally. And so I think those are the challenges, where you’re thoughtful about which things are going to bite me. Did I give myself an ability to upgrade versions? How do I split traffic, split customers? And I think most of us build in a multi-tenant world now, which meant that if this is wildly successful, customer A can effectively stomp the capacity or infrastructure support for customer B, and in a perfect world you wouldn’t want to. Those are the biggest challenges for sure: scale and permanence.

In the space we use the phrase “API first” a lot. What does that mean to you? What does API first mean to you?

It basically means that as you’re thinking through a capability or a feature or something you want to do, there’s got to be a way to do it through an API. That is how you’re thinking about it. If there’s a user interface or another way to achieve the same outcome, you have to make sure that it also can be driven by an API. If you don’t think of it that way, then you’ve effectively limited who and what can use your service and how. And so if you can’t script it, if you can’t control it programmatically, then you’ve very much limited certainly the developer customer base. I’ve seen developers do crazy things for products or capabilities that didn’t have an API. You see them scrape web pages, you see them programmatically do HTTP posts because somebody didn’t create an API for it.

And I had a fun story when I was at a startup, this company called Verge, we did video image recognition, so we extracted metadata from video. And I had an engineer there who had built a piece of software that did speech to text, and it had this crazy interface. I couldn’t understand why he created this crazy API, and I realized he’d ended up wrapping the sample that had shipped with this company’s product. He didn’t realize that he could have just written to their SDK directly. And so effectively the interface that he was writing to was a CLI, it was a command-line program. And so it gets you thinking, like, people do crazy stuff to make it work together. But if you don’t create an API, if that isn’t your first thought, then you’re just making it really difficult to use what you’ve got in creative ways.

When I first woke up to Twilio—I remember when Jeff first came on the scene and was pushing it to developers, and I was one of those developers, and I was like, all right, this really speaks to me, because it’s API-first, it speaks to my needs. SMS is a large-scope thing that I have trouble doing on my own. I don’t know the telco network, I don’t know all of this realm, and Jeff and y’all are going to figure this out for me. Over the years, though, I’ve really seen Twilio as more of an enabler, much more—all the API-economy-level stuff, like delivery apps that enabled SMS at that level. That ease enabled so many more other ecosystems. Did you see that early on, or was it pretty hyper-focused on, hey, the direct consumers of SMS and the resources we’re making available?

No, I think we very much saw the niche we were providing. And this was Jeff’s vision early on, long before I got there. If you look at his trajectory—when I say “worked for Jeff,” Jeff really started little startups. His first one was a university lecture-note company. At school they would take lecture notes. But the trick of all these things is, how do you communicate with your customer? How do you notify them that the notes are ready? He did the same thing when he did StubHub. How do you tell somebody that somebody wants to buy your ticket? Because finding that out a week later when they check their email is not useful. You gotta know right now, and they’re like, oh yeah, I’m going to sell the ticket right now. And so he very much saw the need for communication to be part of it, and that being a very challenging thing for him, and why he created Twilio.

And I think we early on knew that making that easy enabled a bunch of things. Now, what we didn’t have the visibility to see is all of the places where that would happen. Like the creation of Uber, which eventually led into DoorDash and a bunch of other things, which obviously for the last two years has been serious for us. And that shift of the customer experience that it created would just raise the bar for everybody. We effectively decimated the taxi industry, indirectly, because in the old days, in the Bay Area, when you order a taxi you call and you say I want a taxi, and they go, great, we’ll send you a taxi, and an hour later maybe the taxi shows up, maybe it doesn’t, you don’t know, you call again, you have no visibility into that. And to change that into a model where it’s like, no, no, we’re going to tell you, I’m going to tell you who the driver is, let you know—that communication part of the business is as important as the actual delivery of the service. And so the same thing, like, you’re tracking your food now. When you order, you know it’s coming, you know when they picked it up in the restaurant, you know when the driver’s headed to the restaurant. That is the bar for all these other companies, for banks and for every service industry. And so the trick is, okay, now that you’ve raised the bar, what does everybody have to do to get there? And the answer is they all gotta go write messaging and voice code. Nobody’s going to do that.

I think you probably went through the whole same phase. There was a point in time where web pages were all static, and then they started to become dynamic—like, ah, I’ll just stay on the page and the data will update dynamically as things are changing. And when we first did that it was all Ajax. Somebody would figure out how to write Ajax code that worked in every version of every browser, and it was crazy, it was a nightmare for developers. And eventually you started to get jQuery and other libraries that made it a lot easier for everybody to have dynamic web pages. And for Twilio it’s exactly that. It just raised the bar and enabled this set of capabilities that everybody expected, ubiquitously. So I think we saw the possibility, I don’t think we understood how far it went and how many industries would be affected. And I think the funny thing about Twilio is there’s still a fraction of the world that’s even adopted it. You look at how many have not, and how many industries have not.

Yeah, it was interesting to watch the telco industry wake up to it. It took a while for them to even see Twilio. From the old-guard telco folks I know, at least, they were like, what is this thing? And then they started, well, this thing is interesting, and then it became a little bit more threat-level. But it’s still, compared to the overall global telco market, you know, there’s a lot of interesting things there for them, but they’re big dinosaurs. So I think it’s the same for a lot of the other industries. Taxi, I think it took a while to wake up to Uber, a little bit faster, I think. But that communication piece is interesting. So do you think the average enterprise—everyone’s an API company nowadays, it’s really gone mainstream—do you think that that communication factor is really where people should be focusing, making it real-time and personal on that level?

Well, I think it’s an important part of the business. It’s important, but it’s not the only thing. As a company you have to figure out how do I build efficiently, how do I accept a bunch of different payment forms, how do I have a channel for the customer to communicate with me. But I think our expectations of what a company will do and how it’ll interact with its customers has changed. And so if you don’t have that, it almost feels antiquated. You see people communicating with companies via Twitter. You used to call and sit on the 1-800 helpline for hours, and then just deal with it as the only way to communicate with the company, and I think your expectation has changed significantly. I think the tricky part is, how does a company do that at scale? Twilio built a call-center product called Flex. And so we see this shift from voice-based support to text-based support, either text messages or email, where a support person can handle thousands of them, or dozens of them, at the same time, as opposed to, I can only be on one phone call at a time. So my ability to service customers in this fashion is much harder.

And so that is an important shift. But I think you hit on something interesting too. Like, for the telcos, introducing APIs after the fact is very challenging. If your infrastructure was not stood up to support those use cases, it looked a lot like that guy who worked for me wrapping a sample—there was no hook to go in and get the result, all I could do is whatever came out on standard out and trying to parse it in some crazy way, parsing the web page. So for these guys, like, okay, I’m an AT&T and I want to create an API to allow somebody to make a phone call. That is not at all how my infrastructure works. The infrastructure makes phone calls, they’re initiated by somebody—where would I have that hook, and how do I deal with back pressure and scale? It just wasn’t a thought. And that’s why it was so hard for them to make that shift. And I’ve talked to a bunch of other companies that are doing the same thing. Like, we built this thing, and the way you configure it is through the web page. You come in and we generate this enormous JSON blob that is all the parameters we actually pass all back in one call, because we have an HTTP post, and then we stand up all the structures we need on the server side. Now you’re like, okay, how do I make an API? I don’t know, I didn’t deconstruct it into its residual parts. And what can you do and not do? It turns out that’s a really hard thing to do.

Well, I think you really touched on the heart of, for me, why APIs matter, why being API-first and seeing the world in APIs, because it’s going to allow you to evolve quicker, respond to things. So can you speak to how API-first allowed—because Twilio’s responded to quite a few things, quite a few acquisitions, you guys got into building some apps, so I’m guessing this was in response to changes or opportunities you saw. How did being API-first allow you guys to respond to those?

No, I think that’s a good way to think about it. Different companies tackle APIs in different ways. I think Twilio’s approach was very Unix-like. When you think about the early days of Unix, you had tools, and they did a simple action and they usually had a simple output, but you could pipe them together. They had simple things like tee and pipe and sort and grep and uniq, each of these tools that did a thing, but you could wire them together and have different outputs, different outcomes. Using these simple tools. And so Twilio was very much the same thing. Here’s the thing—you can tell it what message to send, you can tell the body, you can tell it who to talk to, but that’s all it does. And the same thing, I can initiate a phone call, but each flow in that process I can tell it a simple thing to do, and with those simple capabilities it meant that you could build more complex use cases on top of it. And again, this was a thing that was difficult for incumbents to do. And as we saw people building call centers or marketing products on top of it, it was pretty easy for us to build a solution that allowed all the flexibility of what was under the covers as a product on top, that would have been very hard for somebody else to do, because we already have all the building blocks. You want to add people to a conference, you want to remove them from the conference, you want some participants to be on video and some participants to be on a telephone call—we have all those pieces.

And as we looked for acquisitions, we looked for companies that were API-first. There was no surprise that we acquired SendGrid, because they were an API-first email company. It was very easy to see how naturally these two would fit together. You want to call in your call center but also send emails as a mechanism of getting support—guess what, SendGrid already does all that. So those wires to connect them to our infrastructure was fairly easy. And Segment the same way, a company that is programmatically driven. And so there are a lot of companies that wouldn’t have fit well in that culture and wouldn’t fit well in that environment, but for Twilio those building blocks made it easy to move.

And those acquisitions, I’m assuming, the friction was lessened or reduced because they were API-first and because Twilio’s API-first. There are things that are going to have to be smoothed out, but I’m guessing it made those a lot easier and quicker.

I think it was less friction for our customers, hopefully, although it’s not entirely true because of a lot of the internal things. Most of the friction came from us internally. Like, okay, we’re API-first, but how did we stand up our APIs inside? What did we enable? It’s funny, Jeff talks about being interface-driven as a company. We have APIs for our customers, and we have APIs between teams. If you read his book, he sort of talks about this. The reality was, Twilio actually was not built that way internally at first. It was a database-centric architecture, where all the communication happened in the database. One service would write something, another service would pull the database and see the change and act on it, as opposed to, as you would think, two services would hit each other through REST APIs and initiate the changes. We eventually got that—that was not where we started. And so APIs over time have changed.

And the APIs—in the early days we ran into this a lot. You do a REST operation, you break your logic or your infrastructure up into these models, and these models would each have an interface. So you’d say, conceptually, there is an element that is a message, and if I want to get all the messages, I just hit the list resource and get all of the messages. But it means some things you want to do, like show me the messages as they’re coming in—your company like Uber, and turns out you’re sending 50,000 messages a second, not a thousand messages a second, and I can only page through a thousand records at a time, like I cannot get my messages this way. It was a simple REST API, it made a lot of sense as an interface, but it did not work into the modern world where Segment and others live, where you actually wanted the streaming interface. How do the records stream across an interface? So APIs have to evolve, and we’ve seen this with GraphQL, we’ve seen this with Kafka as an interface, and other things. And I think that is one of the challenges for data scale that people learn. You usually start with REST because it’s simple, you have a JSON payload, it makes a lot of sense, and then you try to build an interface or a product on top of it and you realize at scale, round-tripping a thousand REST requests to build up a page doesn’t work. And so it was great for sending a message, it was great for initiating a phone call, it wasn’t great for showing me the messages from last month.

So what’s the decision-making process in how you chose Kafka, went with different technologies? Was it purely technical, was it about how it handled data? What was some of the thinking that went into those evolutions?

Yeah, I mean, we were forced to deal with it because of scale. And then there are things that are changing now. You have ELT and other mechanisms of accessing data, and the ecosystem has changed. In the early world, you collected data and it only went to you. You’d build a BI system, it would sit in S3 and you’d have Redshift and you’d query your data and that’s where it went. And then the customers started to want their own data back, like it was theirs conceptually. And so how do you give it to them in a way that is convenient, makes sense? And this is where Segment, all these other companies, started to live now, in this world where, what is the data interface? And I think we had to evolve with that time. You’ll see there’s an Event Streams product that’s part of Twilio now that allows you to effectively subscribe to a product, send me all of the messages when they happen, as they change, all the phone calls as they happen, send them over this interface, they will stream into my infrastructure. Kafka is one of those ways, although Kafka is much more common for an internal interface, to decide how do you send data over the wire. Are you using JSON Schema, using Avro, what do those interfaces look like, what infrastructures do you connect into in GCP or Azure or AWS? Those become the data interfaces, and they’re as important for setting up these almost-streaming pipelines, more than, I’m hitting an API and I’m getting a result.

Yeah, those partner influences and external influences are definitely shaping technical decisions more and more. Was there a lot of regulatory that influenced your decision-making along these lines as well?

It’s an interesting battle. So Twilio—I drove something called GDPR at Twilio, that was my responsibility among other things. And there were two vectors inside. One was this world where we say, listen—and Twilio was unique in some sense, maybe not unique compared to others, but we had a lot of sensitive data. We have the body of the text message you just sent. And watching what’s happening with the January 6th investigation, having the bodies of text messages is pretty important and very dangerous in a lot of cases. You can imagine—we also have the recordings of audio calls and potentially a packet capture of audio of phone calls sometimes. And so one vector is, listen, we’re good, go towards zero. Our goal is to retain nothing. As a customer, we’ll give you a flag that says, listen, as soon as we have sent that text message, we will purge any record of it from all of our systems. We won’t even keep a record of the fact that you sent it, because that’s what you’ll want. It’s a good way to achieve GDPR, and guess what, we don’t have to retain data, our storage systems get smaller. This is a great story.

And then you think about, what is the value of a company? Is it more valuable that I throw away all your data, because that way you don’t have to worry about using me—think about Google not retaining any of your web searches—or is it more important that I have it but give it back to you in some valuable way? Like, you trust me, I’m going to encrypt it when I have it, nobody can steal it from me, and when you want it back, I’ll give it to you in any way you want it, you can filter it, you can order it, you can sort it, but you can also tell me to delete swaths of it. We felt like that was a much better story. As a company, I would rather be the company that owned all your data and was a great arbiter of it than the company that just purged all your data. And if you think about it, the corollary is a company like PayPal or Stripe, where as a company we don’t keep credit cards. None of us would stand up in business right now and say, yeah, go ahead and put your credit card into my web form and we’ll store it in the database for you—your credit card number and your CVC number and all those things, and we’ll just use it when you want to make a payment. You’d think we were crazy. What we do is we head it to Stripe or PayPal—you actually interact with them directly, we get this opaque token, I don’t even know what the heck it is, but when we want to charge, we ask them to charge you on your behalf, and they manage it. It’s their problem, their systems don’t get reached. Conceptually you want Twilio to be the same thing. Would you want to be the company that is retaining all of the text messages that were your interactions with your customers, or would you much rather have Twilio hold all that data, knowing that if you needed it you could go ask—hey, Peter had some interaction with my support team last month, what did he send and what did they respond to him with—but I don’t want to keep that in all my systems, because god forbid somebody breaches my system and my database, now I’m responsible for all this proprietary PII data. So that was a big path for us, and a shift internally, to say, no, no, we want to be the company that retains data, but we don’t do it carelessly. And that was a lot of the thinking around Segment—we want to acquire Segment, what do they do, how do they retain and store data?

Yeah, that’s because we need a whole stack of those types of companies. The back-end-as-a-service. I need my payments, I need my storage, I need my messaging, my core stack, and they’ve got to be people I trust and that aren’t going to screw it up.

Yeah, it’s tricky. It’s funny, we went down the GDPR path, I had meetings with a bunch of companies, and one of the companies I talked to was Autodesk. It’s funny, we get paired together and we have these long conversations. Autodesk has been around for 40-some-odd years. And they said, well, yeah, we’re doing GDPR, you know, what are you guys doing? So we have this event that comes through, somebody says, hey, this is my account, I want you to delete it. And so we just walk the database, we put an event on Kafka, all the systems listen to the Kafka bus, and then we just purge the data from the database, and then the backups will age out after 30 days and your data’s gone. I said, well, how are you guys tackling it? They said, well, it turns out we have about 50 databases, some of them are fronted by COBOL code nobody can read or write anymore, your email address might be in some of them, we’re not sure. If you gave it at a conference, one of our marketing guys might have it. We may be sending you emails out of one system, or text messages out of another system, we’re not sure. So what we’re going to do is open a Zendesk ticket and we’ll CC a bunch of engineers and people on it, and everybody’s job is to look at those tickets every month and go log onto those databases and purge the records you’re supposed to purge. So effectively, Mechanical Turk. And I said, oh, really? They said, we have no other choice. There’s no APIs between these systems, they’re totally disconnected, we can’t do anything else. It gives you that shift of, oh god, data’s become very important in APIs, and how you handle it, how you control it, how quickly you can be asked to delete it, what happens.

Yeah, it’s, I worked for the Obama administration doing the open data mandate, that all top-level cabinet agencies needed to go machine-readable by default for any public data. So it’s got to be publicly available as JSON and XML. And I’m the guy who went around to different agencies telling them they needed to do this and get ready for the deadline, and people were like, what’s JSON, what’s XML, what do you mean? Like, I manage this spreadsheet and it sits on my desktop computer and I email out reports to people. How am I supposed to—? So trying to migrate these legacy processes and people. And it just really speaks to the importance of APIs and getting that foundation laid, because it’s so key to the future and everything now, whether it’s business, regulation, anything.

Can’t agree more. So what’s the favorite thing you did over the last decade at Twilio?

I have a piece that I really enjoyed working on. It became and derived into two different things at first. We used to—obviously you can imagine all the phone calls that go across Twilio’s system, and that all used SIP as the protocol. And so in the early days we had basically two servers that sat on the edge that communicated with the carrier infrastructure. And so if you needed to debug a phone call—hey, what happened, why did that call—and actually, why did it take so long, why did the carrier hang up on us, did they hang up on us or was it the user—we would literally log onto one of those two servers, actually log onto both because you don’t know which one it hit, and go find that call. So you can imagine that was going to be hard to scale over time. And eventually Twilio’s infrastructure became global, and a phone call would actually take sometimes up to 11 hops for the SIP stack. It would go through a bunch of internal servers, it might go through an edge gateway, it would reroute it to another region because it turned out the guy on the other end of the call was in Paris. And so I built a system we called Call Meta that basically did a packet capture at the network layer, decoded the SIP protocol, and stored and extracted metadata in a distributed database system. And so the idea was you could effectively ask it about a phone call and say, go find me all the packet captures related to this phone call, cobble them back together, and draw me a ladder, so I can see which servers did this go through, what happened, who did what, where was latency introduced or not.

And it turned out you could repurpose that to start to see patterns of, like, are we seeing increased latency through a single availability zone for a single region, one single egress point—is it one of our servers, one of the media servers, in a carrier side that’s gone bad—or everything related to a region of the country, like, did somebody sever a transatlantic cable and therefore all the calls related to destination Belgium from New York are kaput? And so that was a lot of fun. It was a lot of fun to build a system that dealt with the protocol, that thought about, how am I going to store the data, how am I going to scale it, I can’t retain this forever, and what interface would a support person want or need such that they could go reach out to the carrier and go, hey, listen, we need to escalate, this is the issue. So that was a fun system to build and work on over time.

Yeah, those are the scope of problems—the data—this is what I love, I’m an old database guy since the ’80s, been doing databases, so I really love the explosion of metadata. But then you kept saying it, “see,” I want to be able to see, and I really feel like that’s the key part of our worlds right now, is helping people see this virtual realm. And that’s kind of the Segment acquisition, I would say to a certain degree—it makes it viewable, makes it manageable. These things are such large problems, any way we can get help to see things and manage them is valuable.

Yeah. And Segment was interesting, and it brought in—if you think about Twilio, it has the communication protocol, we know when you make the phone call, we know when you send the text message, but aside from your phone number, we don’t know who you are. We know nothing about you. You may have spent an hour on the Nike website looking at shoes and then decided you were going to call support, or we may have initiated a text message out to you to say, listen, here’s 20 percent off these cool new sneakers. But for Twilio, I don’t know you’re you, the only thing I know is here’s a string of text I sent to a phone number, whether it’s yours or not, I don’t know. Segment brought in the marriage of that other set of data that came from your website and from your CRM system. And so being able to combine those two is really the value prop in many ways. If you think about it as a support person, if when you called in it pulled up the rest of your record, showed me your purchase history, showed me your interactions and your name and email address—that is where the nirvana is. The marketing system, conceptually the same thing.

Yeah, we always lack context. The data and that visibility—yeah, we have no context. It’s the context you need to understand what’s this log file I’m looking at, or whatever I’m looking at, it gives it meaning for sure. So you’re a transactional company.

Yeah, exactly.

And that context, that meaning to the humans, I think is where the real value is, because then not just the end users but us as the startups and business people can connect the dots in more meaningful, purposeful ways that make our lives better, rather than just text for the sake of tech.

So you’ve moved on, you’re at ngrok now. What are you going to be doing there?

So my role there is CTO. Again, this is a technology story, similar to Twilio in many ways. It is a tool that enables people to bring their logic and their code and their servers to the rest of the world. If you think about it, there’s two challenges. One is, did I make an API—like we talked about for the last half hour or more—how easy is it to use, what does it look like? The second thing is, how do I get that out to the rest of the world? I think Postman deals with, like, how do I find it, how did I know it was there, what does it look like, how do I use it? But tactically, as an engineer within a software company, I have to figure out, how do I expose it, and how do I do it safely, and how do I do it at scale? And so for a lot of folks, it turns out that’s really hard to do, and ngrok really fulfills that niche, that makes it really easy, either as a developer during the developer flow of exposing something I’m playing with before I’m ready for the rest of the world to see it yet, or exposing something when I’m not knowledgeable about how to scale it and make it available, or controlling access to something. Like, I want to put it out there, but I only want people that authenticate through Google, I want to know who they are, I want to make sure the sessions are protected, I want to have visibility into those things. And so ngrok really represents that tool chain and that part of the developer ecosystem. It fulfills a part of the problem that I hadn’t seen a lot of companies do well.

And so I’ll be helping, from both the product direction and the technical journey, like, how do they build that at scale, how do you get observability at scale? And it’s a thing that just really has to work, which is hard. I think you guys, Postman’s in a very similar path, where, listen, while I was in the developer flow, it was fine. Using Postman, you’ve written your Postman scripts, using ngrok, I’m developing my website, ngrok’s down, Postman’s down, it’s like, yeah, it sucks, so go grab coffee, I’ll come back, they’ll probably be back online, I’ll go continue what I was doing. And then there’s the shift, where it’s like, well, no, my app is built on Postman, like every web request that comes through goes through Postman, or my app is standing on top of ngrok, and now the latency matters, the uptime matters, I can’t just do deploys where I take down the database and bring it back up an hour later, it all has to be up all the time. And so for me that’s sort of the fun, like, how do you operate this stuff at scale, how do you build it so that a few engineers can basically manage infrastructure for thousands? Otherwise I’m hiring thousands of engineers.

Yeah, and do it at scale, but do it with the reliability, the quality, and do more with less, because, you said, small teams, we’ve got to really be as efficient as we can and handle these loads. So, well, I think I’ll hit you up in maybe a year, come back and talk to me about what it looks like, and see what the landscape is. Because I think, especially with devices and things being connected to the internet—web and mobile, I’m excited about—but I think the connecting of everyday objects to the internet, and doing that in a reliably efficient, logical way, safe, secure, regulatory-compliant, all of that, I think is going to be super interesting, and that’s what I see ngrok at the center of.

Yeah, no, I think we’re in very similar journeys. I think we tackle different parts of the problem, but for what effectively is, hey, I’ve got a thing, I want the world to see it, for you, or even a segment of the world, help me do that. I think we have learned over time what is hard about that, what’s hard about defining an API that lives on, what’s hard about scaling infrastructure that makes it easy. But not everybody has the luxury, and they’re going to want to stand up stuff. And we’ve learned the same thing with AWS. You’ve been around long enough—we used to rack servers, we used to drag network cables and power, and it’s like, why would I do that again? The guys that were great at that were great at that, but no startup company could afford those guys, and even if they could, they wouldn’t want to hire them. So you pay AWS to do it, you pay them a premium. I’m renting a five-thousand-dollar box for a thousand dollars a month, I paid for the darn thing in half a month, but I paid for it again and again and again over the years, why would I do that? The answer is, I don’t have to deal with it, and they know what they’re doing.

Well, and it’s this evolution—for me, APIs represent this so—within the enterprise, very behind the firewall, and then APIs kind of jumped out of the SOA toolbox, web APIs, mobile, we had this public explosion that gave us Twilio and Stripe and others, but then we have this microservices evolution, which is again turning internally, I think, and using services. But now I think it’s just the world. We’re just all operating on the internet, there’s no “behind the firewall,” there’s just, I’ve got this thing I want to show here, put it up there, help me do it safely, securely.

Yeah, it’s the safety, security part that I think scares the Jesus out of most of us, because we don’t realize, as we all start living on the same infrastructure, the same things, if somebody messes something up, we all kind of go down for the run. We learned it with Log4j and other pieces, where it’s like, ah, somebody messed something up and we’re all using it, now what? So that’s scary.

Thanks for coming by and having this conversation with me. I really appreciate your insight, and look forward to maybe having this conversation again down the road.

No, it’d be great, Kin, I appreciate it.

Thanks again to Peter for stopping by. For more on Peter, you can find him on LinkedIn, where you can see what he’s building at ngrok.com. You can also subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.