2 ms·
The article correctly outlines the benefits of ephemeral envs but glosses over the elbow grease needed to get there. Going from static staging envs to ephemera
by nunez 4y ago
The article correctly outlines the benefits of ephemeral envs but glosses over the elbow grease needed to get there.
Going from static staging envs to ephemeral envs is a lot of work for non-startups with traditional release processes.
Data is an example of a challenging hurdle. It is (somewhat) straightforward to Terraform production and modularize it to make it repeatable. But what do you do when your most current tables have customer PII or other sensitive data in them and migrations are done manually during release? Now you need to audit the entire database for fields where PII might exist so that automation can be written to dump those databases and sanitize that data.
Then there's scavenging the envs. Ephemeral envs can cost A LOT of money. Many places also do not apply as rigorous reporting on resourcing in those envs as they do in production. So what happens when you get a new CEO who wants to cut infra cost by an insanely high figure and you start with the preview envs, but you have no idea which are for active PRs, which were created out of band, which are prod-in-all-but-name, etc?
It's definitely worth the work, as I believe that ephemeral envs lead to safer, faster releases, but getting leadership to buy in and invest capital is often a requirement.
IMO the REAL challenge is creating quality, ephemeral LOCAL environments. So many apps need a crap ton of infra to stand up for no other reason than "we use a crap ton of infra to build and test our app". Like, if I NEED to create a VPC to run an app as a Lambda function because the author tests by shipping directly to Lambda from their IDE or whatever, that's a waste of money and productivity. No reason why we can't run that in Docker locally and mock external dependencies as needed.