Burners - Preview Environments for Kubernetes
Hi, Indie Hackers!
I'm posting today to share an idea that's been percolating in my brain for a while. I'm a Software Developer that has seen quite a few companies (including two I've personally worked at) stumble to scale their development workflows when adopting Kubernetes. It's big, it's awesome, it's low level, and it's also lacking some niceties that make one long for a PaaS like Heroku or Render.
Specifically, it's harder than it needs to be to get unique environments spun up with minimal fuss to dedicate to particular teams, customer demos, QE, and pull request reviews.
Without further rambling, I present:
Burners - Preview Environments as a Service for Kubernetes
Burners is a low-to-no-bullshit way to bolt that feature-set onto your existing Kubernetes compute with practically zero work. The name is a callback to a burner phone, where you use it for the purpose you need and then deep-six it when you're done.
You install a lightweight agent to your cluster and we use secure tunnels to coordinate deploys, tear-downs of running containers, and provide ingress to your services. We provide a subdomain and you're off to the races in seconds. As an added bonus we'll keep your deployed domain names active - we can use our global proxy to cold start a version in the past to allow you to do time travel verification or regression hunting!
When starting out with the idea I firmly believed using one's own compute was a cornerstone goal, especially for an MVP. Nearly everyone that runs Kubernetes already has an image registry and likes controlling their own compute budgets and security. Burners has a priority of not up-selling you on stuff you already have and don't want to pay for and only selling you the management piece you are missing. Our pricing investigation is in-progress, however because of these choices, we can offer a very affordable service with linear and predictable costs.
On a personal note, I joined the Indie Hackers community a few years ago with the dream of creating a sustainable business for myself. I made a lot of mistakes as an Indie Hacker - chief amongst them were wasting way too much time on contracting for supplemental income, and building before validating (this is a death trap, please don't). Then we had COVID and I went back to work - then a few short days ago I was abruptly laid off. I think in a way the universe was telling me to give things another shot, and here I am.
Burners looks interesting! It's under active discussion right now when 'testing' should happen on Kubernetes, and I think this tool addresses the fact that there's a phase before formal integration testing where we'd like to see our code deployed on a k8s cluster.
Did you get a chance to look at Kelsey Hightower's twitter space from today? He talked quite a bit about this question, in the context of using Loft (I can't post links but check his feed for July 4)
I work on the Signadot team, which is addressing a similar problem for a different scale of team: when the issue isn't needing to downscale/stop your staging environment but rather, how do you let hundreds of developers test on a cluster without colliding with each other. Instead of extremely temporary, disposable clusters, Signadot does routing within a cluster to let multiple people test changes at the same time.
Another example is Razorpay's open source project devstack, a highly opinionated way to let developers experiment with staging.
I think the only thing we all know for sure is that this isn't yet a solved problem, and the solution will vary by team scale!
Burners looks really interesting and I look forward to trying it out!
This is very, very helpful comment! I have found there are many potential competitors in this space, all offering various types of solutions that solve different pain points particularly well.
Burners, I think, is meant to address a niche. How worthwhile that niche is remains to be seen, but personally I see potential for a service that's core offering is pain pill instead of a full blown solution. I will check some of those out - I'm sure some of these are open source and I've been debating which components should be open, or if it should all be open with a copy left license.
The tunnels are a bit of a snag since they are major convenience feature, but don't make any sense in a totally home grown setup. I'll be definitely thinking about all this. My priority is to meet people where they are and help them to get to where they want to be. Burners is one of the most hands off approaches I've seen, although it of course asks you to consider adding a SaaS in the mix to get there.
This is kind of "un-Kubernetes", but there are a lot of people running Kubernetes that want some low level control but not hand roll or deploy absolutely every component they need.