(We’ve already cut our own infra costs by more than a third.)
The dream as a Kubernetes developer is to be able to run a single command, spin up a production-like dev environment, then just focus on coding, with...
- No time wasted messing with Kubernetes or trying to make sense of dependencies.
- No worrying about whether your laptop will burst into flames (because you can easily develop in a remote cluster if you want to).
- No tears shed over mysterious CI errors caused by configuration drift.
Making that dream a reality is why we created Garden in the first place, and we’re pretty excited about the upgrades our users have made to their Kuberentes development experience.
We kept hearing a totally reasonable concern, though: once you’ve given all your Kubernetes devs access to on-demand, in-cluster environments (and made them oh so happy), how do you keep your infrastructure bill in check? Devs love their environments, and they’re gonna put them to use.
The same goes for preview environments deployed with every pull request. It’s great to give your QA team and code reviewers a working version of the application they can reference during the review process. But cloud infrastructure doesn’t come for free, and especially on larger dev teams, costs from environments can get out of hand quickly. You don’t want your ops people spending their days monitoring and manually tearing down environments—all you’ve done then is shifted wasted time from one team to another.
Enter automatic environment cleanup
Our most recent Garden Cloud and Enterprise release includes a new bit of magic to solve this problem: automatic environment cleanup (docs here). Though it was a pretty tricky feature to build, it’s wonderfully simple conceptually and in terms of how you use it.
In short, you can now configure Garden Cloud and Enterprise to automatically delete Kubernetes Namespace resources...
- When a namespace hasn't been used by a Garden command for more than a specified number of hours
- And/or at a specified time of day (or at a specified time on a given day of the week)
This cleanup can optionally be enabled on a per-environment basis, and the cleanup schedule for each environment can be set independently.
And it’ll actually save me money?
Bottom line, yes: this feature can significantly cut your infrastructure costs. We know this because we’ve been using automatic environment cleanup for the past two weeks (naturally, we use Garden internally to power our own development process), and we’re already saving a lot of money ourselves.
Here’s a quick rundown.
We used to need 9 <span class="p-color-bg">m4.large</span> nodes in AWS in our most heavily used internal cluster. We found that 9 nodes was the fewest we could get by with in order to not run out of resources when CI runs were scheduled.
These 9 instances each cost around $70/month, or $630/month in total. After enabling autoscaling and automatic environment cleanup, costs for the cluster have dropped to approximately \$400/month, for savings of more than 36%. And that doesn’t even take into consideration the saved opportunity cost of not having our devs or ops people manually managing environments, instead focusing on high-value work.
It’s still early days for automatic environment cleanup, so we’ll be sure to update you on our cost savings over time along with best practices on how to get the most out of the feature.
How do I get started?
The fastest and easiest way: with a Garden Cloud trial. Get in touch with us here, and we’ll get you set up ASAP.
You can also learn more about our product and read up on our plans and pricing.
If you'd like to learn more about automatic environment cleanup, you can check out the docs.
And if you just want to learn more about Garden and how we can help you build a faster and more efficient Kubernetes development experience, feel free to reach out to hello@garden.io. We’re always happy to chat with you.
Photo by Victor Garcia on Unsplash.
