Great Developer Experience with ngrok founder Alan Shreve

Alan Shreve 0:00
It's interesting as developers, we're like, we're constantly caught between two things that we love. One is things that just work. And the other is the, like desire to be able to like configure and twiddle every knob with with software that we have. And so those are, those are two, kind of like opposed problems. Hi, everyone,

Jack Bridger 0:23
you're listening to scaling dev tools, the show that investigates how dev tools go from zero to one, I'm joined today by Alan Shrieve, who is the founder and CEO of ngrok. And ngrok, is online in one line. They help you deploy your apps like incredibly efficiently, which I'll talk about in a minute. But Alan, thank you so much for joining.

Alan Shreve 0:46
Thank you so much for having me here, Jack. It's, it's a pleasure to be on and talking to you.

Jack Bridger 0:52
Thank you. And before we kind of dig in, I wanted to share how I discovered and grok for everyone just because I think it's such a amazing, such an amazing tool. And the way that I discovered it was cool. So I was working with a video API marks. And I wanted to test out web hooks to see when my video had uploaded. And when you're running this in localhost, there's no way to kind of pass your URL to receive, you know, the data when when you receive a notification when you're when your video is uploaded. But they recommended that I use ngrok. And once you instal an grok, you can just go and grok HTTP 3000. And your app is actually online. In the web, your local host is online. And if you save your file, it updates and it's it's really unbelievable. And it was one of those moments where it was just like, wow, that's like magic. And I've been kind of an unpaid advocate of ngrok ever since. So I'm really excited to speak with you today, Alan. And I wondered if you could talk a bit about how you arrived at this. This amazing tool?

Alan Shreve 2:06
Yeah, absolutely. That's a that's a really common discovery path for ngrok. That you mentioned, a lot of folks find us through various different documentation MCSA as an example, but we are embedded in Docs for GitHub, Atlassian, Microsoft, kind of all over the tech ecosystem. Because an grok really enables the usage of that that web hook piece, especially web hook development, and grok has, like found its way into those pieces of documentation.

Jack Bridger 2:44
Yeah, yeah. That's amazing. And how did you and I know this is something Keith, your colleague Keith is very passionate about as well is? How do you kind of create such a simple experience? Because I imagine it didn't start out so simple at the beginning.

Alan Shreve 3:05
That's a really good question. Simplicity is, is something that we think about a lot at ngrok. And something that we focus on, you know, when, when I think about it, there are there are a number of, you know, kind of like famous often miss attributed sayings, that kind of revolve around simplicity, things like, you know, I would have written a shorter letter, if I had more time, or, you know, you know, expertise, quote about perfection is achieved when you can't remove anything else. Those, those are really good directionally about, you know, thinking directionally about how simplicity is a tremendous amount of work to achieve, right, you spend a lot of time thinking about what is truly important, what is most important to user experience, and then trying to pull away all the other pieces of it. It's, it's interesting, as developers, we're like, we're constantly caught between two things that we love. One is things that just work. And the other is the, like desire to be able to, like configure and twiddle every knob with with software that we have. And so those are, those are two, kind of like opposed problems of something that just works versus something that you can configure. In every way. As a designer of those products. It's especially challenging because, you know, we talk a lot about, well, how do we solve the 90% use case? That's, you know, if you solve the 90% use case, you build something, you know, maybe you can keep it simple, right? By like ignoring the complexities of that that additional 10%. But, you know, the other thing that is especially true for developers is that that 10% and One to 10% is different, right of like what they want to configure inside of your tool or your application. And so you spend, basically, you have to make all of the things configurable. When you like, boil it down to like, well, given that problem space, you have folks who want to configure all the different pieces of your application, but you want to deliver something that is really simple and really delivers that magic moment that you experienced with ngrok, where you ran a single command, you imported a single line of code and your application was online. You're you're really thinking about, what are the choices that you can make as a product designer as a API designer? That you're you're taking each of those knobs that you can configure and trying to decide like, what is the sanest default that I can find for them? Or how can I delay that decision so that you can configure it but you don't have to upfront write that I've made the same choice for you. But But it can be changed later. Building that kind of flexibility and flow into your app is, is certainly challenging. There are a lot of decisions that you make about what to default someone to that may not be the right forever, right for everyone. But that is really the product design struggle in trying to like put all these things together is is finding that that simple interface, and either removing unnecessary choices or delaying choices that you can find sane defaults for?

Jack Bridger 6:32
Yeah, yeah, that that's really interesting. And I wonder if there's like, with that particular, kind of like the online in one line? Was that something that? How did that kind of emerge? Like, do you remember the kind of conversations and some of the stuff.

Alan Shreve 6:51
So ngrok was originally a solo project. So there weren't, there weren't a whole lot of like, internal conversations went on, it was like the very first iterations of the product were being developed. But, you know, lately, we've expanded upon that initial toolset, were originally ngrok was a, you know, a, a binary that you've downloaded and ran on your machine that provided you with that connectivity. And we're now starting to expand to a place where you can import and grok directly into your application, you don't actually have to run a separate executor will. Instead, you can import a library and basically add a single line of code that does the same thing that running the acceptable will do, which is give you something that puts your app online. But the thing that it returns to you is a socket, write something that looks and feels like a native socket object in the language that you're using. And so we had a lot of conversations about that about, you know, internally of how do we make that as simple as the developer tool that we built? How do we think about, you know, what are the interfaces that we have to implement? How can we collapse this into as few lines of code as possible? And that was definitely an internal struggle, right? Between us saying, Well, if we make it more lines of code, you can add more configuration? So like, how do we boil it down to like, the simplest piece that covers the majority use case?

Jack Bridger 8:22
Yeah, and how did you like, what was it? Lots of conversations and then just made a decision? Or how did you? It's,

Alan Shreve 8:31
it's definitely an iterative process, right? Where, you know, we have, we have a lot of that DNA baked into the organisation, about creating these simple interfaces. And so that was directionally where we are starting from, but actually getting there is is certainly a challenge where, you know, you like the first API's that we proposed for, you know, our, our ngrok go SDK that we just released. And the new ones that we're working on right now, which are ngrok, Ross and ngrok. J. S. The first versions of those are, you know, API's that we designed, and we implemented them and said, like, that's not exactly right, like, let's go, let's try it again, and again, and again, and iterated those things down. And the other half of it that we found, especially with library design, is two things really, one is, you know, one of the best ways to test your library is to actually use it, right, like become the consumer of it. And so when you, when you take those kinds of pieces and actually build on top of them yourselves, you really start to feel the pain that a developer would in like, you know, starting to integrate it. It's different, of course, and that you kind of like know how the library works underneath you, like know all the sharp corners and edges. But we do find that's one good way to pressure test those designs. And the other is really to go out to the community, right and like talk to folks and offer them first versions of them and get them to try to integrate them into their apps and gather feedback and iterate on the design. I in there as well. So it is by no means like a one and done sort of thing. Definitely not like a place where we like started off more like knew the exact solution to begin with, but one where we've arrived through constant iteration. And I would say that, you know, our designs for those are still not done, right, like they will continue to evolve. And that's, you know, one of the beautiful pieces of software is that you can continuously evolve your designs to make them more elegant.

Jack Bridger 10:33
Yeah, yeah, that makes sense. And kind of probably dropping, like five names here. But Keith shared an article from Swix, who's been on the show before, where Joel Spolsky was talking about Amazon's one click, and how Jeff Bezos for names was trying to kind of implement the one click Checkout, and how the team kept coming back with like four clicks and free clicks, and then two clicks. And Jeff Bezos was like, one click, one click, one click. And just to implement this, they had to build like a whole new system where there was like a 30 minute cooldown period, and it was really easy to edit your order and stuff like that. And I just wondered about, like, how much creating these kinds of really complex, so really simple systems, wherever it's like, you know, not only like a decision of where you focus, but also like, a lot of a lot of extra work to kind of create that simplicity.

Alan Shreve 11:40
Yeah, I've, I've watched that clip, it's, it's really great. It's, it's a really good encapsulation of that iterative process that I was talking about, of like chasing that simplicity. It's, it's interesting to draw that line between the simplicity of the user interface and the complexity of the system that implements it, right? Because that's, that's really what makes an grok. And Amazon's one click feel so magical is that simple interface to the complex system that we built. And grok is a really good example of that, in that, you know, when you run that one line, or you import that one library and add that one line of code to your application, you know, the things that are going on underneath the hood to actually deliver that are is, you know, a large complex system where, you know, when you run your application, and ask it to listen on ngrok, it is connecting to essentially like all of our global points of presence and transmitting configuration requirements to them. And they are all like reloading in real time, to basically push your configuration out to our Global Edge, the infrastructure to run that the software to make that happen, you know, and feel instantaneous, is by no means simple to implement. But there is, but it is really joyful to create that that magical experience, right? Where you hide all of that complexity.

Jack Bridger 13:12
Yeah, yeah, it is amazing. And I just kind of wondering, because on the surface, I felt like everyone would agree with you. You know, like, okay, simplicity is really important, you've got to get the right balance between simplicity and complexity. But it's pretty clear to me like that, you're a lot further down that path than most developer tools. And I just kind of wondered, like, if there's, if there is any, any kind of like, specific things that you do internally that, like, the other dev tools might learn from and kind of try to, you know, to kind of get to that place?

Alan Shreve 13:53
That's a good question. I think, you know, predominantly, it is a mentality it is, is, you know, there are product processes that you can put into place that will help you chase that simplicity. But you really do have to have, you know, that kind of like Jeff Bezos, Steve Jobs like position, right of saying like this, this has to be simple, right? We have to find the minimal interface to begin with. And a lot of it falls out from that intention, I would say.

Jack Bridger 14:38
Yeah. Yeah. That makes sense. So it's like the cultural, like, importance that you put upon it across the whole organisation.

Alan Shreve 14:49
Yeah, exactly. It's, it's something that we measure and track internally. Like one of the things that we measure and track internally is Do you know essentially like time to value between when someone signs up to ngrok, and they are able to essentially like, start and grok, like start an application that is listening on ngrok and receive traffic. That's a metric that we track. It's a it's a KPI that we think about. And we're, we're really proud that, you know, we have we have folks that, you know, basically, like, sign up for the product and have it working in 30 seconds. Like, that's an incredible, like, it's an incredible feat. For us, we're like, really, you know, and we're, we're constantly thinking about, like, how do we push that lower? Or how do we get, you know, the long tail of folks who are, you know, in minutes or hours, like, how do we bring them down to, to that 30 seconds? Yeah, so I don't know, those are, that's one way that you think about it.

Jack Bridger 15:53
Yeah, that's really cool. And so, I guess I'm using it mostly as, like, I'm a free customer at the moment. Because I'm mostly like working on hobby projects, trying to get something off the ground. And I'm using it kind of as a solo person. And it's been amazing. And I just wondered how, how do you kind of think about users like me, or, you know, similar users? And, like, how do they become, you know, people that pay people that have like, Hold teams and that sort of thing?

Alan Shreve 16:34
Yeah, the, there are two ways to think about that. One is, you know, we, we absolutely love of folks who are using the product, like you were, you know, using it for personal projects, and doing small development use cases. Our mission at ngrok is to empower developers, we want to make developers more successful more, you know, easier for them to do their job. And, you know, going back to what we were talking about earlier, is we are trying to create that simplicity, that abstraction around networking, that application, developers shouldn't have to think about these low level networking bits to actually get their jobs done, right. More than that, there's a whole, like, slew of things that we can take off your plate that we can potentially like implement for you in that kind of proxy layer, so that you're able to like actually skip to writing the business logic. So the one, you know, really short answer is, you know, we, we'd love, you know, free tier users, free tier developers who are building on top of the platform, it's really meaningful to us to like see that usage, understand how folks are using the platform, because ultimately, regardless of whether you're paying or not like you have, you know, the same kind of like developing problems, right, so all of those, like feed into the product process of understanding, like what people are doing, and how can we make the product better? The other half of that question is like, what, how do how does, like a hobbyist use case, like expand into something that is commercial or paid? The, you know, there, they're kind of like two directions that that goes, one is just sheer usage, right, you're using so much of the product that, you know, our feature has, you know, some set of like reasonable limits around how much of the resources of our platform that you can use. And so commercial use cases often have like higher resource usage, and that will kick you into some kind of paying tear. The other is, you know, there are some set of, you know, when you're using the developer tool, as a hobbyist, this is kind of like part of ngrok. So like, product lead growth strategy, right, is that, you know, maybe you're using just a small corner of things, but you don't need to put SAML in front of your hobbyist use case, you know, your hobbyist tear, right, or your personal project. But, you know, you know, that it's there, right, you've like seen the capabilities that the platform has offered. And understand that, you know, if you were to use this in a commercial way, like you have a problem to solve it your job, that you're, you're aware that I'm Brock, can help you out there. And so that's another way that we've seen a lot of folks jump into the commercial offerings that they've been using on rocket home, you know, are aware that it can essentially like that same magic moment that you have for solving, you know, your your personal problems, your web hook development thing is, you know, we endeavour and strive to have that same magic moment for putting production applications on the internet as well. And, you know, making that jump from free commercial is often about being aware of that and like finding the use case Uh, at work, you know, in your in your job or in, in commercial life in general. And translating it saying like, I know that and, you know, really solve that one problem, like, let's see if we can solve another problem really easily.

Jack Bridger 20:12
Yeah. Yeah, that makes sense. And how do you think about like the problems that ngrok solves? Because it seems like there's so many paths that you can kind of go?

Alan Shreve 20:26
Yeah, I would say that. We're ngrok is focused as as a company, right? Where we're, you know, really taking the product is in a direction where ngrok is focused on solving the problem of putting applications online creating Ingress, network ingress to applications, you know, we talked about ngrok being a ingress as a service platform. And that means that we are solving that problem of how do I put my application on the internet, right. And there are many additional problems that come with putting your application on the internet, like, the sheer problem of connectivity is one that is, I would say, like somewhat relatively well solved. But it actually isn't when you think about actually like putting something on the internet. These days, it is IP addresses and DNS and TLS certificates. And often like ingress and egress gateways and VPC, like elastic IP associations right there, there's a whole mess of things that are actually required. Which, you know, we talk internally about all of those problems being that developers are, when it comes to networking are still really working with like the assembly language of networking. We haven't built the right abstractions for application developers to work with the networking primitives. And so we're still like stuck using these very low level primitives to solve this much higher layer, problem, this higher level job that we really want to solve. So you know, and grok, and rocks job, our platform is thinking about how do we take those low level primitives and create this abstraction layer on top? That really solves the problem in an easy way. So like I said, one of those is just pure connectivity, which is somewhat solved, but it's still harder than it needs to be. And then a set of additional problems that we really think about solving on top, which are how do I add authentication to my application? Right? Have I only want a certain set of people to access the application? Or how do I observe the application, I want to see all the traffic that's routing to it? Or how do I protect the application from attacks or from accidental like overloads, or the application is down. And so building a lot of those primitives into an rocks essentially, like proxy layer, that allows us to solve those problems for application developers with very minimal configuration on their own. That's, you know, that fits into our overall mission of how do you get an application online?

Jack Bridger 23:15
That's really cool. Yeah, so it's, it's like, you're just essentially letting developers just write business logic, and then everything on the kind of Online Plus like scale, and authentication and security, all of that will be kind of easily assembled or solved.

Alan Shreve 23:43
That's, that's really, you know, the direction that we're we're pointing and rockin. We want it to be like that kind of like, powered like mech suit of armour that you like drop your application into, and it gets it gets superpowers. Another way to think about this, as you know, we want application developers to focus on building applications, right and not on solving, rate limiting and concurrency learning and a whole bunch of other things that you have to do to like put your application online. One of the things that we talked about internally is, you know, and this is maybe like, part of that mentality we were talking about earlier is, you know, how do we allow a developer to like, build something over the weekend at a hackathon, and put an grok in front of it and go to production on Monday, right of like, be able to sell it to businesses or consumers on Monday. And there are a lot of challenges that, you know, that are required to get there are a lot of challenges to solve in order to get there. But directionally, that's, you know, kind of how we think about solving this problem. And where we want to take the product.

Jack Bridger 24:48
Yeah, that's Dow. I mean, that sounds sounds amazing. That would be incredible. Yeah, it's all the fun stuff. Developers they'll do all the fun stuff. And then you just you take care of the rest.

Alan Shreve 25:05
It all depends on what you think is the fun. This is the fun stuff for us, right? Yeah. Yeah.

Jack Bridger 25:11
Yeah. True. Yeah. poorly phrased. Yeah, that's really cool. And one of the things that we've been asking people recently, because we're probably coming to the end of our time, is what takeaway you would have for other developers or founders, people working at dev tools that you think ngrok has learned.

Alan Shreve 25:40
I mean, following up on on our theme here today, I would say that, you know, one of the things that we've learned that I, you know, that I love talking about with with other folks is about that, that effort, and that drive for creating simplicity of like finding the right abstraction. And understanding that it really, truly is an iterative process, that you, you really spend a lot of time but on getting there. And the important pieces that like directional alignment of like, that's the thing that you're you're really chasing after.

Jack Bridger 26:15
Yeah, that makes sense. And if people want to learn more about ngrok, or they want to hear what you're up to, where can they learn more?

Alan Shreve 26:25
Yeah, it's just ngrok.com, that'll take you to to our website where you can, or follow our blog, which is blog.ngrok.com. You know, has all the announcements of all the things that we're working on and shipping to the world?

Jack Bridger 26:40
Amazing, amazing.

Alan Shreve 26:42
Yeah, I mean, the things that, you know, we're, we've like launched recently that we're really most excited about our one, our kind of like Native SDKS, I talked about these a little bit earlier, which is, you know, this ability to embed ngrok directly into your application and get something that back that looks like a socket object that you can just include directly into a piece of software that already like works with the native networking primitives in the languages that you use, we're really excited about that concept of allowing you to, you know, instead of listening on a port, you listen on all event Rock's global network, but from your applications perspective, is just as if it was on a local port, we think this is going to like further increase and grok simplicity, especially when you're deploying applications out to the world, that you don't have to package and grok alongside of your application, it just like that networking capability is just embedded directly into it. So that's one thing that we're super excited about. The other that we, you know, we just launched today, actually, as we moved a couple of those security primitives that I was talking about earlier about how ngrok allows you to wrap authentication around your app, we moved a couple of those security primitives into the free tier, we're on a mission to make sure that, you know, when you put applications out into the world, that you, you know, those applications should be secured, right. And so we've added the capability to basically seamlessly put any kind of OAuth you want in front of the application, as well as a really common use case that you were talking about earlier, which is consuming web hooks, we have the ability for you to essentially like supply ngrok with the web booksigning secret from a given provider. And it will run those signature validation routines, essentially at our Global Edge before any traffic will come back to your application. So if we're really excited to offer those security primitives out to the world, and really like start making all the applications that are, you know, exposing themselves to the world more secure by using those those parameters for authentication.

Jack Bridger 28:45
Yeah, amazing. Amazing. And thanks, everyone, for listening. Thanks so much for joining Alan, as you know, a big fan of ngrok. So this was really exciting. And I hope everyone forgives me for being such a fan of ngrok on the show. Yeah, it's been awesome. Thank you very much.

Alan Shreve 29:06
Thank you so much for all the great questions, Jack. It's been really a pleasure of being here and speaking with you.

Jack Bridger 29:11
Thanks, first of all for listening and see you next week. Oh, and thank you for key for organising. Thanks, bye

Transcribed by https://otter.ai