Cloud costs - a nontechnical primer
Cloud costs are the devil’s mix of complicated, confusing, and infuriating.
When you’re spending $20k+ per month on AWS (or GCP, Azure et al) and it’s eating into your gross margins, you want to find ways to cut and save.
The second you start investigating, you find yourself down a miles-deep rabbit hole… lost, confused, and angry. At least, that’s my experience as a nontechnical founder & SaaS exec. A lot of my friends are in product leadership, finance, and executive roles and feel the same. Cloud costs are too damn high, but also impenetrable.
I am not looking for a PhD in cloud infrastructure. I just want to cut my cloud bill, fast, ideally without interfering in the development, testing, and deployment of my product.
Ephemeral environments, cloud costs, and the “obvious” button
When I first met the team at Shipyard, it took me a few attempts to understand what ephemeral environments were. But when I finally understood, I realized they were the simple cloud cost solve I was looking for, but didn’t know how to express.
Ephemeral environments do a lot of things - the gist is that, instead of having a bunch of pre-production environments for developers that are on 24/7 (for development, QA, testing, staging, etc.), you instead spin up and down test environments as needed for not only developers, but all the stakeholders at your company!
So let’s say you’ve got 50 developers sharing a bunch of testing and staging environments. Today, that means:
- 50 developers have to fight & wait to access a test environment, and new features get jumbled in this environment when everyone’s trying to test, preview, & deploy
- The testing / staging environments usually don’t represent your production system (which leads to bugs in production) because of #1
- And, you’re paying cloud costs for these testing & staging environments to run 24/7
1 and 2 are annoying enough - it tells me the development process is inefficient in dumb ways that deserve to be fixed. But 3 is infuriating to someone thinking about costs: We’re incurring cloud costs for environments we’re not using. They don’t turn off themselves? We can’t turn them off when we’re not using them? What?
That’s where ephemeral environments come in: Instead of having a bunch of testing and staging environments that are racking up cloud bills 24/7, you just spin up a testing environment when you need it - then spin it down when you don’t.
Quick napkin math on that:
- Pre-production environments represent ~40% of total cloud costs
- They are on 24/7 but are needed for maybe 40 hours per week… which represents 128 hours of “dead time” (~76%)
- So if this napkin math works, about 28% of cloud costs are addressed by just turning pre-production environments off when they’re not in use
This is the kind of math that just makes me want to hit the “obviously we should do this” button.
Asada Aside
I just bought a grill. Imagine if it used a ton of propane, and I was trying to fix its propane use. After detailed analysis, I could do 2 things:
- Deconstruct the grill to optimize propane use through each burner
- Or, turn the propane off when I’m not using the grill, because I’m an idiot and leave the propane on
Ephemeral environments are the equivalent to “turning the grill off.”
Shipyard: Ephemeral Environments Made Simple
Shipyard helps you cut your pre-production cloud costs 70%. Instead of using a 24/7 staging environment, you’ll get short-lived, on-demand environments on every PR. As soon as you merge a feature branch, your environment automatically spins down. It’s that simple.
Book a demo to learn more about ephemeral environments can help your organization.
