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.