Development Environment: a journey seeking the 'perfect' setup.

A tale of an IT Engineer searching for the holy grail of Development environments

Development Environment: a journey seeking the 'perfect' setup.
Photo by Goran Ivos / Unsplash.

Containers are far from new, the first time I've used a container as my development environment probably traces back to 2014 - the early days for me and Containers when people were still all-in on Virtual Machines and were confused with the idea of sandboxed containers.

At that time, I was using the containers as a mean to have fun with Linux Containers. There wasn't much space to run those unless you had a Linux VM (Virtual Machine) in Windows Azure - I worked at Microsoft at that time, everything I did was in Azure - and then install the base for running something in there. Far from perfect, but much friendlier than the available services. Application Gateways were super slow and based on IIS (Internet Information Services); Creating VMs and restarting them was a whole ordeal; but I digress.

As you probably are aware, things have changed. With the change, the idea of Containerization got traction and it's much easier to run and deploy your containers. With that, the developers of the tools we know and love also got used to the idea of publishing their binaries in an easier manner to pull and install in our containers; making it much easier to setup what you need when you need it. But something changed as well on my usage of containers.

In my early career days, the computers available to me were hilariously terrible. They barely had enough RAM and had outdated CPUs that couldn't even run their own OS.

Time has now passed. With more experience - working as a consultant - With my own device I could dream about the 'perfect' setup. The advent of "BYOD" - Bring Your Own Device - allowed me to invest more into what I believed was the best. I would spec out my machine to not have to worry about such predicaments. The desire to offload my work to somewhere else dwindled. I wanted something FAST, and I wanted it to work local so I wouldn't have to worry about the performance of my machine because of my unreliable internet connection while living in Brazil.

I won't go into how it is finding the 'best' machine for my workflow. Or trying to find the 'best' Operational System. I've tried building my own and just installing many... Many... MANY flavours onto my laptops to try and have the perfect "feel" of my machine. It would take too long for me to put that down here.

But life, my friends. Life is full of surprises. Once again things have changed, and living in Canada where the internet infrastructure is much better gave me a new opportunity to rethink what I believed was best. All of this to say: everyone has their own version of "perfect" and there's nothing wrong with that. With all of that in mind, here are my current requirements:

  1. Portability: Most of my clients need me to work through their own infrastructure, which could be:
    1. Laptops running Windows or MacOS
    2. Virtual Machines in a Cloud provider
    3. Virtual Machines. On Premises.
    4. Shared Virtual Desktop Environment.
    5. BYOD.
  2. Ergonomics: I need to be able to navigate through code in the way that makes sense to me:
    1. VIM motions are a requirement for coding
    2. Terminals make more sense to me.
    3. Shell environment that I enjoy using.
  3. Security: everything must be up-to-date to protect me and my clients.
    1. Dependencies must be kept up-to-date.
    2. I must be aware of vulnerabilities and be able to patch them ASAP.
  4. Backup: As much as everything is in the VCS (Version Control System - i.e. git), not everything is there.
    1. Current workflow files that I haven't committed should be available.
    2. Configuration for the environment should be easy to reset in a moments notice - I've been bitten in the *ss too much by not being ready for this.
    3. Notes that I usually make along the way must be available - which is the same as 4.a.
  5. Easy to install everything that I need: WSL doesn't cut it. Sorry.

Anyways, that's a long way of saying that I've landed into something that feels very comfortable for me as I went through this list: a dev-container. You've probably already guessed it from the start of this post that I had containers in my mind from the get-go. If you also know me in person, you already know that I love containers and Kubernetes; I'm definitely biased. I take no issue to say that I am indeed excited about orchestrating containers and making platforms, that's what I do! But I honestly feel it's one of the best options if your requirements align with mine.

It's also no secret that I've done this in the past and have used my code-server setup for a long time. You can see how this solution looks in one of my YouTube videos:

It works quite well in terms of Backup, Security and OK for portability. But I can't deny that using VSCode is quite a let-down when y0u are used to VIM motions and have a more 'personalized' setup. I've been through VIM, NeoVim, Zed, PyCharm, Visual Studio, Eclipse, Visual Studio Code, XCode, you name it. Using VSCode was just a let-down for me; It works well enough out of the box, but the features and the ergonomics weren't there for my workflow.

I have also found myself having to work around this environment to fit my requirements. Most of my clients needed me to be on VPN - which wouldn't really work on a container running in my Kubernetes cluster - or they would block most internet access from my environment. This included my IP addresses and services. It was good enough for 30% of my professional work and for personal projects, but it kept getting more and more cumbersome to adapt.

That's when I gave up. I went back to my 'old' ways. Here I was again with my trusty terminal and NeoVim. And I asked myself: Why not create a container that has everything that I need, and could run locally if my clients can't allow me to run a remote server? This way I could reach out to a trusted registry by them - usually Docker Hub or GitHub Packages - and download my dev environment! I would not have my files, but at least my dependencies would work exactly the same! All I had to do is bind the volumes to the local machine and just like magic: I had an environment ready in no time!

Here is my current state of said environment: https://fancywhale.link/dev-container

I will be developing it in my free time to enrich my experience. For now, I feel great that I am developing something that potentially can hit my requirements:

  1. Portability: It's a container image. Could be used anywhere.
  2. Ergonomics: This image contains everything I want it to have. I just need my terminal and use the local machine for other types of apps like browsers and teams communication.
  3. Security: With this image I can keep scanning it and have the reports of all vulnerabilities arrive to me as soon as something happens to the binaries that are in it. As long as I keep using Renovate - a dependency management tool used heavily at FancyWhale - I feel confident the dependencies will be updated in a timely fashion.
  4. Backup: For times where I can run this container in my Kubernetes cluster, I can keep it running with proper backups and just spawn it back up somewhere else with everything the way it was.
  5. Easy To Install: I just need the machine I am using to either connect to my FancyWhale endpoint, or to have a way to run my container.

The quest for perfection is ongoing, but I'm happy knowing that I've found a foundation upon which to build my journey – and it feels like coming home.