Keep your cloud accounts clean by setting TTL on unused resources
We talk about the importance of keeping development environments clean from forgotten cloud resources while allowing developers to work freely.
Originally published on Altostra.
Every developer deserves a deployment
As developers, we want to keep our work momentum while intermediately doing integration testing in a real cloud environment. But, if the environment is shared with other developers on our team, we run into a common set of problems: overriding each other’s work, coordinating who’s testing right now and waiting in line for others to finish.
A common practice to deal with these problems is to work with branch deployments where developers create an entirely separate deployment for their project branch. When done and integration is needed, they deploy to a shared deployment.
Cleanup as a Service
Of course, the problem with creating ad-hoc deployments all over the place is that eventually, someone will have to clean them up. Either because one might have an OCD, and it hurts their brain to see all that clutter (hello 👋 ), or that some resources from these deployments might cost money if not removed. Over time, the costs can accumulate, and the cleanup work will get more challenging and more error-prone if automated with scripts.
So what can you do? Well, there are cleanup services for offices, houses and cars, then why not for development environments? Why not let developers create as many deployments as they want and then delete them after a relatively short period — a day or a week.
Our thoughts exactly! And we got positive feedback as well, so we’re not crazy. That’s why we added a setting that enables deployments to be ephemeral in environments.
On our Altostra production account, we have two environments called “Weeklong” and “Daylong” that respectively have their Deployment Expiration times set to a week and to a day. We use them to do isolated development, experiments and demos — without worrying about cleaning them afterward.
Counting the Minutes
Let’s see this feature in action. We’ll create a new environment with an expiration policy of 2 minutes and deploy our project from a previous post to this environment.
First, we create a new environment called “Short Lived”:
Then configure it to expire deployments after 2 minutes. To do that, set the Delete Deployments After setting of the environment to the desired period of:
From now on, deployments that outlive their expiration period will be deleted, including past deployments in the environment.
Deployments expire after the set period since the last update was made to them. As long as you keep working on it, the deployment will not expire.
Our environment is ready. Let’s deploy the COVID-19 Tracker project as an example:
Now we wait… And:
When the time passes, Altostra automatically expires and deletes the deployment. The expiration event signifies that the delete event afterward was not triggered by a direct user action, but rather by an automated process.
That’s it. We can move on to the next task, worry-free of our deployment’s fate.
Summary
In this post, we’ve talked about one of the approaches development teams take when working on projects in parallel, and how Altostra helps the teams to do their work and move on with peace of mind.
In real-world setups, you’d see many deployments popping in and out of such environments. When we first implemented this feature for ourselves, the amount of junk in our AWS accounts went down drastically, and our environments became much cleaner.
