Some of the environments our customers rely on can be very expensive in terms of cloud costs.
Even when these costs are justified by the mission-critical services they support, their deployment activity typically has room for improvement in efficiency.
For example, we work with a team of engineers who are responsible for delivering environments to support software demos. Since their priority is executing high-quality software demos when needed, they often deploy new environments repeatedly—even in cases when an existing environment would suffice.
This is a common blind spot for those who rely solely on Infrastructure as Code (IaC) to provision cloud infrastructure supporting their environments. Without visibility into who is running cloud infrastructure or guardrails to prohibit that activity, these teams have little recourse to eliminate this waste.
Here we’ll show how to implement guardrails to limit the volume of cloud environments that your teams run concurrently.
Step 1: Create and distribute templates for your cloud environments
The first step is to remove the need to provision cloud resources for your environments.
Our customers accomplish this by importing the cloud resource configurations defined in IaC into “blueprints” in Quali Torque.
These blueprints are YAML files that define all the cloud resources—regardless of the IaC tool used to define each one—as well as the dependencies and outputs needed to support the use case. And since they’re based on the IaC configurations in your Git repository, you don’t need to create new scripts or modules. They use your existing infrastructure components to make a repeatable template of the complete environment.
Once an admin determines that a blueprint is ready to use, admins can “publish” a blueprint to the self-service catalog in Quali Torque. This allows those with end user permissions in the platform to view and launch the environment defined in the template.
Publishing a blueprint also makes it available to integrate with CI/CD and other developer tools.
When a user deploys an environment, they are listed as the owner. This makes it easier for admins and other teammates to track who is using which environment, and for what purpose.
Step 2. Track deployments to understand your teams’ needs
Once your teams start running their cloud environments via the platform, you can start to see who has deployed which environment at which point.
This will allow you to understand who may be running multiple concurrent environments and understand whether they may be able to use cloud resources more efficiently. If, for example, the same owners are running multiple environments concurrently, you may want to set policies that encourage them to use those which are already available.
Step 3. Set a policy to limit concurrent deployments per user
Deploying your cloud infrastructure via Quali Torque allows you to set rules for how your teams use it.
One example is a limit on concurrent deployments per user. Only admins have permission to set these policies and can customize them based on their end users’ needs. In the example below, the policy limits users to running no more than 3 concurrent environments within a workspace (where users access the infrastructure within Quali Torque).
To further customize this policy, admins can choose to apply it only to certain workspaces. This allows admins to limit concurrent deployments for those on one team while loosening the restrictions on another.
If you have end users who access multiple workspaces in Quali Torque, you can set a separate policy that limits the total number of concurrent environments across your entire account.
This adds a separate guardrail to prevent users from launching excessive concurrent environments in multiple spaces.
This is just one example of cloud governance policies that our users have embraced. Learn more about how Quali Torque supports cloud governance here.
