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.
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.
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 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?
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 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.
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.
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.
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.
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.
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.
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?
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.
That's what the foot pedals are for, for
holding down the control and the meta keys.
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.
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."
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.
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?
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.
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.
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.
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.
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, 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.
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?
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.
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.
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.
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, 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.
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
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?
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, 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.
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 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.
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 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.