{
"path": "/a/3mjxe7zmq6e23-recent-readings-26042026-ephemeral-environments-edition",
"site": "at://did:plc:tbzfsowmg4zj234pws47u3x6/site.standard.publication/3mi2wl3vzsx2z",
"$type": "site.standard.document",
"title": "Recent Readings - 26.04.2026 - Ephemeral Environments Edition",
"content": {
"$type": "app.offprint.content",
"items": [
{
"$type": "app.offprint.block.text",
"plaintext": "At work I've been mainly focused on creating ephemeral environments for our Developers too speed up the development process. Especially nowadays as code is produced faster than ever before testing & QA is becoming the real bottleneck. "
},
{
"$type": "app.offprint.block.text",
"plaintext": "Spinning up a full test environment on the cloud in a matter of minutes is actually not that easy, when you have 100s of services with a wide range of infrastructure dependencies. Every environment needs 100s of SQS queues, DynamoDB tables and more. I will tell about our approach to this in a lot more details soon(-ish), hopefully even give a conference talk or two about it but for now it has definitely shaped my recent readings, as you'll be able to tell."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 43,
"byteStart": 0
},
"features": [
{
"uri": "https://www.uber.com/de/en/blog/simplifying-developer-testing-through-slate/",
"$type": "app.offprint.richtext.facet#link"
}
]
},
{
"index": {
"byteEnd": 465,
"byteStart": 451
},
"features": [
{
"uri": "https://martinfowler.com/bliki/DarkLaunching.html",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "Simplifying Developer Testing Through SLATE - What I find most interesting about Ubers approach described here is that the service being tested is interacting with their live production systems. While they talk a lot about how they ensure data isolation of their shared components like Kafka Topics this still sounds like a decent level of trust in the changes being tested should have already been established beforehand. To me this sounds closer to Dark Launching than Ephemeral Environments. "
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 57,
"byteStart": 0
},
"features": [
{
"uri": "https://www.vcluster.com/blog/ephemeral-environments-what-they-are-and-how-to-use-them",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "Ephemeral Environments: What They Are and How to Use Them - While vCluster here is listing \"Clear Environment\" as one of the Benefits of Ephemeral Environments it is also one of it's downsides. Most features will need some amount of data to test properly and when you bring up a new \"Clean\" environment then you don't have any. Being able to generate pseudo randomized data will therefore be one of the next problems we need to tackle for our ephemeral environments."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 78,
"byteStart": 0
},
"features": [
{
"uri": "https://carloarg02.medium.com/how-we-use-hermetic-ephemeral-test-environments-at-google-to-reduce-test-flakiness-a87be42b37aa",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "How we use hermetic, ephemeral test environments at Google to reduce flakiness - Google seems to heavily prioritize being able to spin-up a service and all it's dependencies on a single box. As long as you can do that it reduces factors such as network problems that can otherwise cause your tests to become flaky."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 67,
"byteStart": 0
},
"features": [
{
"uri": "https://theburningmonk.com/2023/02/how-to-handle-serverful-resources-when-using-ephemeral-environments/",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "How to handle serverful resources when using ephemeral environments - \"For example, I would have one RDS cluster in the dev account. All ephemeral environments in the dev account would use the same cluster but have their own tables/databases.\" This also what we ended up doing for RDS and it works quite well. I liked that this blog actually admits the difficulties you face in handling the stateful parts of your environments that those are best shared by multiple ephemeral environments."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 22,
"byteStart": 0
},
"features": [
{
"uri": "https://vitorogomes.com/posts/2025-03-16-ephemeral-environments/",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "Ephemeral environments - One of the few blogs I could find that actually talks about how they build their ephemeral environments rather than just rambling about the concept or going deep down the theory. Sadly also this one is extremely sparse on details. It mentions they used Gitlab merge request IDs to suffix all ephemeral resources, which is quite close to what we are doing where we use the Jira Ticket ID as the prefix for all ephemeral resources. They also mention that Terraform made it easy for them to spin up ephemeral environments, this I believe can only be true if you are operating at a small scale spinning up large amounts of Terraform resources can take too much time."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.text",
"facets": [
{
"index": {
"byteEnd": 60,
"byteStart": 0
},
"features": [
{
"uri": "https://oneuptime.com/blog/post/2026-02-23-how-to-use-terraform-with-ephemeral-development-environments/view",
"$type": "app.offprint.richtext.facet#link"
}
]
}
],
"plaintext": "How to Use Terraform with Ephemeral Development Environments - while I can appreciate this one actually sharing some Terraform examples it's kept a bit too simplistic. It does show the general approach very well tho, the pipeline first runs a terraform apply to setup the environment, then creates a comment on the MR to let the developer know where to find it."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
},
{
"$type": "app.offprint.block.heading",
"level": 2,
"plaintext": "Closing"
},
{
"$type": "app.offprint.block.text",
"plaintext": "Overall I have to say that there is a very distinct lack of people describing more complex ephemeral environment setup, it's either small scale demo applications or big tech giants only describing their abstract methodology but not going into implementation details."
},
{
"$type": "app.offprint.block.text",
"plaintext": "For the small demo apps, yes of course you can just Terraform apply your 15 resources but what if we are talking about thousands, 10s of thousands? Time matters here, developers and QAs do not want to wait an hour before they can start using their on-demand environment."
},
{
"$type": "app.offprint.block.text",
"plaintext": ""
}
]
},
"publishedAt": "2026-04-26T07:07:17+00:00",
"textContent": "At work I've been mainly focused on creating ephemeral environments for our Developers too speed up the development process. Especially nowadays as code is produced faster than ever before testing & QA is becoming the real bottleneck. \nSpinning up a full test environment on the cloud in a matter of minutes is actually not that easy, when you have 100s of services with a wide range of infrastructure dependencies. Every environment needs 100s of SQS queues, DynamoDB tables and more. I will tell about our approach to this in a lot more details soon(-ish), hopefully even give a conference talk or two about it but for now it has definitely shaped my recent readings, as you'll be able to tell.\n\nSimplifying Developer Testing Through SLATE - What I find most interesting about Ubers approach described here is that the service being tested is interacting with their live production systems. While they talk a lot about how they ensure data isolation of their shared components like Kafka Topics this still sounds like a decent level of trust in the changes being tested should have already been established beforehand. To me this sounds closer to Dark Launching than Ephemeral Environments. \n\nEphemeral Environments: What They Are and How to Use Them - While vCluster here is listing \"Clear Environment\" as one of the Benefits of Ephemeral Environments it is also one of it's downsides. Most features will need some amount of data to test properly and when you bring up a new \"Clean\" environment then you don't have any. Being able to generate pseudo randomized data will therefore be one of the next problems we need to tackle for our ephemeral environments.\n\nHow we use hermetic, ephemeral test environments at Google to reduce flakiness - Google seems to heavily prioritize being able to spin-up a service and all it's dependencies on a single box. As long as you can do that it reduces factors such as network problems that can otherwise cause your tests to become flaky.\n\nHow to handle serverful resources when using ephemeral environments - \"For example, I would have one RDS cluster in the dev account. All ephemeral environments in the dev account would use the same cluster but have their own tables/databases.\" This also what we ended up doing for RDS and it works quite well. I liked that this blog actually admits the difficulties you face in handling the stateful parts of your environments that those are best shared by multiple ephemeral environments.\n\nEphemeral environments - One of the few blogs I could find that actually talks about how they build their ephemeral environments rather than just rambling about the concept or going deep down the theory. Sadly also this one is extremely sparse on details. It mentions they used Gitlab merge request IDs to suffix all ephemeral resources, which is quite close to what we are doing where we use the Jira Ticket ID as the prefix for all ephemeral resources. They also mention that Terraform made it easy for them to spin up ephemeral environments, this I believe can only be true if you are operating at a small scale spinning up large amounts of Terraform resources can take too much time.\n\nHow to Use Terraform with Ephemeral Development Environments - while I can appreciate this one actually sharing some Terraform examples it's kept a bit too simplistic. It does show the general approach very well tho, the pipeline first runs a terraform apply to setup the environment, then creates a comment on the MR to let the developer know where to find it.\n\nClosing\nOverall I have to say that there is a very distinct lack of people describing more complex ephemeral environment setup, it's either small scale demo applications or big tech giants only describing their abstract methodology but not going into implementation details.\nFor the small demo apps, yes of course you can just Terraform apply your 15 resources but what if we are talking about thousands, 10s of thousands? Time matters here, developers and QAs do not want to wait an hour before they can start using their on-demand environment."
}