Raphaël: Hey friends and welcome
to the Small Tech Podcast.

I'm your host Raph from Éphémère Creative.

And today we are going to be talking
about development environments.

So before I keep going.

I'm going to specify that I do not mean.

Sort of dependency management, package
management tools tied to a specific

programming language or environment,
um, and for the non-technical among you.

Essentially.

Well, we'll, we'll go into
the why uh, I think that'll,

that'll clarify some things.

So why are we talking about,
uh, Development environments

and tools to manage them.

Uh, because.

While a lot of work is
complicated and depends on a lot

of tools and it can get messy.

I have found personally that
development environments are among

the messiest most complicated types
of environments to deal with, um,

at least in sort of knowledge work.

So.

To fix the problems that
come with that messiness.

I think there's, there are a lot of
really useful tools that you can use

to manage development environments.

And I think they're very,
very worth exploring.

Um, so why do we use
these specialized tools?

Essentially you want to have consistency.

Developers often need to install
different types of databases or

libraries and tools and services and
all kinds of stuff, uh, that they need.

To do their work to build
your software product.

And sometimes they'll install a command
line tool and another developer will need

to install that same command line tool.

If they want to do the same
kind of work or get the same.

Software up and running on their
machine so they can collaborate

or they might need to install a
database and they need to make sure

that they're on the same version.

And they might need to install.

I don't know something else.

Maybe they need to run some scripts
before they get up and running.

So you'll write some software
to make sure that your software

is ready to start building.

Um, and all of those things get really
messy if you don't have a nice way.

To get them playing together
correctly, especially when different

developers have different machines.

And as a, as a company, you could start.

Uh, sort of mandating a very specific
machine and, and controlling how

your machines are provisioned.

Um, as a smaller company, that's
kind of hard to deal with.

You might not have an it team that
deals with that sort of thing.

And developers are kind of picky.

They kind of want their
own, their own thing.

Uh, they have their own way of working.

Of course they have to conform to some
extent to your process as a team, but

they're going to have little things that
they, that they like to do differently.

Uh, not in the code, but in how they work.

Um, All of those things.

Basically can get really hard to manage
unless you have tools to make sure that

certain things always happen the same way.

Um, The, so, yeah, consistency.

You want to make sure that everything
happens the same way and the reason

you want to do that a is just because
you don't want people wasting a

lot of time fiddling around with,
well, oh, what version of that

command line tool did you say?

Oh, but like, I actually
upgraded the database.

And so you're going to
need to do that on yours.

Otherwise the new code isn't going
to, like, you don't want to waste

time with that sort of thing.

Um, The other thing that I
find particularly useful about.

Using tools to manage
development environments.

Is onboarding speed.

So if you have a lot of steps
that someone needs to take.

To get a part of your application or
your whole application up and running.

Then, if you can automate all of
that by managing their development

environment, then you can get
them working a lot faster.

There's usually one way or another.

There's always going to be time spent.

For a developer to get up and
running with your project.

Uh, they don't know how your software
is architected and they're going

to need to poke around at that.

And they're going to read
documentation and they're going

to want to read through the code.

And they're going to want
to just mess around with it.

So they get a sense of like
how it works and how it feels.

Um, but you can get them
to that point a lot faster.

If you have scripts and environments
that are consistent and just run.

Uh, before they, yeah.

Before they, even before
they have to do anything.

Um, So, yeah, that's another thing.

Onboarding speed.

Um, the other thing that I found
particularly neat with, uh,

with some of the tools that,
uh, I'm going to talk about.

Is.

You can treat development
environments as ephemeral when

you use these types of tools.

And so you can let your
developers kind of go wild.

And they can break things and they can
completely destroy their environment

as they're experimenting to try and
do something new or interesting.

And it doesn't matter because you
can just turn it all down and turn

it all off and spin up a new one.

And there you go.

You're up and running again.

Um, we'll talk about how that
specifically works, but, uh, yeah.

So the.

So those are the pros.

Those are the reasons I like to
use these types of, uh, tools.

Um, But there are reasons why
you might want to not use them.

Um, One is cost.

So if you have a developer
running something on a machine,

that's kind of a one-time cost.

It depends how you frame it.

But that machine you pay for it.

You run it.

You're good.

And that developer can do things to that
machine and they'll run things on that

machine and it doesn't change your cost.

With some of the tools that
we're going to talk about.

You actually have the cost of a
developer's machine, but you also

have the cost of maintaining those
developer environments because some

of these solutions are cloud-based.

So there's a cost to running the
actual machines on in the, in the,

in the data centers that power
your development environments.

So that's, that's one downside.

The other downside is on some
level of complexity, right?

With simpler projects one way or another.

If you're building an environment
for someone to work in.

Um, the simpler projects won't have
that much additional complexity,

but they might have a bit.

Um, a bit more than if you just
tell the developer here's the

code, just go run it yourself.

Um, And, you know, getting them up and,
and up to speed with, with a new tool is

just an additional layer of complexity
that you wouldn't have normally.

Um, There's also a certain amount
of, I mean, there's this whole field

that has developed over the past.

However, I don't know, decade
that we refer to as dev ops,

which is building tooling.

Uh, some of it purchased tooling.

Some of it is, uh, internal tooling.

To help improve the flow with which,
uh, developers release their, their.

Their work.

Um, And.

There's complexity that comes with that.

When you're building development
environments, you're, you're

customizing those scripts.

You're saying, yep, we're going to
write all of this additional software.

To make sure that when a
developer gets up and running.

They have everything they need.

To work quickly and efficiently, and you
might also be building tools to help them

manage their software and package their
software and release their software.

Um, And that's a lot of overhead.

Depending on the scale of the
project that becomes very useful.

Right?

So if it takes one developer a lot
of time to do those things manually.

Well, you might as well build software
to automate it or to help simplify it.

Uh, there's also with all of that,
I feel like I'm going off on a

tangent, but there's consistency.

Uh, if a developer has to
do everything manually.

And perhaps they have
to tweak the process.

Then that lives in their head and the
other developers don't know about it.

Uh, and so now you've got a problem
where if one developer's not available

and you can't reproduce the work
that they've done to either release

something or get it up and running.

You've got a problem.

So if it's all encoded as software, Um,
Whether it's development environments

or releases or whatever, then you
know that you can always keep going.

You can always keep working, you
can keep releasing your product.

So that's the.

That's why?

Uh, yeah, that's another
reason why it's it's worth it.

For a given complexity level.

Um, In my opinion.

Um, So what are the different
tools that you can use?

We have used.

Two different tools, uh, and
we're aware of two others.

Um, so I have specifically used, uh, and
set us up on, on a tool called Coder,

which I think is absolutely fantastic.

Um, it is, it is really, really good.

Uh, and basically it helps you.

Provision environments you
use, uh, for again, for those

of you who are not technical.

Uh, Docker is a developer tool that allows
you to define what we call containers.

And containers.

Are there not like they're
not virtual machines.

On some level, you can kind of pretend
that they're a little isolated.

Workspaces that feel a little
bit like a virtual machine.

So it's like running
little mini containers.

Uh, many, many machines, many
computers inside your computer,

but it's, it's really not.

Um, but it can feel like that.

And so if you specify what is supposed
to run in one of those containers,

you can say, you know, install this
command line tool, install this

database, this other thing, whatever.

Um, And a Coder lets you specify a
developer's work environment that way.

And so it will run that work environment.

Uh, in a variety of different places.

Uh, I think they're actually
changing their spec as well.

So I'm not sure you have
to define things as, uh, as

containers, uh, as Docker files.

Um,

And because I saw that the latest
version allows you to spin up a virtual

machine on your cloud of choice.

Uh, or you can run it on a Kubernetes
cluster, which is, again, for those

of you who are not super technical is
a technology that allows you to run

workloads across, across machines.

Uh, that's the simplest way of saying it.

Uh, and, and they offer other
deployment targets as well.

Um, so they're kind of interesting
in, in that way and that they're, they

can target different environments.

Um, you can specify what the
developer environment looks like

as a Docker file, but I think there
might be other ways to do it now.

Um,

And yeah, because of their structure,
you can also define the resources

that you want to allocate to a given.

Uh, environment.

So you might be able to say, yep.

Uh, this developer, uh,
environment should use.

I don't know.

Uh, eight VCPU and 32 gigs of Ram.

Whereas this other one only
needs two VCPUs and four gigs

of Ram, something like that.

Um, really neat tool, a good
chunk of it is open source.

And the reason we stopped using it is
because you have to run it yourself.

And there's some overhead there
that, uh, we just didn't feel ready

to take on, especially because.

For a small company, you also
have to run the servers on which

the development environment,
the developer environments run.

And those can be quite costly.

Um, so yeah, it didn't, it
didn't make sense for us.

Um, especially when there was a tool
like the next one called GitPod uh,

which they have a hosted version
where they run the infrastructure.

You just pay them to use it.

Uh, and so they can distribute
the cost among their users.

And that makes it cheaper to run and
you don't have to run the infrastructure

yourself, which also, uh, is a benefit.

If you are a tiny company and you
don't have the bandwidth to be

running yet, another set of servers.

So that's yeah, that's uhh that's
what's nice about GitPod Other than

that they function very similarly.

You define your development
environments as.

As Docker files and
they run as containers.

Um, They do not have the other
advantages that Coder has, where

it can spin up virtual machines.

And, uh, yeah.

That means that you're also, you're
kind of stuck with, uh, well, yeah,

you're stuck with their infrastructure.

And they only define
two sizes of machines.

I believe that's a four.

Hm.

I might have this wrong,
so don't quote me on it.

I think it's for vCPUs and.

Uh, like.

Eight gigs of Ram or two VCPUs
and eight gigs of Ram and

four vCPUs and 16 gigs of Ram.

Something like that.

Uh, so they're not huge, huge development
environments develop, uh, yeah.

Development environments.

Uh, so if you do have something very
heavy that you want to run and build

a, you might want to look elsewhere.

If not, it's a very, very easy
way to get started building in

the cloud and having consistent
environments among your developers.

And the other one that
I have not tried yet.

Is, uh, is, uh, Docker's dev environments.

So Docker.

Uh, I mentioned earlier, the Docker is
used by coder and GitPod to define what

the development environments run as.

Right.

So they manage the infrastructure
to get that up and running.

And how you spend those up and how
you manage resources among developers.

But the environment itself
is defined as a Docker file.

So you can spin up these Docker based or
Docker file defined environments across.

Uh, across machines with
coder or GitPod recently?

Well, relatively recently, I think in
the past year, Uh, Docker has started to

build out its own way of doing that, but
it happens on the developers machine.

So you define the environment
with a Docker file, but the

developer runs it on their machine.

Now there are some benefits to this and
that you do not have any additional costs.

But there are some disadvantages
too, in that there's still

some complexity to manage.

If you have developers with
different types of machines.

Um, with the cloud environments, you can
guarantee a certain level of consistency.

Uh, across the machines that the
developers are actually running

their, their environments on.

Um, if you're telling them to run it
locally on their own hardware, then

you are stuck with whatever hardware
they've got, unless you have the

resources to provision that hardware
and make sure that it is all consistent.

Um, so yeah, that's a, that's another one
to think about, uh, No, I haven't used it

yet, so I don't know how well it works.

I assume well, Uh,

and finally the last one is, uh, Nix.

Nix is not something I have.

Uh, tried at all.

And it's not something I know
well, but I've heard a couple

people talk about it recently.

My understanding of it is it is
actually more of a package manager.

Than a development environment.

Like a tool to manage development
environments, but they also

offer their own operating system.

Um, and I think in tandem
being able to run their own Os

with their package manager and
their tooling to manage Docker.

Uh, containers.

Uh, I think they functionally give
you something very, very similar.

Um, yeah.

I still feel a little
bit confused about Nix

uh, but I figured I'd throw it in
there in case any of you listeners

are interested in this stuff
and are looking to explore it.

Um, I would love to hear what you all
use because making sure like running

into that problem of, well, it runs on
my machine, but it doesn't run on mine.

Um, is such a pain and it's so
annoying and it can cause so many

problems and slow, so many things down.

Uh, so I would love to hear
what you all are using.

Uh, have you tried coder or get pod?

Uh, what about Docker
dev environments or Nix.

Uh, maybe there's other ones.

I know there's code anywhere,
but they're more limited.

Uh, Replit and others.

Uh, I feel my instinct is
they're more like toys.

They're less, they feel less
like places to work as a team.

Uh, but maybe not.

Uh, oh, I will add one last thing about
GitPod one thing that I quite like about

them is that they treat their development
environments as ephemeral so they, you are

encouraged through their user experience.

To treat them as things
that you just toss out.

So you get some work done on a feature
and then you get rid of the environment.

Uh, and the idea is you should be able
to just provision environments, quickly

work on some stuff, throw it out.

And in a sense that kind of forces
you to make sure that the tooling is

ready for the next environment to be
provisioned nicely, which means it should

work for every developer on the team.

But yeah, let me know what you all use.

I would love to hear more and, uh, yeah
. If you want to hear more about this

stuff, make sure to subscribe and we all
want to do something good in the world.

So go out there and build something.

Good friends.

See ya.