Introduction
At first, it works okay when you set your dev environment up and running. You might only need to run react dev server and next dev server. However, you'll see that things become slower when you run storybook dev server. What's worse, more components are added. Plus, you want to run unit/integration/e2e tests locally before making a pull request. Some developers might have a brand-new performant machine to handle all of them. Unfortunately, it wasn't me. To solve this issue, I looked into how to speed up my development environment.
Buying a new local machine
Most individuals choose this option. Students switch to a brand-new performant Macbook. I've seen a bunch of companies giving a laptop too. However, the budget got in the way. So next.
Using GitHub codespaces
Pricing and plans of GitHub codespaces
I needed at least 4 cores and 16 gigabytes of RAM. If you spend 130 hours using GitHub codespaces, you pay $36 per month. If you keep using this for 3 years, that sums up to $1,296. It was clear I would end up paying the same amount as a brand-new laptop. Rather than relying on a service, I decided to look into cloud service providers directly.
Using a cloud service provider
Let's move onto VM(virtual machine) instance pricing provided by a cloud service provider, AWS.
On-demand ec2 instance pricing on July 8th, 2024
An on-demand 4-core 16GB RAM instance costs $0.2 per hour. Compared to GitHub codespaces it's cheaper. However, I didn't feel like it was still affordable. Meanwhile, I found out there was a thing called spot instance
during research. Simply put, this type of vm instance is about 75% cheaper, and when the ec2 computing engine in the region gets busy, it stops for a while and restarts.
On-demand spot instance pricing on July 8th, 2024
$0.2 per hour goes down to ~$0.05 now. Using it for 100 hours costs $5. Now the price is affordable, indeed. I decided to go with that.
Now, a question caught me: How can I set up a spot instance for remote development? I'm not a docker expert. I'm not a dev-ops guy. Thank god, there is an open-source application setting it up for me: devpod!
Setting up with Devpod
What is devpod?
Devpod is a client-only application that creates a development environment on any backend. You can choose Kubernetes, Docker, SSH, and the big three Cloud Servider Providers(AWS, GCP, Azure). The great thing is when you click the backend option, it sets up everything under the hood. We'll use was option to use aws spot instance as our backend.
Configuration options in devpod
Installation
Download Devpod from the official website.
Devpod official website-
Run this command to enable spot instance option in the terminal.
devpod provider add aws@v0.0.14-alpha.0 --name aws-alpha
Download AWS CLI here.
-
Open terminal and run this command to see if aws cli is installed.
You need to issue an access key. Visit IAM > My security credentials.
-
Generate an access key.
Configuration
Run 'aws configure' in the terminal and type access key and your region. You can find the list of regions here.
Open devpod application and add a new provider. Make sure to click aws-alpha instead of aws. Check spot instance option.
Create workspace with the aws-alpha provider. You can connect your github repository.
- Make sure to include a .devcontainer.json file, manifesting which docker base image to use and which dependencies to install.
- It'll grab .devcontainer.json or .devcontainer/devcontainer.json by default. You can find a list of base devcontainer image in Micrsoft Artifact Registry.
-
For example, my devcontainer.json looks like this.
{ "name": "Node.js", "image": "mcr.microsoft.com/devcontainers/javascript-node:1-22-bookworm", }
Running with environment variables and secrets
-
After successfully creating, you can add secrets like this when running the app.
devpod up --workspace-env-file [path]
If they are just environment variables that should be public, add remoteEnv option to your
.devcontainer.json
like this.
"remoteEnv": {
"API_URL": "...",
"BASE_URL": "...",
}
How companies use Devpod
Uber has an awesome article about how they built their remote development infrastructure using devpod.
Their problem
- Multirepo(Repository per microservice) caused library version fragmentation and build tool fragmentation. They needed better dependency management.
- Monorepo has new challenges. Builds are larger and longer
- By setting up remote development with Devpod, builds took faster. Since a lot of people need to access the remote development environment, they run it as a container per user on Kubernetes.
Top comments (0)