My least favorite part of working with Kubernetes is running it on my laptop.
It gobbles up my CPU and battery, keeps the fans running non-stop, and it’s a nuisance to maintain.
For added effect, a relevant stock photo.
Minikube, kind, k3s, Docker for Desktop, microk8s, etc. are all excellent efforts designed to make that as pleasant as possible, and kudos to all of them. Seriously. But no matter how you slice it, Kubernetes isn’t intended to run on my laptop. Nor is my computer designed to run a cluster of containers in layers of VMs. The unfortunate thing will try its best, but it won’t like it and will show its dissatisfaction by making its fans scream, and scalding my thighs if I’m not careful.
Let laptops be laptops, we say.
Garden is a tool for developers, in the same area as Skaffold and Draft that makes developing and testing Kubernetes applications faster and easier.
Since we started working on Garden, about eighteen months ago, we knew that developing distributed systems locally was a stop-gap solution, so we designed Garden with a lot of flexibility in mind and laid some solid foundations.
Now we’re ready to support both local and remote Kubernetes environments, and it’s better than ever: you can now run all your builds, deployments, and tests in a remote cluster.
With Garden v0.10, you can completely get rid of your local Kubernetes cluster and still enjoy rapid feedback while you write your code. All free and open source.
Enjoy the same developer experience with remote and local environments.
Okay, you have my attention.
I’m glad to hear that, dear reader who is not me talking to myself, because there’s more!
Sharing development clusters has broader implications, especially for teams working together, and for CI pipelines.
First off, the in-cluster builder — either a standard Docker daemon or Kaneko — and the bundled in-cluster registry are shared cluster-wide. Meaning, your team can share a development cluster, and all the build caches and images are shared across all developers. Because Garden tags your pictures based on hashes of your source files, the tags and layers are consistent between users.
This means that once any developer has built a version of an image, your whole team has as well. Day in and day out, developers download the same base images and make the same things on separate computers. I wonder how much bandwidth and electricity has been wasted on that…
And the same goes for tests: test results are stored cluster-wide and are available for your whole team, in much the same way. Once one developer has tested a version of your code, no-one has to repeat the same test.
So it’s not just about not having to run minikube. This leap opens up a lot of optimizations for your team — no more redundant builds and test runs!
What was that about CI?
Most of us are used to local dev and CI being two separate worlds that you need to configure separately — and don’t share a cache. Now you can fold the two together, and get rid of much of that friction:
You can run the same commands in CI as when you develop and use the same environment, caches, and test results.
Your CI becomes a bot developer working in the same environment as you.
All the moving parts, through development and testing.
You can drastically simplify your CI pipeline configs. Just run Garden from CI to do the builds, tests, and deploys — and because you and CI use the same environment, you’re much less likely to find yourself debugging CI issues.
All that poking at thousands of lines of configs and scripts, then pushing, waiting, hoping, rinsing, and repeating ad nauseam… None of that. You develop — no extra steps.
And to make it crystal clear: When you or anybody on your team has built or tested something with Garden, so has your CI. If you don’t change anything after running tests yourself, your CI doesn’t need to test it again, or even build it. Garden checks the box and goes straight to your other workflows, like spinning up a preview environment, pushing artifacts, and so on.