Screaming in the Cloud - Standardizing Developer Freedom with Chris Weichel

Episode Date: November 19, 2024

Whether remote or local, Gitpod Co-Founder and CTO Chris Weichel thinks there’s a clear benefit to standardizing automated development environments. On this episode of Screaming in the Cloud, Chris joins Corey to chat about the inception and progression of Gitpod, highlighting the company’s mission to streamline development workflows, improve security, and enhance developer productivity. They also discuss the hurdles and solutions that come with balancing organizational standardization with individual developer preferences. You’ll also get the inside scoop on why Gitpod is transitioning away from Kubernetes and the innovative aspects of Gitpod Flex!Show Highlights(0:00) Introduction(0:27) Gitpod sponsor read(1:39) What is Gitpod in the modern era?(3:07) The debate of local vs. remote development(4:57) Explaining Gitpod's target customers(9:36) Clarifying Corey's misconceptions about Gitpod(12:42) Building between developer environments(15:23) Is something inherently bad if your employer forces you to use it (17:49) Gitpod sponsor read(19:01) Deploying local development tools at large scale(21:16) Launching Gitpod Flex(22:54) Creating a separate product based on feedback(24:58) Gitpod's decision to leave Kubernetes(28:16) Where you can find more from Chris and GitpodAbout Chris WeichelChris Weichel is the Chief Technology Officer at Gitpod, where he leads the engineering team that builds and maintains the cloud-native platform for software development. With over 20 years of experience in software engineering and human-computer interaction, he has a comprehensive view of the systems Gitpod creates, from the user experience to the underlying technology.Chris is passionate about creating technology that empowers users, and solving complex engineering problems. His expertise in cloud-native architecture, programming, and digital fabrication has resulted in multiple publications, patents, and awards. Chris is always looking for new opportunities to apply my broad skill-set and excitement for creating technology in a commercial or research context.LinksChris’s LinkedIn: https://www.linkedin.com/in/christian-weichel-740b4224/Chris’s Twitter: https://twitter.com/csweichelGitpod: https://www.gitpod.io/Why Gitpod is leaving Kubernetes: https://www.gitpod.io/blog/we-are-leaving-kubernetesSponsorGitpod: https://www.gitpod.io/

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, build on top. 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 Wachl. Chris, thank you for joining me. Great to be here. 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. I have been a strong

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? 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. 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, well, okay, what if I want to do development and I don't have an internet connection? Which always seemed a

little on the 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 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. Totally. 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 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 a really interesting question. Less so, is that development environment sitting on an EC2 box or my full-grand MacBook? One thing that I found as well that has sort of gotten me to the same place is that at home, I use a Mac Studio. 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 non-podcast recording task? It's 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 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 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. Who is your target customer for something like this? Because when I think of it as an independent developer who's fairly bad at it, who's only programming languages are brute force

and enthusiasm 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. Yeah. So 100% 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 ghost 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 Docker file 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 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. Oh, my God. You may have just captured 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 are self-containing the blast radius of some terrible development practices, usually on my part. Great. That is a win right there. Absolutely. And then, you know, you run, as you put it well, like sketchy, provenant, 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 one password installed, that 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 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 or 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 and in itself is a new 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 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? Yeah, that's absolutely where it came from. That's how we, more years when I didn't have gray hair yet ago, when we started with this, this 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 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, like just getting VS Code in the web, getting VS Code in one environment, I don't break everything else. So these are really the benefits and not so much 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 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. That's what the foot pedals are for,

for holding down the control and the meta keys. Ah, that's what they were. There we go. So the, 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, build on top. The idea of being able to deploy this 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 workspace's 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 we built that you've been using and now you have a library problem. 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. And we are already seeing that. We have that platform that lets you issue development environments to engineers. And then the obvious next question, especially for larger organizations, is all right, now how can I control it? How can I enforce that 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. Right. 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 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 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 going to 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? Yeah, 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 bring several pages, go knock yourself out, right? We did Extreme Ends, and then we went to the other side where like you get this one tool set,

BDIs 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, 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 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 Linear or Jira or whatever. Like you standardize on tools. And then there is personal preference. You don't necessarily have to enforce if you use Bash or Phish 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 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. 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, there's a sense that whenever something becomes enterprise-y, 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, 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. I'm sure. 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. 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 going to be successful.

This is going to work unless we find adoption, unless we find developer love. We are fundamentally a company that... My co-founders and I, 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, 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 to. 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 machine and I really enjoy writing code. 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. 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?

There are really two broad categories I want to say that this falls into. One is what you could call inside the box and the other is what you could call outside the box. Inside the box really is pretty much the way you would be thinking about 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 pub providers. And then you can run whatever you need to run in there. You need to run a Kubernetes cluster? Please do. You need to run

local stack and Docker? Please do. All these things are definitely possible. Again, the moment you 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 more or less traditional ways. Like one tool that I'm a big fan of is telepresence, for example, because it really makes it easy to replace an individual service or deployment in a Kubernetes cluster. That's really helpful. So you still have this problem of, all right, now I need 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. Either it fits in a box and they put it in there, or it doesn't, and then they put the box close to the remaining infrastructure. No, it seems to be an appropriate way of structuring things. 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. 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, you're highlighting the launch of Gitpod Flex. What is that exactly? So we have been around for quite a while. I mentioned Greyhair 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 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,

or previously, the previous offering. One of which is that Flex is a lot more flexible in where your workspace is 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. 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, all right, 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 or 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 I suppose you just like wave your paw and do this via fiat. But for mere mortals, we have to get buy-in for such things. 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 convinced me in the end is that I do believe we are creating a 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, 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 run-os. 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. 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. 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 way 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 first steps, 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 going to 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 how the landscape looks like there.

And that's what we did perpetually. And with that, also unlocked ever bigger investments into this. It's neat to see. I mean, I saw it on Hacker News a few weeks before this recording, or a week or so ago. And it definitely caused a lot of kerfuffle. A part of that may very well have been the somewhat click-baity 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. The technology is easy compared to the people. That's very right. Like, you know, technology is something 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 catathic. We went through this and all these years of really trying to make it work are in that

blog post. I can easily say this. This is five years of my life that's in this blog post. And I think this is what I found so great to see is the very first comment on Hacker News was, hey, folks, I know the title is tickbait. This is a really nuanced article. Let's keep this 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? Yep.

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. 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, 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.

That is so. 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? So the first place to go to is gifpo.io. You know, 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. 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.

Thank you so much for having me. Chris Feichel, 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. 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.