For software organizations, the ability to demonstrate, enable, and train customers on functionality has a direct impact on overall success.
One of the most common barriers to this process is the ability to spin up temporary environments to support software demos, training, and proof-of-concept (POCs) deployments for customers.
While this level of customer support is equally as critical as the software development lifecycle, the technology supporting it often pales in comparison to that provided to development teams.
As a result, the solution engineers, architects, and technical onboarding engineers responsible for meeting customer needs face limited options:
- Submit a ticket to IT or DevOps teams and hope that the environment is delivered in time and configured correctly to support the customer engagement
- Provision the environment independently based on previously used configurations that are probably stored on a colleague’s laptop
While this undoubtedly causes frustration for the teams executing the demos and POCs, it’s a sign of a much larger problem for software organizations.
How many demos and POCs are delayed due to inefficient or incorrect configuration of the environment? How many new customers have you lost after a poor training experience during onboarding? How does your team know whether the demo environment can support the latest functionality available in production?
We’ve seen real-world examples where limited access to these types of environments leads to longer sales cycles, slower growth, and higher customer acquisition costs.
In this article, we’ll walk through some example customer use cases where Quali Torque has helped to accelerate and enhance customer acquisition and onboarding with a self-service portal for demo, training, and POC environments.
Step 1. Create reusable definitions of demo environments
The bottleneck to access software demo, POC, and training environments stems from a simple fact of modern software—the infrastructure needed to support application performance is becoming increasingly complex.
For example, a standard customer-facing demo or training session will typically require multiple layers of infrastructure to support, including the foundational servers and data centers, cloud-delivered VMs and storage services, and application services like database and Platform as a Service components.
Provisioning this environment requires defining the parameters for each service and dependencies between each to generate the application functionality needed for the customer engagement.
Even if each cloud service is defined in an Infrastructure as Code (IaC) module like Terraform, CloudFormation, or Ansible, orchestrating the environment will require manual coding every time it’s needed.
This redundant, manual process is typically the most common cause for delays in executing customer demos and training.
Our users solve this by defining the configuration of all infrastructure components needed to run the demo environment in one reusable file. This works by connecting to the source repository for all IaC and infrastructure configures, discovering the cloud resource definitions within them, and generating a new file leveraging those resources and defining the configuration of the environment.
We call this environment definition a “blueprint.” With your blueprints defined, your teams don’t need to manually orchestrate an environment in order to run it. The blueprint defines the deployment plan for the environment.
Step 2. Provide a self-service platform to launch demo environments on-demand
Another benefit of the build-once-deploy-repeatedly nature of the blueprint model is the ability to provide self-service access. If the blueprint can be used to launch environments repeatedly, why not let your teams initiate that launch on demand?
Quali Torque comes with a native self-service catalog that displays all environments that are available for the teams that need them. Once an infrastructure expert has validated that the definition in a blueprint is working correctly, they can “publish” it to the catalog where anyone with access can launch it.
Launching an environment requires no manual coding. As part of the process, users can:
- View a description of the environment and instructions on how to use it (as defined by an administrator)
- See how long the environment will take to launch (typically a matter of minutes), as well as whether their colleagues are currently running the same environment
- Set a duration for the environment, after which Torque will terminate it automatically
- Add collaborators on their team so anyone else who needs access can use the environment
- Click “launch” to initiate the deployment of the environment
Watch a brief demo to see Quali Torque in action
User-level permissions allow solution engineers or technical support teams to launch environments while denying access to create or modify blueprints. Meanwhile, Quali Torque executes all cloud account credentials, keys, and certificates automatically when initiating the launch of a cloud environment. This removes the need for your teams to share account credentials in order to access to cloud environments.
The objective is to create an easy, secure way for your teams to run the environments they need, while preventing them from running anything that they’re not allowed to.
In one case, we’ve seen Torque users turn an environment orchestration process that took several days into a 12-minute, one-click launch process.
Step 3. Monitor activity & configurations continuously
When talking with customers about this approach, we typically hear a few common concerns about the implications of this self-service model:
- Quality: A self-service platform for cloud environments makes it easier for your teams to run a large volume of environments—all of which need to be maintained to prevent failures or bugs that could affect user experience in a customer demo or POC.
- Cost: While RBAC may help with the configuration of cloud resources, how do I know my cloud bill won’t skyrocket simply due to the increase in volume of environments?
Over the years we’ve rolled out functionality to address these challenges.
Since all blueprints are based on the cloud resource configurations that the team built in IaC or Kubernetes, Torque can monitor the deployment of all cloud environments as well as the state of all configuration files supporting them.
If an environment fails to launch, the platform shows the cause of the failure so the engineer can correct it quickly. Similarly, if a resource configuration drifts from its initial state, Torque will alert the environment owner about the change and allow them to reconcile it immediately.
And since all environment deployments are based on a central blueprint, admins can push changes at the blueprint level with the peace of mind that all launches will adhere to the latest updates. That means no stale or out-of-date environments for demos or other customer-facing engagements.
To manage cost efficiency, Quali Torque provides visibility and governance to help admins identify, eliminate, and prevent waste continuously.
Unnecessary deployments and runtimes are a common cloud cost management challenge. Since Torque initiates the creation of all cloud resources supporting an environment, it can also calculate the cost of those resources based on the configuration and runtime of the environment.
The added benefit of associating all activity to an environment owner allows admins to see who is responsible for all cloud costs at any given time. This includes a view of cloud costs across the whole team, as well as a real-time view into which cloud environments are actively running.
One easy way to cut down on unnecessary deployments is to look at all actively running environments. If, for example, several people are running the same cloud environment at the same time, you can ask them to collaborate on just one of those.
At scale, eliminating concurrent environments can have a big impact on cloud costs. To prevent this, admins can set a policy to limit the number of concurrent environments for a specific team. Torque will deny the launch of an environment if it exceeds the limit set in the policy.
Policies can also help to eliminate zombie infrastructure, or cloud resources that are left running long after their workloads have ended. Setting a policy for maximum runtimes instructs Torque to deny the launch of any environment configured to exceed that runtime. Similarly, workflows allow admins to set a daily schedule to automatically shut down all cloud resources for a specific team at the end of the workday—preventing anything from running when it’s not needed.
Learn more: Sample cloud governance policies you can start using today
To help identify waste, Torque analyzes all actively deployed cloud environments for signs of activity. Any cloud resources that appear to be inactive are flagged as “Idle” and added to the Inactivity dashboard, along with the expected cost-savings from terminating those resources. This dashboard allows admins to review and prioritize savings opportunities based on both the impact on budget and how it may affect the team it supports.
Through these measures alone, one customer reduced cloud spend for its customer-facing demo environments by more than 50% in the first three months using Torque.
To see how this approach might work your team, book a demo of Torque today.
