Hey there! Welcome to Platform Weekly. Your weekly bowl of platform engineering yogurt. Every week, we dive into another part of the platform engineering world discussing and highlighting news, lessons, and best practices.

This week we’ve got a guest newsletter from Lou Bichard from Gitpod previewing a great whitepaper he’s been working on + having a poke at some of the challenges of Docker😉 

Let’s get spicy🌶

What Docker should have been

Docker burst onto the scene in 2013, promising to revolutionize how we build, ship, and run applications. It was hailed as the solution to the age-old ‘it works on my machine’ problem that has long plagued our development teams and caused outsized cognitive load. It wasn’t just innovative because it created containerization technology, Docker made containers developer-friendly by: 

• Simplifying the use of Linux kernel features like cgroups and namespaces
• Introducing a standard container format and runtime
• Providing a simple CLI for building, shipping, and running containers
• Creating a hub for sharing and distributing container images 

Yet, as with many technological revolutions, the reality has been more complex than the promise. Ultimately, Docker gives us part of a solution to the ‘works on my machine’ problem but there is certainly a lot that Docker alone cannot give us. Docker requires developers to grasp not only containers but images, volumes, and networking complexities for multiple containers and host-container communication. It’s easy for platform or DevOps engineers very comfortable with Docker to overlook how complex configuring Docker can be.

But, why is Docker so challenging? Docker introduces its custom configuration file format with the Dockerfile. This configuration exposes developers to skills that are closer to a Linux system administrator than your average developer who already has a tremendous learning workload. Additionally, security concepts like multi-step configurations aren’t always intuitive or obvious and can make docker configurations feel opaque to your average developer. 

Fast forward to today, the path to filling these gaps in the promise of Docker might just be hiding in plain sight. Platform teams at some big tech companies have already stumbled upon this opportunity for significant ROI for platform engineering teams: automated and standardized development environments. 

The Platform Engineer's golden opportunity

By addressing the 'works on my machine problem’ head on platform teams can: 

• reduce development environment setup time from days to minutes
• cut down on debugging time related to environment inconsistencies by up to 50%
• accelerate project delivery timelines by 20-30%

For platform engineers, the imperative is evident. By quantifying and communicating these impacts, platform engineers cement their position as architects of efficiency and showing how platform engineering is a strategic partner to drive organizational success. The message is clear: platform engineering isn't just supporting the business—it's propelling it forward.

The adoption of automated and standardized development environments through cloud development environment platforms is not a novel concept in tech. For years, platform teams have recognized the value in streamlining their development processes. With Uber utilizing ‘Devpod’ so developers can spin up ready-to-code environments with all necessary dependencies setup for them. Shopify uses ‘Spin’ to reduce the time developers spend on environment troubleshooting and management. Google with ‘Cider’ to provide development environments that allow their engineers to work on any project, from anywhere while maintaining security. 

How cloud development environments (CDE) solve the Docker configuration problem

The journey to solve the ‘works on my machine’ problems that Docker started is far from over. We need to consider more than containerization. Not only do we need a simplified interface for working with Docker, but also to consider all other aspects that come with setting up our development environment like: 

• secrets management and systems access (identity provider integrations)
• provisioning of external infrastructure like databases or clusters
• source control, internal developer platforms and portal integration

A cloud development environment is a platform for standardizing and automating development environment. It comes pre-configured with all tools, dependencies and access required to write code. For developers that means they can launch new environments using their preferred tooling. For platform teams CDEs are a centralized place to automate everything related to the setup, maintenance and troubleshooting of development environments. With CDEs platform teams shift their influence to the inner loop of the software development. 

Something that I’ve heard time and again when people see Gitpod for the first time is: “wow, this is what I hoped Docker would have been”. Let me be clear, this is not to say that Docker has not revolutionized our work—it absolutely has. What I feel this points to is an acknowledgement that to fully solve the ‘works on my machine’ problem we need to build on and around containers with additional developer experience to fully solve this problem. 

The golden standard we’re striving for is the ability to press a button, and for developers to be productive as quickly as possible. This is the mission of a CDE and it was the original promise of Docker. CDEs are built on and extend container technology with Dev Container to give a full development environment including all your tools ready to go at the click of a button. 

If you want to understand how this is possible and research into the clear ROI of this, download my full paper.