Welcome to this month’s roundup of product enhancements for Quali Torque.

If you’re not familiar, Torque is a platform engineering tool that simplifies and optimizes the orchestration and provisioning cloud-based and environments.

For an introduction to Quali Torque, watch this brief demo:

Here are this month’s updates:

Join our livestream: Preventing IaC updates from disrupting live dev & prod environments

Even routine updates to a single Infrastructure as Code (IaC) module can have unintended effects on other resources in an application environment, disrupting performance as a result.

Correcting these errors after they occur often entails lengthy debugging processes that holds up any work that relies on those environments and slows down the pipeline considerably.

On Tuesday, October 22nd, we’re hosting a 30-minute livestream that will show how to mitigate this risk by:

• Defining your Environments as Code based on your existing IaC modules and other application services
• Mapping the expected impact of IaC updates to other resources in your Environment as Code blueprints
• Automating detection and alerts for configuration drift and other updates to resources in your environments

Our monthly Torque Talk series provides the Quali community a chance to dive deep into common platform engineering use cases, see the latest functionality in Quali Torque in action, and submit questions for our experts to answer live on the call.

Join our Torque Talk livestream: Preventing IaC updates from disrupting live dev & prod environments

Connecting and Working with IaC Assets

Quali Torque leverages our users’ Infrastructure as Code (IaC) modules to make it easier to build and launch application environments. Once a user has connected a repository, Torque discovers those modules and turns the resource configurations within them into reusable assets which can then be orchestrated into templates for environments (based on simple AI prompts). For a deeper look at how Torque leverages IaC to create environment templates, check out this demo.

Recognizing the value of this platform approach to standalone cloud resources defined in IaC, we’ve updated Torque to provide a new dedicated interface for IaC assets.

Torque administrators can now share repository credentials across different Spaces (which are how user access is managed) so users can leverage IaC assets within multiple environments.

Once a user defines a repository, Torque automatically discovers those IaC assets and displays them on the new dedicated interface for IaC assets.

This allows administrators to distribute access to individual cloud resources via the self-service catalog within the Space, while also making them available to be used to orchestrate a more complex environment via Torque’s AI interface.

Moreover, these assets are readily available for deployment on any designated agent, significantly enhancing the efficiency of managing and updating IaC assets across repositories.

Mapping the Impact of IaC Updates on Environments

A common challenge among DevOps and IT teams who rely on IaC involves the downstream impact of an update to an IaC module upon the environments it supports.

Without a clear understanding of how those updates will affect the resources and environments that depend on them, DevOps and IT teams struggle to prevent any unexpected disruption.

Worse still, reacting to this disruption often requires extensive debugging that can hold up the work that relies on the performance of that environment.

Torque’s new impact mapping feature provides a comprehensive understanding of the dependencies among IaC assets, Torque Blueprints, and Environments. Prior to pushing an update or other change to an IaC module, DevOps engineers can now see the implications of those changes on Environments and Blueprints in Torque.

For instance, when modifications to a base Terraform file are needed, Torque’s impact mapping feature will identify which Blueprints are reliant on the asset in question.

Furthermore, Torque provides visibility into the live environments utilizing the asset, thereby facilitating informed decision-making regarding the update of these environments. This will make it easier to prevent unexpected changes to environments in Torque as the result of IaC updates.

To see this functionality in action, join our 30-minute livestream on Tuesday, October 22, that will demonstrate how to prevent IaC updates from disrupting live environments.

Join our Torque Talk livestream: Preventing IaC updates from disrupting live dev & prod environments

Workflows in the Self-Service Catalog

In Torque, Workflows represent stateless automation processes that were previously bound to specific environments.

Typically, Workflows are valuable in the context of day-2 operations, by simplifying and/or automating the execution of routine actions, such as adding or removing a disk from a VM within a live environment.

In a recent update to Torque, we’ve extended this functionality to allow Workflows to be defined independently of any specific environment and included in the self-service catalog.

This makes it easier for users to execute workflows for stateless scenarios—akin to the deployment of Blueprints—without necessitating a managed environment.

LocalStack Integration

To support our users who rely on LocalStack to emulate cloud resources for local development purposes, we’re recently introduced a new integration enabling Torque users to define a LocalStack agent and use the same IaC assets to run infrastructure across various deployment locations.

For instance, a Torque Blueprint containing an AWS S3 bucket defined via Terraform can initially be deployed on a developer’s local machine using LocalStack, and can subsequently be deployed to an AWS development environment.

GCP Cost Collection

Torque’s role as the platform from which all cloud infrastructure is provisioned enables it to track, calculate, and attribute cloud cost consumption based on the resources deployed and runtimes set by the user.

This means that:

• End users can see an estimated cost of each environment they launch via the platform prior to deployment, increasing awareness of the financial impact of their environments
• Administrators and leadership can see costs attributed to users, teams, clouds, environments, and other variables based on real-time deployment
• Admins can set policies and workflows to prevent wasteful cloud resource consumption, such as idle resources, over-sized instances, or redundant infrastructure running concurrently

We’re pleased to extend support for collecting actual cost data to Google Cloud Platform (GCP) in addition to AWS and Azure.

These capabilities are especially valuable for teams that work across multiple cloud platforms. Our support for GCP enables those teams to establish real-time visibility into cross-cloud cost consumption.