In Flexera’s 2024 State of the Cloud report, respondents estimated that about 27% of total spend on cloud infrastructure is waste.
While that amount of wasted budget could be staggering, it’s not even the whole story. When considering the amount of time and resources that DevOps teams spend orchestrating and maintaining unnecessary infrastructure, the impact of this type of waste is far greater than what shows up on the cloud bill.
One of the most effective ways to eliminate this kind of waste is by cutting down on redundant, concurrent cloud resources. That means finding areas where separate engineers or teams are deploying identical cloud resources for unique purposes.
In practice, creating shareable cloud infrastructure and environments eliminates the wasted time and cloud costs.
This article will show you a few ways that how our users accomplish this.
1. Establish a single platform for your teams to provision resources via self-service
First, it helps to understand how our users manage cloud infrastructure.
Qualis Torque is a central platform from which users provision multi-cloud infrastructure. To accomplish this, Torque creates an inventory of the user’s cloud assets by discovering the configurations in the user’s Git repositories and public cloud accounts, creating reusable modules for all infrastructure and environments, and providing an intuitive experience for provisioning them via self-service.
This includes a self-service catalog where users can find and provision IaC modules as well as the pre-configured Environment as Code blueprints created via Torque.
For example, let’s say a user needs to run a Kubernetes cluster to support a development, staging, or other type of environment. A Torque user would visit the self-service catalog in Torque, search or filter through the available resources in the catalog, and launch the cluster they need based on a pre-configured blueprint that an administrator added to the catalog.
Torque’s self-service provisioning experience allows admins to eliminate the complex and sensitive inputs required to run infrastructure via traditional IaC tools, including variables and security credentials, so more users can deploy the resources they need on-demand. Role-based access controls prevent anyone from modifying those resources without permission.
This helps to reduce ticket requests to DevOps teams for resources like development environments, as well as the redundant orchestration and provisioning required to deliver them.
Another advantage of this approach is that it provides a single point from which users can monitor resource deployments. Torque’s Operation Hub provides visibility into each resource deployed along with the users responsible for deploying them.
This provides visibility to understand whether multiple users are running identical resources concurrently, which enables DevOps and other engineers to intervene to find ways to eliminate waste.
2. Invite collaborators to access environment outputs once live
One way to eliminate waste proactively is by sharing access to environment outputs.
For example, multiple users may run the same environment to support different work. One user may need to run the environment for development, while another may use it to demonstrate functionality to a customer or for internal training. At scale, that kind of redundant usage could add up to significant waste on the cloud bill, even if each workload is considered mission-critical.
To prevent this, Torque users can invite collaborators when provisioning a resource or environment via the catalog. These collaborators are notified when the environment output is live and can access it via self-service. This allows DevOps teams to run a single cloud environment for multiple use cases.
However, some teams may still encounter cases where collaboration doesn’t serve the team’s needs.
3. Make infrastructure resources available as inputs for new environments
To refer back to our earlier example, let’s say multiple users need to run the same Kubernetes cluster to support entirely different environments.
For many teams, this kind of redundancy is considered a standard cost of operations. If each environment that relies on that cluster is mission-critical, then the team will need to run each one independently.
Torque addresses this by enabling users to make a resource available as an input when provisioning a new environment. Those with administrator access can provision the resource and choose to “publish” it for use as an input for other environments.
This makes any single resource, such as a Kubernetes cluster, shareable to support unique workloads. In the self-service provisioning process, Torque users can set the environment inputs via a user-friendly form. Administrators can choose to set default values so that users don’t need to make any changes when launching an environment. But the administrator can also provide a simple pick-list showing the options users can select for their input.
When publishing the output of an environment, an admin can make it accessible as an input for users provisioning new environments. Through this approach, users only need to select that option from the pick-list as they launch their environment.
This approach eliminates the redundant orchestration and provisioning for complex resources, while also helping to cut out wasted cloud cost due to concurrent resource deployments.
To explore this option for your infrastructure, book a demo of Torque.