Subscribe
Share
Share
Embed
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Chris Weichel: Really, the benefit comes from being able to standardize these things and then build on top. And editors, IDEs that you integrate with are just one way to build on top.
Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Gitpod, who have also brought their CTO and Co-Founder, Chris Weichel. Chris, thank you for joining me.
Chris Weichel: Great to be here.
Sponsor: This episode is brought to you by Gitpod. Do you ever feel like you spend more time fighting your dev environment than actually coding?
Works on my machine issues are too familiar and the VDI setup in your organization drives you mad. Gitpod brings automated, standardized development environments to your laptop and the cloud. Describe your dev environment as code and streamline development workflows with automations. The click of a button, you get a perfectly configured environment, and you can automate tasks and services like seeding your database, provisioning infrastructure, running security or scanning tools, or any other development workflows.
You can self host Gitpod in your cloud account for free in under three minutes. Or run Gitpod Desktop locally on your computer. Gitpod's automated, standardized development environments are the fastest and most secure way to develop software. They're trusted by over one and a half million developers, including some of the largest financial institutions in the world.
Visit Gitpod. io and try it for free with your whole team. And also, let me know what you think about it. I've honestly been looking for this for a while and it's been on my list of things to try. I'll be trying it this week. Please reach out. Let me know what you think.
Corey Quinn: I have been a staunch advocate of the idea of remote development in some key ways for a long time.
I was one of those lunatics where when I was traveling a lot, my only computer that I brought with me was an iPad. So, great, how do I wind up working on things in the modern era? Because Vim in an EC2 box worked for a long time, but it turns out that it's getting harder and harder to just tab complete with various AI assistants in there.
You can get GitHub Copilot to work with VI, but it's not a pleasant process. So, what is Gitpod in the modern era?
Chris Weichel: So, Gitpod is really a platform for automating and standardizing development environments. And that includes, if you want to standardize on VI, hey, knock yourself out, you can absolutely do that.
You can also use more widely adopted editors, VS Code, JetBrains being the obvious example. So, really fundamentally, we've gone through a sort of series of transitions and remote development was sort of a precursor to where we're at now, I think. Remote development, really the idea of shifting this off the machine, shifting this off of the computer is one step.
And then we really found that the fact that it is a different box that I now need to maintain isn't all that helpful. Just the fact that it runs somewhere else, great. You get more bandwidth, like that Amazon data center sure has more bandwidth than my mobile connection does. But the real pain is needing to maintain all this stuff.
So we've taken that step beyond remote development.
Corey Quinn: It's one of the constant challenges of do we do development locally or do we do it remotely? And it used to be that people would always complain about like, well, okay, what if I want to do development and I don't have an internet connection? Which always seemed a little on the meh side of the fence until recently where it's, okay, let's do the actual numbers.
How many hours a year are you in front of your computer with no internet connection? And is that really a common enough use case to be worth standardizing your workflows around? And the answer is almost always no. One of my snarky observations has been that remote development is absolutely the right way to go and local development is not, except when I'm trying to convince my boss to get me the upgraded new laptop, in which case it's the only way to fly. It feels like people tend to go back and forth on that particular side of the fence. From where I'm seeing, where I'm sitting, it seems like you are unapologetically on the side of remote development is the way to go. And I can make a good faith argument in favor of, and against that mindset. I think it really comes down to individual contexts.
Chris Weichel: Like one could argue that, you know, in this day and age, how many engineers are truly productive without copilot running on the side, or like, you know, being able to go to Stack Overflow if you're so inclined. Frankly, we're not really working without internet connection, at least not very productively anymore these days.
But I think this whole, like, remote local thing is, like, it's an important conversation, something that a lot of folks focus on. But it's also somewhat, like, it's not the most important. I think that the really key thing is not where does my stuff run, but how much do I need to invest and keep investing to keep it running?
Right? Like what's the cost and effort to get my development environment set up and keep it set up? I think that's the, that's a really interesting question. Less so is that development environment sitting on an EC2 box or my $4,000 MacBook.
Corey Quinn: One thing that I found as well, that, that has sort of gotten me to the same place is that.
At home, I use MacStudio. I've had it for a few years. It's a pandemic era thing. I'm using it now. It's great. In the work office downtown, I take my laptop with me and use that. And part of the value of that workflow that I've gotten to is everything that I use on a consistent, ongoing basis has got to be available in both places.
This has forced a lot of really good data hygiene and being able to work in a way that is consistent between those environments. To the point where now it's a question of what do I grab for any, you know, non podcast recording task, it's just a question of what am I closer to, and I can get it done with equal ease there.
That, I think, is sort of one of the great outcomes of having a cloud developer environment. Your office can burn to the ground in a suspicious act of what they're not going to call arson, but the closest thing to it. And your data winds up being relatively intact and ready to go since, I don't know, some ridiculously short period of time.
That I think is sort of the goal. It makes everything easier from backups to ransomware detection and data protection from that perspective to at some level ensuring that what you're working on is in some ways like within the boundary that folks care about. This does feel frankly like a like a problem that is cared about a lot more by a specific class of customer.
Be it the large enterprises and or the folks that are subject to various compliance regimes. Uh, who is your target customer for something like this? Because what I think of as an independent developer who's fairly bad at it, who's only programming languages are brute force and enthusiasm and "in the off hours," I feel like standardization is not the first thing that I'm going for.
When you're dealing with giant enterprise, it feels like that's the number one concern that they have. And somewhere in between those two is probably a sweet spot.
Chris Weichel: Yeah. So 100 percent large enterprises, specifically regulated industries, really are the first that come to us sort of from a top down perspective.
That said, the benefits of standardized and automated development environments really exist across the spectrum. Like, even as an individual engineer. Heck, I don't even have Go installed on my MacBook anymore. And that's, you know, like, I got some little tiny Go stuff happening on the side, and I don't have that installed on my MacBook either.
And the reason I don't have to is because I can use environments that, you know, are described in code that I can instantiate. It's, you know, essentially a Dockerfile. That I can instantiate and when I'm done with them, I throw them away. And when I break one, I can get a new one at the click of a button.
And that's fantastic. I can even have three of those at the same time and try different ideas and like, you know, keep one around. It just really changes the way you work as an engineer. So even at that individual level, it's, it's fundamentally different to having this one precious thing that you need to take great care of, and God forbid you install the wrong version of Anaconda, and your day is gone.
Corey Quinn: Oh my God, you may have just captured the entire, the entirety of one of the biggest challenges I have in the development space, which is, What is it? "Good artists borrow, great artists steal," is the famous Jobs quote. I tend to wind up grabbing all kinds of various nonsense of sketchy provenance off of GitHub.
And that means that I need to be able to run basically every version of every language, because you never know what the next one is going to hit. And It's taken me a while to get to a point of being able to do those various languages in certain virtual environment style and containers, where it's, okay, if I destroy the system environment for this version of Ruby, can I still use my computer after the fact?
So the idea of being able to have these various forms of environment that is, that are self containing the blast radius of some terrible development practices, usually on my part. Great. That is a win right there.
Chris Weichel: Absolutely. And then, you know, you, you run, as you put it well, like sketchy, provident, like this random thing I found on GitHub, and I'm going to run this on the same machine, You know, npm install is essentially remote arbitrary code execution that I voluntarily run.
And I do that on the same machine that has access to my email, that has my 1Password installed, that, you know, has access to, like, heck, it has a Git credential helper that can access all my repos. I don't know what's going to happen. And so there's also that element of it. If I want to try some random thing and I want to make, I want to limit the blast radius, I want to make sure that it can do less damage.
It's really great if this happens in its own security boundary. And quite frankly, none of this is really new, right? Like, this idea has been around in various iterations for, various versions for a while. Like, anyone remember Vagrant? And then Docker? Like, all this idea of, like, trying to put your development environment in a box of sorts.
That you can replicate in and of itself is a no.
Corey Quinn: It's one of those problems where I keep smacking into various incarnations of the same thing again. I mean, I've been using the ASDF version manager for a while for various languages just to be able to use the different things in the different places where I need it.
But it's been incredibly frustrating.
I want to call out that apparently I've been operating for a little while now under a misconception. I was under the impression that Gitpod was effectively a hosted VS Code equivalent running in some sort of VM. Very similar to a Codespaces equivalent. But that's not what it seems to be.
Not the way that you describe it as a platform. It's not, oh, it's a developer tool that provides you your IDE, the end, full stop. Is that where you came from? Or am I just remembering this and conflating it with something else?
Chris Weichel: Yeah, that's absolutely where it came from. Like that's, that's how we more years when I didn't have gray hair yet, go like, when we started with this, like this is, is really where we came from.
And what we then found is that really the thing isn't so much about where does my editor run? In fact, you want your editor, your IDE as close to you as you can, right? You want that on your machine. That doesn't mean the compute has to happen there. And really the benefit is coming from the fact that you can, you can automate this, that you can replicate it, that these individual environments are isolated. So if I get something terribly wrong, and I accidentally delete root in one environment, I don't break everything else. So these are really the benefits and not so much the, the where, like just getting VS code in the web, getting VS code in the web, very helpful. If you happen to, you know, want to do that on an, on an iPad back in the, especially back in the day, that was about the only way you had other than SSH and VI or Emacs, if you have 12 fingers.
Corey Quinn: That's what the foot pedals are for, for holding down the control and the meta keys.
Chris Weichel: Ah, that's what they, yeah, there we go. So, the, really the benefit comes from being able to standardize these things and then build on top. And editors, IDEs that you integrate with are just one way to build on top.
Corey Quinn: The idea of being able to deploy this is a, is a handy thing.
I mean, AWS's own WorkSpaces product, their virtual desktop, was effectively, I want to say extended slash borderline replaced by the WorkSpaces core. Which they've been talking about for a while. The idea being it's less about here is your actual environment, and here is how you manage all of those environments that you're passing out to people willy nilly.
It seems like this is a fairly traditional progression of going from, "we built this thing that provides you an environment that you can do your work in remotely," to, "here's how you manage all those things that you have, that we built, that you've been using, and now you have a library problem."
Chris Weichel: Yeah, that progression is definitely there.
And I think we've seen that in other also more VDI leaning places, a bunch of times. Quite frankly, I think we're going to end up in a similar place. I can say, well, and we are already seeing that, you know, like we have that platform that lets you put like issue development environments to, to engineers.
And then the obvious, obvious next question, especially for larger organizations is. All right. Now, how can I control that? How can I enforce that? Like, you know, everyone uses the same version of Java after some larger CVE happened. No recent time in history comes to mind, but how do I make sure that everyone uses the correct version or whatever control that we need from a compliance perspective?
Obvious next questions. Platforms like Gitpod. are a great way to make that happen. Especially then balancing this with developer preferences is an interesting challenge.
Corey Quinn: When you start talking about consistency between environments, and especially in regulated environments, which I get, but a lot of folks work in industries that for better or worse are not regulated, whether they should be, is a separate topic for a different podcast.
But the, as a result then, there's this question of every time I've had something forced upon me as a developer, I've resented it, because it seems that even when I've run engineering teams in the past, not well, mind you, I felt like the rule one was basically get out of the way of whatever developers want.
If they, if they want to buy jetBrains or something else like that, great. You do it. They want to, for some reason, develop on Windows. Awesome. Superb. They're going to wind up using a text to speech engine that only registers clicks and pops. Okay, fine. We're gonna figure out a way to do it. But, so it's basically, we'll move heaven and earth just to make people productive in the way that they want, and it seems like the idea of standardizing a development environment is almost one of the last things you'd want to do from that perspective.
Clearly you have a functioning, viable company. So I'm the one who's wrong at this and at certain points of scale, what am I missing?
Chris Weichel: Yeah, this, this is so interesting. Like, I think as an industry, we're going through pendulations here. At some point it was all like free for all. Everyone goes, you know, go do what you want.
You want to build the next platform and brainf*** server pages. Go knock yourself out, right? Really extreme ends, and then we went to the other side where, like, you get this one toolset, BDI is locked down to the max, that's the only thing you get, good luck. And life there sucks. And then we, you know, we pendulate back.
The thing that's happening, I think, is we're sort of oscillating around an optimum here, and we're, you know, this is another, iteration towards the optimum. And what I mean with that is there is a sweet spot on some things that you want to agree on as a team. You know, it doesn't make sense if the team itself can't even agree on the version of Go or Java or Node they want to use.
Like there is some standardization that needs to happen at some scope. Whether that's organization wide, business unit wide, team wide, that's a matter of the organization, and it's not on us to answer that. But there is some standardization that naturally happens. You need to get work done. You know, you're all going to use Linaro, Jiro, whatever. Like, you standardize on tools. And then there is personal preference. You don't necessarily have to enforce if you use bash or fish or set as H or whatever the case may be. So there is a case for standardization, and the thing that we're trying to get right is walking this metal line.
What we're trying to get right is how we can enable organizations. How we can embrace this sort of organizational standardization that naturally ,happens or sometimes by force, and combine that with the individual preference of engineers so that they still have the freedom of movement, you know, to make it their own and then be productive.
Corey Quinn: I guess to put it slightly more bluntly is the question, the way that I've often heard this discussed by human beings, generally when, you know, someone who they have to be professional in front of is not in the room is, okay. If the company's making me use it, how good could it possibly be? There's a sense that whenever something becomes enterprising, it becomes terrible.
My wife works for a giant company, and her laptop sounds like a battle tank just drove into the living room whenever she fires it up to check her email. You know, it sounds like it's mining cryptocurrency, but no, that's just the VPN or possibly Outlook. Great. That's just how it works. And the thing's a piece of crap.
There's no way around that. Everything that I've ever been forced to use by large companies tends to follow suit. It's almost the, I don't want to sound overly oppositional, but there's an idea of if you have to force me to use it, it can't possibly be good. Which I think is an un-nuanced take on it, but I'm sure people are thinking about it.
Chris Weichel: I'm sure, like, everyone who's worked at a reasonably large enough organization will have experienced their share of software they were forced to use that isn't great. Like, I remember working at a really, really large automotive supplier where at 12 o'clock, I simply couldn't use my laptop for an hour because the antivirus needed to do its thing.
These things exist, no doubt. The thing is, with developer tooling, with tooling like Gitpod, there is no way we're gonna be successful, we're gonna, this is gonna work unless we find adoption, unless we find developer love. We are fundamentally a company that, like, this is, my co-founders and I, like, the way we founded this is as a developer-first organization, and this is really what we deeply care about, is the experience you're going to have with this product.
And we strongly believe we will not be successful unless we make engineers happy. And the way this shows is there is this initial hump you got to get over, like this jumping over your own shadow. There's something new. And as engineers, we're so often ingrained in our ways. Once you jump over that and realize all these new options that you now have, you're not going back. It's that simple. And the reason you're not going back is not because there is someone standing behind you telling you, you have to use this. The reason you're not going back. And I promise you that is because you simply don't want it. Once you've seen the light, there is no going back.
And I can, you know, obviously I'm a bit biased. Obviously I have a vested interest in saying all this. The great thing is you can try it, you know, like you don't have to take my word. You can try this thing today. Again, I don't even have anything installed on my, on my machine and I really enjoy writing code.
Sponsor: This episode is brought to you by Gitpod.
Ever feel like you spend more time fighting your dev environment than actually coding? “Works on my machine issues” are too familiar and the VDI setup in your organization drives you mad?
Gitpod brings automated, standardized development environments to your laptop—and the cloud.
Describe your dev-environment-as-code and streamline development workflows with Automations. At the click of a button, you get a perfectly configured environment and you can automate tasks and services like seeding your database, provisioning infrastructure, running security or scanning tools or any other development workflows.
You can self-host Gitpod in your cloud account for free in under three minutes or run Gitpod Desktop locally on your computer.
Gitpods automated, standardized development environments are the fastest and most secure way to develop software.
Gitpod is trusted by over 1.5 million developers including some of the largest financial institutions in the world. Visit gitpod.io and try it for free with your whole team.
And also, let me know what you think about it. I've honestly been looking for this for a while, and it's been on my list of things to try. I'll be trying it this week. Please, reach out, let me know what you think.
Corey Quinn: There's also the question as well of, some of these approaches feel like they work better for certain types of development.
If I'm just writing something that is self contained in its own repository, great, but there are also times when I'm trying to do local development against something that is not traditionally local. My dearly beloved local stack is a great example of this, but that often means that you need to be running an entire Docker series in conjunction with what you're already doing.
How do you wind up deploying something like that at large scale?
Chris Weichel: There are really two broad categories. I want to say that, that this falls into one is. What you could call inside the box and what you could, the other is what you could call outside the box. Inside the box really is pretty much the way you would be thinking about a, any sized machine.
And then, you know, it becomes a matter of size and at the end of the day, dollars you're paying to any of the big hub providers. And then you can run whatever you need to run in there. You know, you need to run a Kubernetes cluster, please do. You need to run local stack and Docker, please do. All these things definitely possible.
Again, the moment you like, imagine needing to set up a Kubernetes cluster, even if it's just something like K3S. Deploy a bunch of manifests to that, just so you can make a single change. Clearly you wouldn't, right? Like you'd keep this around for a long time, and then automation would rot. This benefits from being exercised regularly, so there's one thing you can do, you can put this in a box, you can automate the recipe for creating that box, and then you can get multiple of them.
The other way is you can do this outside of the box. You can put that machine, this box, somewhere close to existing infrastructure, and then connect to it in a more or less traditional way. It's like one tool that I'm a big fan of is Telepresence, for example, because it really makes that, makes it easy to replace an individual service or deployment in a Kubernetes cluster.
And that's really helpful. You still have this problem of, all right, now I need, you know, Java or Go, whatever it is in the right version. I need the Docker daemon. I need all the scripts. I need everything set up. So the setup problem doesn't go away. It is just reduced in scope. But I think these are the two broad categories is either it fits in a box and they put it in there or it doesn't.
And then you put the box close to the remaining infrastructure.
Corey Quinn: No, it seems to be an appropriate way of structuring things. It's, again, this is one of those areas where the question is sincere. It's not one of those, wait, you mean you need to use third party dependencies? Oh no, well maybe our product is not going to work out for you.
Yeah, you've probably seen that issue before.
I am curious as well though, you've have people like to use words and often it's impossible to understand what those words mean in the context of how other people are using them. For example, I used to think I know what the word "flex" means, but now if I look at your blog at the top, but you're highlighting the launch of Gitpod Flex.
Uh, what is that exactly?
Chris Weichel: So we have been around for quite a while. I mentioned grey hair earlier. So we've been around for a while. And the offering that you can get today is fantastic. So it's really battle hardened. We've been at it for a while. Over the years though, you know, you collect ideas, you collect thoughts and things that you wish you could do in the current architecture.
And many of us have been there, at some point comes the point in time where we go, "Huh, what if we could start over again?" And that's fundamentally what Flex is. It's us taking all these learnings over the years and going back to the drawing board and thinking, "all right, if we could start again today, how would this look like? What would we be building? How can we make this simpler?" is a good element of it. "How can we make it more flexible?" Hence the name. So this is where the name comes from, and fundamentally, there are many differences between Flex and our existing offering, but, or the previous offering.
One of which is that, that Flex is a lot more flexible in where your workspaces run, right? So you can take the thing that executes your or runs your workspace. We call them runners for obvious reasons. You can take those runners and put them very close to existing infrastructure that you want to be close to. Your own AWS account, for example, that, you know, in your own private VPC, or in your own VPC that, you know, hosts your RDS or whatever else.
Corey Quinn: It's a nice structure of effectively, like, I like the idea of being able to reimagine this, because so many folks, when you talk about how they've built what they've done, and you go into, "alright, tell me about your architecture and your infrastructure," and you're having this in a conversation context that is not, you know, on a conference stage, where everyone has to be unrelentingly positive.
Everyone tells you versions of the same story, which is we made this mistake and that mistake, and the infrastructure database is a burning tire fire of sadness and regret, and if I could do this again, I would. You actually lived out that fantasy and turned it into a completely separate product. How hard was that to get advanced politically, internally?
I mean, you are the Co-Founder and the CTO. So, you know, I suppose you just like wave your paw and do this via fiat, but for us mere mortals, we have to get buy in for such things.
Chris Weichel: Funny enough, I was the one who had to be convinced. Every engineer, you ask them, what would you do differently? They would, they'll come up with a list, right?
I'm no different. The thing at the end of the day, though, is unless this offers tangible value, unless this actually benefits our users, our customers, and us the business, why do it? So that's where that comes from. The thing that, that convinced me in the end is that I do believe we are creating fundamentally better version of the same product.
So I want to highlight that. The value prop is the same. It's the same idea. I think we're just executing on it much better now, and I also like to your point, like, this is how you, I think, convince people. You got to show what's the value of doing this. Like, just going from, "I need to change the language," probably isn't going to cut it.
There needs to be more to it. In this case, just to make that very concrete, architecturally, one of the big mistakes we made is we have two fundamental components. We have the management plane, and we have where your workspaces run, what we now call runners, right? And historically the management plane would connect to the piece that runs your workspaces.
Now this is reversed and it sounds like a really benign change, but it's fundamental. Because so many places, you simply cannot deploy something that needs to be connected to. What? You want ingress into my network? Not happening. Just reversing that has unlocked so much.
Corey Quinn: There's a lot to be said for the idea of being able to live out that fantasy, but the problem, as you say, is finding the bandwidth to do it. And I have a sneaking suspicion I know where all of that bandwidth came from. Because also on your blog, somewhat recently, you wound up posting about leaving Kubernetes, which is awesome. I feel like great. Now that you're not running Kubernetes all the time, what are we going to do with all the extra hours in the day?
Let's rewrite the core business.
Chris Weichel: It's deliberately in like present continuous. We are leaving, not we have left. So we're still in the process. But indeed, this is a big element of it is the simplification that has come with this, right? Like the, where we found the bandwidth is, first of all, engineering us to a place of better stability on our existing offering, but then also taking a small and very effective team and trying this really. Like, taking the first step, seeing where we go.
Is there enough there to do it? So what we didn't do is we didn't set out and go, all right, we're gonna, you know, table flip, start over. That's not at all what we did. We started with a small team. We really iterated our way forward. One of our company values is climb the next hill. It's like trying to find the next hill, see what, how the landscape looks like there, and that's what we did perpetually.
And with that also unlocked ever bigger investments into this.
Corey Quinn: It's neat to see. I mean, I know, I saw it on Hacker News a few weeks before this recording, where, a week or so ago, and it was a, it definitely caused a lot of kerfuffle. A part of that may very well have been the somewhat clickbaity nature of the subject line, but it was a well nuanced article.
And discussing the why behind it and the benefits you got from it are just freaking terrific. I love the idea that you can make a strong business case that stands up to scrutiny, and I think that that's something that a lot of engineers have lacked over the previous few years. It's a human nature problem because the technology is easy compared to the people
Chris Weichel: That's very right.
Like, you know, technology is something that, that we all know, but at the end of the day, it needs to serve a purpose. The Kubernetes blog post, I really love how this went, because we wrote this, and it was almost cathartic. Like we, we went through this, and like all these years of really trying to make it work are in that blog post.
Like this is, I can easily say this, this is five years of my life that's in this blog post. And I think this is what, like what I found so great to see is the very first comment on Hacker News was, "Hey folks, I know the title is clickbait. This is a really nuanced article. Let's keep the civil and talk about the points in the article and not go like, 'how dare you attack Kubernetes?'"
The thing I identify with so strongly, you know?
Corey Quinn: Yep.
Chris Weichel: It was a really great conversation, really nuanced conversation of people coming from different perspectives and going like, "Hey, this would never work in our organization. Here's why." Or like, "Hey, it's great. We can talk like this for this use case. I totally see where you're coming from. This makes sense." And so it was a really, really civil, really fruitful conversation. It was wonderful to see that.
Corey Quinn: It was one of those rare moments where the terrible orange website can actually come together and deliver reasonable value. I think it's the reason I keep going back to it other than the, like, you know, sure.
Nine times out of 10, it's horrible. But that 10th time, it just really gets it in a nuanced exploration of things. I wish the ratio were better, but that's the people.
Chris Weichel: That is so.
Corey Quinn: I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?
Chris Weichel: So the first place to go to is gitpod.io. It gives you great detail on all the things that we spoke about. It links to our blog posts, which really are written by our engineers.
A lot of like, it's not fluff. We pride ourselves in the depth of our content. And you can also try this. The upper right corner is a login button, well worth your time. Other than that, you can find me on X, on LinkedIn, my DMs are open.
Corey Quinn: And we will, of course, put a link to all of that in the show notes.
Thank you so much for taking the time to speak with me. I deeply appreciate it.
Chris Weichel: Thank you so much for having me.
Corey Quinn: Chris Weichel, the Co-Founder and CTO of 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, insulting comment that doesn't quite seem to post properly because your environment has been trashed to the point where you can't even submit comments because there's no consistency to what you've done to your computer.