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. It’s not the IDE, compiler, debugger, or any of those other tools.
Cloud-Native Broke Development
The cloud-native movement, typified by technologies like Docker, Kubernetes, and service-mesh focuses on resilient, scalable, and self-healing production infrastructure. Despite some growing pains, teams that adopt the cloud-native architecture benefit from higher feature velocity, reliability and scalability.
However, the progress has come at the expense of developer experience. Cloud-native technologies tend to be built by and for engineers focused on production. Precisely those design decisions that have made it so powerful in production have been to the detriment of developer experience. Today, we find ourselves in a strange situation where developers have taken a step backward, working with tools that make development more difficult than when building VM based monoliths.
The primary source of the problem has been the development environment. In a cloud-native world, any container likely has many dependencies, such as other containers, serverless functions, and cloud services. For developers to test changes to a service, they need to run all of these dependencies locally. A task complicated by challenging tooling and limited resources available locally.
Limited resources
When a team first adopts containers, they usually have a monolith and maybe one or two microservices. Developers write a Docker Compose file to automate and share their development setup, no problem.
As time goes on, the engineering team tends to add more and more containers. There’s constant pressure to release new features, bug-fixes, or products. In many cases, the path of least resistance is adding more containers, which (of course) require additional resources to run. In production, but that’s no big deal — we built a super scalable cloud-native infrastructure, so that problem more or less solves itself.
In development, however, the amount of RAM and CPU required by containers can quickly exceed the amount available on the laptop (especially after taking into account other things that may be running locally like Browsers and IDEs). When this occurs, performance collapses, and even basic tasks like starting an environment can take hours.
How Cloud Native kills developer productivity
Making the switch to microservices but think it’s too good to be true? Or you already made the switch, but you’re starting to notice that local development is harder than it used to be. You’re not alone. Read more of this whitepaper
Blimp
At Kelda, our first step toward solving the cloud-native development problem is Blimp — a new service that makes it easy to run containers in the cloud for development. Blimp ensures you have the same development experience you had while running locally, but with infinite resources at your disposal.
Blimp is a drop-in replacement for Docker Compose that has the same experience as working with Docker locally. Take any existing docker-compose.yml file, and instead of running docker-compose up, run blimp up to run it in the cloud instead.
Cloud development environments
We believe that the future of cloud-native development environments is in the cloud. By running in the cloud, developers aren’t constrained by the resource limits of their laptops. Additionally, running in the cloud lets SREs take responsibility for development environments, so that they can create a development experience that just works for their developers — just like how they provide a simple experience for deployment via CI/CD.
Many top tech companies already run their development environments in the cloud. Eventbrite, Slack, AirBnB, LinkedIn, and many others, have built internal solutions to move their development environments to the cloud. However, building it yourself requires a dedicated team of engineers.
Blimp makes it seamless to move your development environment to the cloud so that you can make the jump without a dedicated team.
Zero Setup
A key goal for Blimp is to make it easy for developers to adopt Blimp. Developers shouldn’t have to change their workflow based on a new tool, or write yet another YAML file. That’s why we made Blimp fully backward compatible with Docker Compose.
Blimp doesn’t just support the basic Compose configuration for booting containers. It respects important configuration like build, volumes, ports, depends_on and healthchecks. Blimp also mirrors Docker runtime behavior like volume initialization.
This might seem like a somewhat counter-intuitive choice. Kubernetes is the future! Why Docker Compose?
We noticed an interesting pattern. Even with teams that had standardized on Kubernetes in production, the developers still chose Docker Compose as their primary platform for running containers. You run into exceptions to this rule, such as folks using Minikube or some other hand-rolled solution, but Compose is typical.
Simple hosting
Additionally, to make it easy for users to get started with Blimp, we offer a software-as-a-service version that allows you to get started with Blimp in seconds — no need to create any backend infrastructure.
For security conscious teams and those that want more control and observability, you can also self-host Blimp on your own infrastructure. Under the hood Blimp just runs on a stock Kubernetes cluster, so Blimp works with a variety of cloud providers.
Zero workflow changes
Standardizing on Docker Compose for the configuration is necessary, but not sufficient. There have always been ways to run Docker Compose files in the cloud, ranging from Docker Machine and kompose, to just doing it your self.
Development environments are more than just a collection of containers. The key is how you interact with those containers. How do you get the logs? How do you view the frontend? How do you change the code? How do you attach a debugger? The key to a great development experience is getting these details right.
Blimp not only allows you to run containers in the cloud, but it does it in a completely transparent way. Everything (and I mean everything) works the same as it did when working locally. Use host-mount volumes to mount code directly into your container, view changes on localhost, attach a debugger, use your existing editor. Everything is the same.
Conclusion
Over the past year, we’ve seen an accelerating trend toward the adoption of containers and other cloud-native technologies. At a small scale, with relatively simple deployments, the development experience can be great. But as the number of containers grow, devs must deal with increased complexity, and worsening performance. Blimp is the easiest way to run remote development environments without any configuration work, or workflow changes.
By: Ethan Jackson
Next Step: Create a free Blimp account and try an example app
Resources
See how Blimp compares to other tools.
Check out the command documentation to see what’s possible with Blimp.
Check out the configuration documentation.
