For years, our users have leveraged Quali Torque to eliminate redundant infrastructure provisioning and environment orchestration with reusable definitions of their cloud environments.
In our platform, environments are defined in YAML files, which we call “blueprints.” Creating a blueprint allows an administrator—typically an engineer in the DevOps, IT, or platform engineering team—to eliminate cases where they need to provision the same environments repeatedly every time someone needs them.
Once defined, admins can publish blueprints to Torque’s self-service catalog, where the teams they support can launch them on-demand.
This removes barriers that slow down the teams responsible for orchestrating environments as well as those who need access to environments to get their work done.
In our work with our customers, we’ve thought a lot about what we can do to take the next step in this evolution.
The result is Torque’s new Designer Canvas with access to out-of-the-box environment resources.
Leveraging out-of-the-box IaC & Kubernetes to design environments
To help our users create blueprints, Torque now comes with out-of-the-box Infrastructure-as-Code modules and Kubernetes resources.
This means that users looking to design an environment can find pre-configured infrastructure and application services to help support common use cases, regardless of whether they’ve already built those configurations in a separate repository.
Meanwhile, Torque will continue to support user-provided IaC and Kubernetes assets by discovering and leveraging the resources in the user’s repository.
When combined with the Quali-hosted agent for executing the automation defined in your blueprints, Torque users can get environments up and running faster and more easily.
This lowers the barrier to environment orchestration for those looking for resources to get started.
But it’s just one part of our efforts to simplify the orchestration process.
No-code environment design using the Designer Canvas
While Torque’s blueprint model made it easier for infrastructure experts to orchestrate environments, the blueprint design process often required some level of modification of the code leveraged from the user’s repository.
As we looked for ways to better support our customers, we wanted to extend that ease of use to more people in the organization.
One way to do that is to automate the generation of the blueprint YAML based on the administrator’s inputs.
Today, administrators have the option to create a blueprint using the platform’s new Designer Canvas.
In the Designer Canvas, admins can access all infrastructure and application services needed to support environments, including those discovered from the user’s repository and the community assets that come out-of-the-box for all Torque accounts.
From the Asset Library within the Designer Canvas experience, admins can search for the asset they need and click “Add” to bring it into their blueprint design.
To set dependencies, admins can click and drag the arrows to define how individual assets will work together to launch the environment.
A user-friendly form allows admins to set the inputs for each asset, such as the parameters for public cloud resources or the pipeline and account for the CI/CD tool.
During this no-code process, Torque automatically generates a new YAML file that will serve as the blueprint for this environment.
Once defined, admins can operationalize this environment in various ways:
- Publish to Torque’s native self-service catalog, where those with end-user permissions can launch on-demand
- Integrate with developer tools and platforms like Jenkins or Spotify Backstage so developers can access them without straying from their day-to-day work
- Add the blueprint YAML to a repository so their users can launch and manage it in a GitOps approach
Administrators can still choose to create and modify blueprints via the YAML file. This no-code option does not take away functionality that others may prefer—it just lowers the barrier to creating cloud environments by providing a simplified, no-code option.
Enforcing guardrails over cloud environment deployments
Some infrastructure experts might be reluctant to allow more people to design environments—and for good reason.
In theory, empowering more people to configure cloud environments could increase security, performance, and cloud cost risk due to misconfigurations.
To prevent this risk, Torque allows admins to set custom policies for cloud resources, configurations, and operations.
Some common examples include:
- Allowed cloud resources, instance sizes, configurations and regions: These policies ensure all environments are launched with the proper cloud resources.
- Maximum environment duration and expected cost: Since Torque requires a pre-set runtime for all environments, the platform can enforce rules based on the duration and expected cost of the environment that a user attempts to launch.
- Limit for concurrent environment deployments: To prevent users from running too many cloud environments simultaneously, this policy sets a limit on how many environments their users can launch.
Since Torque initiates the creation of cloud resources defined in the blueprint, the platform can monitor the configurations in all blueprints and deny the launch of any environment that violates these policies.
Even if a blueprint designer violates a policy, Torque will prevent it from going live and require a correction.
With this approach, Torque admins can comfortably democratize environment design to more users.
To see this process in action, watch this brief demo:
To see how this approach can work for your environments, book a personalized demo.
