Blog

Setting up a development environment is not as easy as it once was. It’s hard to remember the days when all you needed to launch your brilliant new startup idea was a LAMP stack and a dedicated server. Perhaps you were exceptionally successful, and you hauled in HAProxy and a few more servers. Still, easy-peasy!

Installing Python, MySQL or PostgreSQL was well within reach of most web developers, and developing "locally" didn't even require fighting Apache rewrite rules. Strikingly, developing remotely was nothing exceptional, and we didn't distinguish between local and remote development.

We won't get a free ride back to the past we loved with Vim or Emacs: grand displays of chorded keystrokes, a single Python process, and a silent CPU fan. The future is here, and it has a broken development experience.

The complexity of modern software systems has been written about and discussed with vigor. The complexity of a multi-container microservice architecture often overshadows the resources required to develop one. Let's talk about that and how adopting a sidecar can help.

More Resources!

Many companies issue underpowered laptops to developers and ignore the impact it has on a developer, which is inexcusable. I imagine the situation from this Hacker News article is happening a lot right now:

"I just had to explain to a bunch of project managers that developers cannot do docker-based workflows with a bunch of locally running cloud service emulators … with 8GB of RAM. Watching those poor coders clicking around and typing was just painful. Multiple seconds to respond to any input. Madness."

My laptop is not in the aforementioned category. It's a Dell XPS 9570 15" Intel Core i7 with 32GB of RAM and a 1TB SSD. Unfortunately, it's not enough, and it has an annoying and constant CPU fan murmur on most projects. It's not the hardware's fault. A laptop is not supposed to be a mini-cluster of containers, multimedia comms tool, and IDE for coding, all at the same time.

Developing modern software requires more resources. The solution is not to buy the highest spec M1 Macbook. As powerful as it is, a multi-container project will test its limits. Ideally, companies should provide a remote development environment with enough resources to work productively. However, setting up a remote development environment isn't trivial.

It's no surprise that we see more and more products to enable remote development, like:

• GitHub Codespaces from Microsoft,
• Space,
• Gateway; and
• Fleet from JetBrains.

In my experience, none of these products are capable of running a complex set of Docker-compose services yet. They are most suited to simple projects with a single Dockerfile. What other options do you have?

Enter the Sidecar

If I Google "sidecar," the top Wikipedia hit is the sidecar cocktail. I can riff on that, but that's not the one we’re talking about. I am, of course, referring to a one-wheeled device attached to the side of a motorcycle.

The purpose of the sidecar is clear: to carry the extra load. When your laptop requires most of its resources to run a Zoom call and preserve your browsing history in 90 open tabs, it makes sense to offload some processing to a "sidecar."

Any old gaming PC, workstation, mini-PC, or even some Raspberry PIs can become your new development sidecar. In my case, I went for a custom-built RYZEN 9 5900X workstation with a super-fast 1TB SSD and 64GB of high-speed gaming RAM. Whether you repurpose old hardware or invest in a more powerful workstation, you will improve your development experience immediately.

If you use Docker, I recommend installing Linux on your sidecar. Docker uses the host kernel directly on Linux. On Linux, a container is just another running process with direct access to the host infrastructure. On macOS, Docker runs inside a VM with a Linux kernel, often with terrible performance.

If you add a Linux sidecar, you can continue to develop on your favorite desktop OS while your sidecar runs Docker natively with much better performance. Even if I had a MacBook M1 Pro, I would still opt for a development environment where I can deploy and run the project on an entirely separate machine. Here are some notable benefits:

• my development experience doesn't change with project resource requirements; and
• upgrades on my laptop leave the development environment untouched.

How it Works

How does one develop locally but run processes and containers on the sidecar? The simplest way is to clone the repo on the sidecar and use a remote development extension to connect a locally running IDE to the remote environment. VSCode and Jetbrains IDEs have remote development extensions that make this very easy.

With VSCode, one can take this a step further and develop inside a Docker container. Development containers dramatically reduce the amount of setup and installation required before you can start with development. Additionally, it guarantees that all developers share the same development environment. In a future blog post, we will dive into how to use a VSCode development container on a project with multiple containers, each with its own Dockerfile.

Cloning the repo on the sidecar or remote machine is not the only way to develop remotely. Consider it to be a gentle first step towards a better development experience. An alternative is to clone the repository locally and use a Docker context to run the containers on a remote machine. When using a Docker context, it becomes challenging to synchronize source code between your laptop and the container. Cloning the repo on your sidecar is a perfectly workable solution.

Always make sure that you are allowed to install a development environment on a machine that is not issued by the company you are working for. If you are working on company-issued hardware, I would recommend you ask the company to provide you with additional resources, either in the form of a sidecar or an instance in the cloud.

I am actively working on ways to improve the development experience for Six Feet Up’s production team. A development sidecar was the first practical step toward improving it without disrupting the development workflow too much.

I am currently working on a detailed Kubernetes development workflow, and I hope to share just how empowering it can be to your team. Read Six Feet Up’s blog for more best practices, and sign up for ACCELERATE to get tech tips directly in your inbox.