Unlike production, development environments usually evolve ad-hoc. Teams are so busy deploying new features that they don’t have time to invest in “sideways work” that doesn’t result in immediate value for customers.
I’ve noticed that one tactic teams use to prioritize developer productivity is to let some efficiencies build up, so that they can understand the underlying cause and invest in fixing that.
In this post, I chatted with Laszlo from Prezi to hear how they’ve increased developer happiness and feature velocity by iterating on their development workflow.
We have around one hundred microservices: most are Python, and some are Scala or Go. …
Blimp is a drop-in replacement for Docker Compose that runs your development environment on Kubernetes in the cloud. It’s backward compatible with Docker Compose, the most popular local development tool today. Take any existing
docker-compose.yml file, run
blimp up, and get a development sandbox with infinite resources at your disposal.
In this post, I’ll explain why we built Blimp and describe some of the design principles behind it.
Note: For this post, I consider a “development environment” as a sandbox in which developers can run their code and dependencies for testing. …
In Part 1 of this interview with Remy DeWolf, a principal engineer on the DevTools team at Eventbrite, we discussed what information factored into Eventbrite’s decision to move their development environment to the cloud.
The DevTools team at Eventbrite set out to build
yak because they had too many services to run locally. They knew they wanted to move their development environment to the cloud, but it ended up
yak had additional benefits that ranged from sharing environments to transitioning to working remotely due to COVID.
In this post, we dig into how
yak works, what it’s like for devs to use it, and how it’s been received. …
Deciding when to invest in developer productivity improvements is hard. If you’re on the ops side of things, you’re usually concerned about production and releases. If you’re a developer, you’re concerned about getting new features out as quickly as possible.
Usually, teams make development productivity improvements in two situations. Either the fix is so small that you can just do it in addition to your other work, or development is so painful that making changes has ground to a halt.
However, there’s still a large murky middle ground: how do you decide that it’s worth investing in a large change to your development workflow before development has ground to a halt? …
Let’s discuss an extremely common anti-pattern I’ve noticed with teams that are relatively new to containers/cloud-native/kubernetes, etc. More so than when building traditional monoliths, cloud-native applications can be incredibly complex and, as a result, need a relatively sophisticated development environment. Unfortunately, this need often isn’t evident at the beginning of the cloud-native journey. Development environments are an afterthought — a cumbersome, heavy, brittle drag on productivity.
The best teams treat development environments as a priority and devote significant time to perfecting them. In doing so, they end up with development environments that “just work” for every developer, not just those who are experienced with containers and Kubernetes. …
At Kelda, we’re building Blimp, a version of Docker Compose that runs in the cloud. Our goal is to improve the development productivity by providing developers with an alternative to bogging down their local systems with loads of resource-hungry Docker containers.
We’ve put a lot of engineering effort into supporting all of the Docker Compose fields commonly used during local development, such as
build. In this post, I’ll talk a bit about what we’ve gleaned from the experience as it relates to Docker Compose’s
When a service has a
build field, Blimp builds your images locally, and pushes them to the cloud so that they can be pulled by the development environment. This push can be frustratingly slow, especially on home networks. Waiting 30 minutes for the image to upload before being able to start developing was just unacceptable to us. …
One of the most time consuming parts of booting a Docker development environment is initializing databases. The data container pattern gets around this obstacle by taking advantage of some less known features of volumes. With data containers, you can easily distribute, maintain, and load your database’s seed data.
Data containers are a commonly overlooked tool for building the nirvana of development environments: booting the environment with a single command that works every time.
You’re probably already using volumes to save you some time working with databases during development; if one of your development containers crashes, volumes will prevent you from losing the database’s state. …
Docker has many benefits that make deploying applications easier. But the process of developing Python with Docker can be frustratingly slow. That’s because testing your Python code in Docker is a real pain.
Luckily, there’s a technique you can use to reduce time you spend testing. In this tutorial, we’ll show you how to use Docker’s host volumes and runserver to make developing Python Docker applications easier and faster.
(If you’re a Node.JS developer, see How to Develop Your Node.Js Docker Applications Faster.)
As every Python developer knows, the best way to develop your application is to iterate through short, quick cycles of coding and testing. But if you’re developing using Docker, every time you change your code, you’re stuck waiting for the container to rebuild before you can test. …
When building a containerized application, developers need a way to boot containers they’re working on to test their code. While there are several ways to do this, Docker Compose is one of the most popular options. It makes it easy to:
The vision is that someone writes a
docker-compose.yml that specifies everything that’s needed in development and commits it to their repo. Then, every developer simply runs
docker-compose up, which boots all the containers they need to test their code.
However, it takes a lot of work to get your
docker-compose setup to peak performance. We’ve seen the best teams booting their development environments in less than a minute and testing each change in seconds. …
We recently ran into a mysterious bug that required hours of digging into the arcane details of Docker’s registry credentials store to figure out. Although in the end the fix turned out to be easy, we learned a thing or two along the way about the design of the credentials store and how, if you’re not careful, it can be configured insecurely.
Blimp, sometimes needs to pull private images from a Docker registry in order to boot those images in the cloud. This typically works fine, but unfortunately, when some users started Blimp, they were getting the following error message:
Get https://1234.dkr.ecr.us-east-1.amazonaws.com/v2/blimp/blimp/manifests/v0.1: …