Screaming in the Cloud - Remote Versus Local Development with Mike Brevoort

Episode Date: May 23, 2023

Mike Brevoort, Chief Product Officer at Gitpod, joins Corey on Screaming in the Cloud to discuss all the intricacies of remote development and how Gitpod is simplifying the process. Mike explains why he feels the infinite resources cloud provides can be overlooked when discussing remote versus local development environments, and how simplifying build abstractions is a fantastic goal, but that focusing on the tools you use in a build abstraction in the meantime can be valuable. Corey and Mike also dive into the security concerns that come with remote development, and Mike reveals the upcoming plans for Gitpod’s local conference environment, CDE Universe. About MikeMike has a passion for empowering people to be creative and work together more effectively. He is the Chief Product Officer at Gitpod striving to remove the friction and drudgery from software development through Cloud Developer Environments. He spent the previous four years at Slack where he created Workflow Builder and “Platform 2.0” after his company Missions was acquired by Slack in 2018. Mike lives in Denver, Colorado and enjoys cycling, hiking and being outdoors.Links Referenced:Gitpod: https://www.gitpod.io/CDE Universe: https://cdeuniverse.com/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. It's easy to f*** up on AWS, especially when you're managing your cloud environment on your own.

Mission Cloud unf***s your apps and servers. Whatever you need in AWS, they can do it. Head to missioncloud.com for the AWS expertise you need in AWS, they can do it. Head to missioncloud.com for the AWS expertise you need. Have you listened to the new season of Traceroute yet? Traceroute's a tech podcast that peels back the layers of the stack to tell the real human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I have had loud, angry, and admittedly at times uninformed opinions about so many things over the past few years. But something that predates that a lot is my impression on the idea of using remote systems for development work as opposed to doing local dev. And that extends to build and the rest. And my guest today here to argue with me about some of it, or agree, we'll find out, is Mike Brevoort, Chief Product Officer at Gitpod, which I will henceforth be mispronouncing as Jitpod because that is the type of jerk I am. Mike, thank you for joining me.

Thank you for insulting my company. I appreciate it. No, by all means, it's what we do here. So you clearly have opinions on the idea of remote versus local development. And I am using the word remote development. I know you folks like to use the word cloud in place of remote. But I'm curious to figure out, is that just the zeitgeist that has shifted? Do you have a belief that it should be in particular places, done in certain ways, etc.? What are your opinions on this start and stop?

I think that, I mean, remote is accurate, an accurate description. I don't like to emphasize the word remote because I don't think it's important that it's remote or local. I think that the term cloud connotes different values around the elasticity of environments and the resources that are more than what you might have on your local machine versus a remote machine. It's not so much whether the one machine is local or remote as much of it is that there are infinite numbers of resources that you can develop across in the cloud. That's why we tend to prefer cloud development environments. From my perspective, I've been spending too many years now living in basically hotels and airports. And when I was doing that for a long

time, the only computer I bring with me has been my iPad Pro. That used to be a little bit on the challenging side. And these days that's gotten capable enough where it's no longer interesting in isolation. But there's no local development environment that is worth basically anything on that. So I've been SSHing into things and using VI as my development environment for many years. When I started off as a grumpy Unix sysadmin, there was something reassuring about the latest state of whatever it is I'm working on lives in a data center somewhere rather than on a laptop I'm about to leave behind in a coffee shop because I'm careless. So there's a definite value and sense that I am doing something virtuous historically.

But it didn't occur to me until I started talking to people about this, just how contentious the idea was. People would love to ask all kinds of fun objections to this, where it was, oh, well, what about when you're on a plane and you need to do work? It's, well, I spend an awful lot of time on planes, and that is not a limiting factor

in me writing the terrible nonsense that I will charitably call code in my case. I just don't find that that idea holds up anymore. The world has become so increasingly interconnected that that seems unlikely, but I do live in San Francisco. So here, every internet is generally pretty decent. Not every place is. What are your thoughts?

I agree. I mean, I think one thing is I would just like not to think about it, whether I can or can't develop because I'm connected or not. And I think that we tend to be in a world where that is is more so the case. And I think a lot of times when you're not connected, you become reconnected soon. Like if your connection is not reliable or if you're going in and out of connectivity issues. And when you're trying to work on a local laptop and you're connecting and disconnecting, it's not like we develop these days and everything is just isolated on our local laptop, especially we talk about cloud a lot on this podcast. And a lot of apps now go way beyond

just I'm running a process on my machine and I'm connecting to data on my machine. There are local emulators you could use for some of these services, but most of them are inferior. And if you're using SQS or using any other like cloud-based service, you're usually as a developer connecting to some version of that. And if you're disconnected anyway, you're not productive either. And so I find that it's just like an irrelevant conversation in this new world and that the way we've developed traditionally has not followed along with this view of, I need to pile everything in on my laptop to be able to develop and be productive, has not followed along with the trend that moved into the cloud. Right. The big problem for a long time has been, how do I make this Mac or Windows laptop look a lot like a Linux EC2 instance? And there have been a bunch of challenges and incompatibility issues in the RAST.

And from my perspective, I like to develop in an environment that at least vaguely resembles the production environment it's going to run in. Which at AWS's case, of course, comes down to expensive, but don't tiss. Yeah, it's a really big challenge. It's been a challenge, right?

When you've worked with coworkers that were on a Windows machine and you were on a Mac machine and you had the one person on their Linux machine forever. And we all struggled with trying to mimic these development environments that were representative ultimately of what we would run in production. And if you're counting costs, we can count the cost of those cloud resources. We can count the cost of those laptops, but we also need to count the cost of the people who are using those laptops and how

inefficient and how much churn they have and how, I don't know, there was for years of my career, someone would show up every morning to the stand up meeting and say, it's like, well, I wasted all afternoon yesterday trying to work out my issues with my development environment. And it's like, I hope I get that sorted out later today and I hope someone can help me. And so I think cost is one thing. I think that there's a lot of inconsistencies that lead to a lot of inefficiencies and churn. And I think that regardless of where you're developing, the more that you can make your environments more consistent and sound, not for you, but for your own team and have those be more representative of what you are running in production, the better. We should disambiguate here because I fear this is one of the areas where my use case tends to veer off into the trees, which is I tend to operate largely in isolation from a development

point of view. I build small micro things that wind up doing one thing poorly. And that is like what I do as a proof of concept or to be funny or to kick the tires on a new technology. I'll also run a bunch of random things I find off of Github. Yes, that's how I pronounce GitHub. And that's great, but it also feels like I'm burning as a result every stack and

every language in every various version that it has. And very few of the cloud development environments that I've seen really seems to cater to the idea that simultaneously, I want to have certain affordances in my shell environment set up the way that I want them. Tab complete this particular suite of tools generically across the board, but then reset to that baseline and go in a bunch of different directions of today, it's Python in this version, and tomorrow it's Node in this other version,

and three, what is a TypeScript anyway? And so on and so forth. It feels like it's either, in most cases, you either get this generic, one size fits everyone in this company for this project approach, or it's, here's a very baseline, untuned thing that does not have

any of your dependencies installed, start from scratch every time. And it feels like there are two paths and they both suck. Where are you folks at these days on that spectrum? Yeah, I think that, one, if you do all of that development across all these different libraries and technology stacks, and you're downloading all these repos from GIF Hub, is that right? And you're experimenting, you tend to have a lot of just collision of things. Like if you're using Python, it's like really a pain to maintain isolation

across projects and not have, like your environment is like one big bucket of things on your laptop. And it's very easy to get that into a state where things aren't working. And then you're struggling. There's no big reset on your laptop. I mean, there is, but it takes,

it's a full reset of everything that you have. And I think the thing that's interesting to me about cloud development environments is I could spin one of these up. I could trash it to all hell and just throw it away and get another one. And I could get another one of those at a base of which is been tuned for whatever project or technology I'm working on. So I could take, you know, do the effort to preset up environments. One that is set up with all of my like Python tooling, another one that's set up with all my like Go or Rust tooling or front end development, even as a base repo for what I tend to do or might tend to experiment with. Or what we find is that whether you're working alone or you're working with coworkers,

that setting up a project and all the resources and the modules and the libraries and the dependencies that you have, someone has to do that work to wire that up together. And the fact that you could just get an environment and get another one and another one, we use this analogy of tissue boxes, where you should just be able to pull a new dev environment out of a tissue box and use it and throw it away and pull as many tissues out of the box as you want. And they should be cheap and ephemeral, and they shouldn't be be long lived because they shouldn't be able to drift. And whether you're working alone or you're working in a team, it's the same value. The fact that like I can pull one of these out, I have it, I'm confident in it of what I got. Like for

example, ideally you would just start a dev environment. It's available instantly and you're ready to code. You're in this project with, and maybe it's a project you've never developed on. Maybe it's an open source project. This is where I think it really improves the sort of equitability of being able to develop, whether it's an open source, whether it's inner source and companies, being able to approach any project

with the click of a button and get the same environment that the tech lead on the project who started it five years ago has. And that I don't need to worry about that. And I get the same environment. And I think that's the value. And so whether you're individual or you're on a team, you want to be able to experiment and thrash and do things and be able to throw it away and start over again and not have to, like, for example, maybe you're doing that on your machine and you're working on this thing and then you actually have to do some real

work. And then now that you've done something that conflicts with the thing that you're working on this thing and then you actually have to do some real work. And then now that you've done something that conflicts with the thing that you're working on and you're just kind of caught in this tangled mess where it's like, you should just be able to leave that experiment there and just go work on the thing you need to work on. And why can't you have multiples of these things at any given time?

Right, one of the things I loved about EC2 dev environments has been that I can just spin stuff up and, okay, great. It's time for a new project, spin up another one and turn it off when I'm done using it, which is the lie we always tell ourselves in cloud and get charged for things we forget to turn off. But then, okay, I need an Intel box one day. Done. Great. Awesome. I don't have any of those lying around here anymore, but clickety clickety, and now I do. It's nice being able to have that flexibility, but it's also sometimes disconcerting

when I'm trying to figure out what machine I was on when I was building things and the rest, and having unified stories around this becomes super helpful. I'm also finding that my overpowered desktop is far more cost-efficient when I need to compile something challenging as opposed to finding a big, beefy EC2 box

for that thing as well. So much of the time, what my remote system is doing is sitting there bored. Even when I'm developing on it, it doesn't take a lot of modern computer resources to basically handle a text editor. Unless it's Emacs, in which case that's neither here nor there. I think that the thing that becomes costly, especially when using cloud development environments, is when you have to continue to run them even when you're not using them for the sake of convenience, because you're not done with it.

You're in the middle of doing some work and it still has to run or you forget to shut off. If you're going to just spin up a really beefy EC2 instance for an hour to do that big compile and it costs you 78 cents, that's one thing. I mean, I guess that adds up over time. And yes, if you've already bought that Mac Studio that's sitting under your desk humming, it's gonna be more cost-efficient to use that thing. But there's like an element of convenience here that like, what if I haven't bought the Mac Studio,

but I still need to do that big beefy compilation? And maybe it's not on a project I work on every single day. Maybe it's the one that I'm just trying to help out with or just starting to contribute to. And so I think that we need to get better about and something that we're very focused on at JITPod is our good pod is. I'm going to get you in trouble at this rate. Is really to optimize that underlying runtime environment so that we can optimize the resources that you're using only when you're using it, but also provide a great user experience, which is for me as someone who's responsible for the product to get pod. The thing I want to get to is that you're paying for, that there's a meter spinning, that if you forget it, that you're like, ah, it's going to cost me a lot of money, that I have to worry about ever losing it. And really, I just want to be able to get a new

environment, have one, use it, come back to it when I need it, have it not cost me a lot of money, and be able to have five or 10 of those at a time because I'm not as worried about what it's going to cost me. And I'm sure it'll cost something, but the convenience factor of being able to get one instantly and have it and not have to worry about it ultimately saves me a lot of time and aggravation and improves my ability to focus and get work done. And right now we're still in this mode where we're still thinking about, is it on my laptop? Is it remote? Is it on this EC2 instance or that EC2 instance, or is this thing started or stopped? And I think we need to move beyond that and be able to just think of these things as development environments that I use and need and they're there where I want

to when I need to work on them and I don't have to tend to them like cattle. Speaking of tending large things in herds, I guess, that's sort of the most tortured analogy slash segue I've come up with recently. You folks have a conference coming up soon in San Francisco. What's the deal with that? And I'll point out it's all on-site locally, not in the cloud.

So, hmm. Yeah, so we have a local conference environment, a local conference that we're hosting in San Francisco called CDE Universe on June 1st and 2nd. And we are assembling all the thought leaders in the industry who want to get together and talk about where not just cloud development is going, but really where development is going. And so there's us, there's a lot of companies that have done this themselves. Like before I joined Gitpod, I was at Slack for four years and I got to see the transition

of a sort of remote development hosted on EC2 instances transition and how that really empowered our team of hundreds of engineers to be able to contribute and like work together better, more efficiently to run this giant app that you can't run just alone on your laptop.

And so Slack's going to be there. They're going to be talking about their transition to cloud development. The Uber team is going to be there. There's going to be some other companies. So Nathan, who's building Zed, he was the one that originally built Atom at GitHub, is now building Zed, which is a new IDE, is going to be there. And I can't mention all the speakers, but there's going to be a lot of people that are really looking at how do we drive forward development and development environments? And that experience can get a lot better.

So if you're interested in that, if you're going to be in San Francisco on June 1st and 2nd and want to talk to these people, learn from them and help us drive this vision forward for just a better development experience, come hang out with us.

I'm a big fan of collaborating with folks and figuring out what tricks and tips they've picked up along the way. And this is coming from the perspective of someone who acts as a solo developer in many cases. But it always drove me a little nuts when you see people spending weeks of their lives configuring their text editor, Vim in my case, because I'm no better than these people. I have one of them. And getting it all set up and dialed in. It's how much productivity are you gaining versus how much time are you spending getting there? And then when all was said and done a few years ago, I found myself switching to VS Code for most of what I do because it's great. And suddenly the world's shifting on its axis again. There's at some, you want to get away from focusing on productivity

on an individualized basis. Now, the rules change when you're talking about large teams where everyone needs a copy of this running locally or in their dev environment, whatever that happens to be. And you're right.

Often the first two weeks of a new software engineering job are, you're now responsible for updating the onboarding docs because it's been 10 minutes since the last time someone went through it. And, oh, the version's bumped again of what happens when you type brew install on a Mac and suddenly everything's broken. Yay. I don't miss those days.

Yeah. The new like ARM-based Macs came out and then you're, now all of a sudden all your builds are broken. We hear that a lot. Oh, what I love now is that in many cases, I'm still in a process of, okay, I'm developing locally in an ARM-based Mac, and I'm deploying it to a Graviton2-based Lambda or instance, but the CICD builder is going to run on Intel. So it's one of those, what is going on here? Like there's a tool chain lag around embracing ARM as an architecture

that's mostly been taken care of as things have evolved, but it's gotten pretty amusing at some point just as how quickly that baseline architecture has shifted for some workloads and for some companies. Yeah. And things just seem to be getting more and more complicated, not less complicated. And so I think the more that we can try to simplify, build abstractions, you know, the better. But in those cases where I think it's actually good for people to struggle with setting up their environment sometime with caring about the tools that they use and their experience developing. I think there has to be some ROI with that.

If it's like a chronic thing that you have to continue to try to fix and make better, it's one thing. But if you spend a whole day improving the tools that you use to make you a better developer later. I think there's a ton of value in that. I think we should care a lot about the tools we use. However, that's not something we want to do every day. I mean, ultimately, I know I don't build software for the sake of building software. I want to create something. I want to create some value, some change in the world. There's some product ultimately that I'm trying to build. And early on, I've done a lot of work in my career on like workflow type builders and visual builders.

And I had this incorrect assumption somewhere along the way. And this came around like sort of the maker movement when everybody was talking about everybody should learn how to code. And I made this assumption that everybody really wants to create. Everybody wants to be a creator

and if given the opportunity, they will. And I think what I finally learned is that actually most people don't like to create. A lot of people just want to be served. Like they just want to consume and they don't want the hassle of it. Some people do if they have the opportunity and the skill sets too,

but it's also similar to like, if I'm a professional developer, I need to get my work done. I'm not measured on how well my local tooling is set up. I'm sort of measured on my output and the impact that I have in the organization. And I tend to think about like chefs, if I'm a chef and I work 60 hours in a restaurant, 70 hours in a restaurant, the last thing I want to do is come home and cook myself a meal. Like, and most of the chefs I know actually don't have really nice kitchens at home. They like tend to, they want other people to cook for them. And so I think like there's a place in a professional setting where you just need to get the work done and you don't want to worry about

all the meta things and the time that you could waste on it. And so I feel like there's a happy medium there. I think it's really, it's good for people to care about the tools that they use, the environment that they develop, and to really care for that and to curate it and make it better. But there's got to be some ROI and it's got to have value to you. You have to enjoy that. Otherwise, you know, what's the point of it in the first place? One thing that I used to think about was that if you're working in regulated industries, as I tended to a fair bit, there's something very nice about not having any of the data or IP or anything like that locally. Your laptop effectively just becomes a thin client to something that's already controlled by the existing security and compliance apparatus.

That's very nice, where suddenly it's, oh, someone steals my iPad, or I drop it into the bay, it's locked, it's encrypted, cool. I go to the store, get myself a new one, restore a backup from iCloud, and I'm up and running again in a very short period of time, as if nothing had ever changed. Whereas when I was doing a lot of local development and had bad hard drive issues in the earlier part of my career, well, there goes that month. Yeah, it's a really good point. I think that we're all walking around with these I'm on a local coffee shop and the latest vulnerability that an update I have to do on my Mac if I'm behind. And there's actually a lot of risk in having all that just sort of thrown to the wind and

spread across the world. And there's a lot of value in having that in a very safe place. And what we've even found that at Gitpod now, like the latest product we're working on is one that we call Gitpod Dedicated, which gives you the ability to run inside your own cloud perimeter. And we're doing that on AWS first. And so we can set up and manage an installation of Gitpod inside your own AWS account. And the reason that became important to us is that a lot of companies, a lot of our customers treat their source code as their most sensitive intellectual property, and they won't allow it to leave their perimeter. They may run AWS, but they have this concept of our perimeter, and you're either inside

of that and outside of it. And I think this speaks a little bit to a blog post that you wrote a few months ago about the lagging adoption of remote development environments. I think one of those aspects is sort of convenience and the user experience, but the other is that you can't use them very well with your stack and all the tools and resources that you need to use if they're not running sort of close within your perimeter. And so, you know, we're finding that companies have this need to be able to have greater control.

And now with the sort of trends around like coding assistance and generative AI, and it's even the perfect storm of not only am I like sending my source code from my editor out into some LLM, but I also have the risk of an LLM that might be compromised, that's injecting code that I'm committing on my behalf that may be introducing vulnerabilities. And so I think getting that off to a secure space that is consistent and sound and can be monitored and be kept up to date, I think has the ability to sort of greatly increase a customer's security posture. While we're here kicking the beehive, for lack of a better term, we support for multiple editors in Gitpod, the product. I assume that most people would go with VS Code because I tend to see it

everywhere. And I couldn't help but notice that neither VI nor Emacs is one of the options the last time I checked. What are you seeing as far as popularity contests go? And that might be a dangerous question because I'm not suggesting you alienate many of the other vendors who are available, but in the world I live in, it's pretty clear where the zeitgeist of my subculture is going. Yeah, I mean, VS Code is definitely the most popular IDE. The majority of people that use Gitpod, especially we have like a pretty heavy free usage tier, uses it in the browser just for the convenience of having that in the browser and having many environments in the browser. We tend to find more professional developers use VS Code Desktop or the JetBrains suite of IDEs. Yeah, JetBrains I'm seeing a fair bit of in a bunch of different ways.

And I think that's actually most of what your other options are. I feel like people have either gone down the JetBrains path or they haven't. And it seems like people who are into it are really into it, and people who are not just never touch it. Yeah, we want to provide the options for people to use the tools that they want to use and feel comfortable in. And we also want to provide a platform for the next generation of IDEs to be able to build on and support and to be able to support this concept of cloud or remote development more natively. So like I mentioned, Nathan Asobo at Zed, I met up with him last week. I'm in Denver, he's in Boulder, and we were talking about this. And he's interested in Zed working in the browser. He's, I'm in Denver, he's in Boulder. And we were talking about this and he's interested in, you know, Zed working in the browser.

And he's talked about this publicly. And for us, it's really interesting because like IDEs working in the browser is like a really great convenience. It's not the perfect way to work necessarily in all circumstances. There's some challenges with like all this tab sprawl and stuff,

but it gives us the opportunity if we can make Zed work really well and for Gitpod or anybody else building an IDE for that to work in the browser. And ultimately what we want is that if you want to use a terminal, we want to create a great experience for you for that. And so we have, we're working on this ability in Gitpod to be able to effectively like bring your own IDE if you're building on that and to be able to offer it and distribute on Gitpod, to be able to create a new developer tool and make it so that anybody in their Gitpod workspace can launch that as part of their workspace, part of their tool. And we want to see developer tools and IDEs flourish on top of this platform that is cloud development because we want to give people choice.

Like at Gitpod, we're not building our own IDE anymore. The team started to, they created Thea, which was one of the original cloud sort of web-based IDEs that now has been handed over to the Eclipse Foundation. But we moved to VS Code because we found that that's where the ecosystem or that's where our users were, our customers and what they wanted to use. We want to expand beyond that and give people the ability to choose not only the options that are available today, but the options that should be available in the future. And we think that choice is really important. When you see people kicking the tires on Gitpod for the first time, where does the bulk of their hesitancy come from? Like, what is it where people, in my experience, don't love to embrace change. So it's always this thing sucks is sort of the default response to anything that requires them

to change their philosophy on something. So, okay, great. That is a thing that happens. We'll see what people say or do, but are they basing it in anything beyond just familiarity and comfort with the old way of doing things? Or are there certain areas

that you're finding that new customers are having a hard time wrapping their head around? There's a couple of things. I think one thing is just habit. People have habits and preferences, which are really valuable because it's the way that they've learned to be successful in their careers and the way that they expect things. Sometimes people have these preferences that are fairly well ingrained that maybe are irrational or rational.

And so one thing is just people's force of habit. And then getting used to this idea that if it's not on my laptop, it means like what you mentioned before, it's always what if. So like, what if I'm on a plane? Or like, what if I'm at the airport in a hurricane? What if I'm on a train with a spot internet connection? And so there's all these sort of what ifs situations. And once people get past that and they start actually using Gitpod and trying to set their projects up. The other limiting factor we have is just connectivity. And that's like connectivity to the other resources that you use to develop. So whether that's a package or module repositories, or that's some internal services or a database that might be running behind a firewall, it's like getting connectivity to those things.

And that's where the dedicated deployment model I talked about running inside of your perimeter on a network they have control over kind of helps. And that's why we're trying to overcome that. Or if you're using our SaaS product, using something like Tailscale or a more modern VPN that way. But those are the two main things. It's that it's like familiarity, this comfort for how to work sort of in this new world and not having this level of comfort of like it's running on this thing I can hold as well as connectivity. And then there is some cost associated

with people now paying for this infrastructure they didn't have to pay for before. And I think it's a mistake to say that we're going to offset the cost of laptops. Like that shouldn't be how you justify a cloud development environment. Yeah, I feel like people are not requesting under spec laptops much these days anymore.

It's just like you want, I want to use a good laptop. I want to use a really nice laptop with good hardware. And that shouldn't be the cost. The proposition shouldn't be, it's like save a thousand dollars on every developer's laptop by moving this off to the cloud. It's really the time savings.

It's the focus. It's the, you know,000 on every developer's laptop by moving this off to the cloud. It's really the time savings. It's the focus. It's removing all of that drift and creating these consistent environments that are more secure and effectively automating your development environment. That's the same for everybody. But I think habits are the big thing. little bit that element of like, we still have this concept of like, I have this environment and I start it and it's there and I pay for it while it's there and I have to clean it up or I have to make sure it's stopped. I think that still exists. And it creates a lot of sort of cognitive overhead of things that I have to manage that I didn't have to manage before. And I think that we have to, Gitpod needs to be better there. And so does everybody else in the industry about removing that completely. Like there's one of the things that I really loved that I learned from

like Stuart Butterfield when I was at Slack was he always brought up this concept called the convenience threshold. And it was just the idea that when a certain threshold of convenience is met, people's behavior suddenly changes. And as we thought about products and like the availability of features, that it really drove how we thought about even how to think about adoption or like what is the threshold?

What would it take? And like a good example of this is even like the way we just use credit cards now or debit cards to pay for things all the time where we used to carry cash. And in the beginning, when it was kind of novel that you could use a credit card to pay for things, like even pay for gas, you always had to have cash because you didn't know if it'd be accepted. And so you still had to have cash. You still had to have it on hand. You still had to get it from the ATM. You still had to worry about like, what if I get there?

They don't accept my cards. And how much money is it going to be? So I need to make sure I have enough of it. But the convenience of having this card where I don't have to carry cash is I don't have to worry about that anymore as long as I have money in my bank account. And it wasn't until those cards were accepted more broadly that I could actually rely on having that card and not having the cash. It's similar when it comes to cloud development environments. It needs to be more convenient than my local development environment. It needs to be. It's kind of like early.

I remember when laptops became more common. I was used to developing on a desktop and people were like, nobody's ever going to develop on a laptop. It's not powerful enough. The battery runs out. I have to, you know, when I close the lid, when you open the lid, it used to take like five minutes before like it would resume and un-hibernate and stuff. And it was amazing where you could just close the lid and open it and get back to where you were.

But that's the case where laptops weren't convenient as desktops were because they were always plugged in, powered on. You could leave them and you could effectively just come back and sit down and pick up where you left off. And so I think that this is another moment where we need to make these cloud development environments more convenient to be able to use and ultimately better. And part of that convenience is to make it so that you don't have to think about all these parts of them, whether they're running, not running, how much they cost, whether you're going to be there with them or lose their data. That should be the value of it. I don't have to think about any of that stuff. So my last question for you is, when you take a look at people who have migrated to using GitMod,

specifically from the corporate perspective, what are their realizations after the fact? Assuming they still take your phone calls, because that's sort of feedback of a different sort. But what have they realized has worked well? What keeps them happy and coming back and taking your calls? Yeah, our customers could focus on their business instead of focusing on all the issues that they have with configuring development environments, everything that go wrong. And so a good example of this is a customer we have, Quizlet. Quizlet

saw a 45-point increase in developer satisfaction and a 60% reduction in incidents. And the time that it takes to onboard new engineers went down to 10 minutes. So we have some customers that we talk to that come to us and say, it takes us 20 days to onboard an engineer because of all the access they need and everything they need to set up and the credentials and things. And now we could boil that down to a button click. And that's the thing that we tend to hear from people is that they just don't have to worry about this anymore. And they tend to be able to focus on their business and what the developers are actually trying to do, which is build their product. And in Quizlet's example, it was really cool to see them mention in one of the recent OpenAI announcements around GPT-4 and plugins is they were one of the early customers that built GPT-4 plugins or chat GPT.

And they mentioned that they were sharing a lot of Gitpod URLs around when we reached out to congratulate them. And the thing that was great about that for us is like they were talking about their business and what they were developing and how they were being successful. And we'd rather see Gitpod and your development environment just sort of disappear into the background. We'd actually like to not hear from customers because it's just working so well from them. So that's what we found is that customers are just able to get to this point where they could just focus on their business and focus on what they're trying to develop and focus on making their customers successful and not have to worry about infrastructure for development. I think that really says it all. On some level, when you have customers who are happy with what's happening and how they're approaching this,

that really is the best marketing story I can think of. Because you can say anything you want about it, but when customers will go out and say, yeah, this has made our lives better, please keep doing what you're doing. It counts for a lot. Yeah, I agree. And that's what we're trying to do. We're not trying to win sort of a tab versus spaces debate here around local or cloud. I actually just want to enable customers to be able to do their work of their business and develop software better. We want to try to provide a method and a platform that's extensible and customizable and

gives them all the power they need to be able to just be ready to code, to get to work as soon as they can. I really want to thank you for being so generous with your time. If people want to learn more, where's the best place for them to find you other than at your conference in San Francisco in a few weeks? Yeah, thank you. I really appreciate the banter back and forth and uh i hope to see you there at our conference you should come consider this an invite for uh june 1st and 2nd uh in san francisco at cde universe of course and we'll put links to this in the show notes thank you so much for being so generous with your time appreciate Appreciate it. Thanks, Corey. That was really fun. Mike Brevoort,

Chief Product Officer at Gitpod. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice,

along with an angry comment detailing exactly why cloud development is not the future, but then lose your content halfway through because your hard drive crashed. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.