Image for post
Image for post

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.

How is the Prezi application architected?

We have around one hundred microservices: most are Python, and some are…


Image for post
Image for post

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. …


Image for post
Image for post

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…


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


Image for post
Image for post

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…


Image for post
Image for post

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 volumes, ports, and build. In this post, I’ll talk a bit about what we’ve gleaned from the experience as it relates to Docker Compose’s build functionality.

version: '3'
services:
web:
build: .

When a service has a…


Image for post
Image for post

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…


Image for post
Image for post

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.)

How Host Volumes and Runserver Can Speed Up Your Python Development

As every Python developer knows, the best way to develop your application is to iterate through short…


Image for post
Image for post

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:

  • Specify what containers to boot during development
  • And setup a fast code-test-debug development loop

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…


Image for post
Image for post

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:

Blimp

Local development with containers is slow and heavy. With Blimp get your containers off your laptop and into the cloud https://blimpup.io/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store