One of the most common challenges for our customers is granting simple access to cloud services.
The developers and other staff who need to deploy cloud services typically lack the infrastructure skills and expertise to configure them correctly. Unfettered self-service creates the risk of misconfigurations—one of the leading causes of data breaches in the public cloud—and wasted costs due to zombie infrastructure.
So all requests go to the few operations and IT people who know how to configure cloud resources to prevent these risks.
This is where operational bottlenecks form.
Those with the skills to provision cloud infrastructure end up overburdened with simple requests, resulting in delays for those who submitted the requests and just want to get their work done.
Here we’ll explain how we’ve helped our customers democratize access to public cloud services while mitigating the risk of misconfigurations.
Step 1. Scale your cloud environment
To help minimize redundant provisioning of cloud infrastructure, Quali Torque imports the configurations in your Git repository—including those defined in Infrastructure as Code and Kubernetes tools such as Terraform and Helm—and defines a ready-to-run environment based on that infrastructure.
In this example, we have an Amazon EC2 instance defined in Terraform, which is used to power a WordPress website.
To create this environment, an admin would simply enter the URL of the Git repository where the Terraform file is stored and Quali Torque will automatically discover the Amazon EC2 configuration.
After discovering the infrastructure, Quali Torque will automatically define the inputs and outputs of the environment running on that infrastructure, i.e. the WordPress website, in a new YAML file.
That pre-configured YAML file can now be used to execute the Terraform plan as frequently as needed.
Step 2. Set role-based access controls for staff to launch via self-service
Now that the environment is pre-configured, the DevOps team no longer needs to configure it every time that a developer needs it.
Therefore, the developer doesn’t need to request it. So DevOps can give them self-service access to launch it.
Once an admin has generated a blueprint for an environment in Quali Torque, they can publish it to a self-service catalog where other users can launch and operate the cloud infrastructure via self-service.
Role-based access controls prevent the developer from modifying any of the infrastructure. Automatic drift detection will notify the admin about any unexpected changes to the configuration of the Amazon EC2 service, giving further peace of mind that all infrastructure deployed is up to date.
Step 3. Set a maximum duration to prevent zombie infrastructure
One of the concerns about democratizing cloud access is zombie infrastructure—or cloud instances that are left running long after they’re supposed to.
Our users prevent this with a duration for every cloud deployment. As part of the self-service deployment process, the developer needs to set a duration from a picklist managed by the infrastructure admins.
After that duration has expired, Quali Torque will automatically terminate all cloud resources defined in the environment.
The admins can set the maximum duration allowed in the picklist and have the ability to manually terminate any environment on-demand.
Step 4. Set tags to apply to cloud services automatically
Tagging cloud resources is an often-overlooked step that can have a massive impact on cloud cost reporting and optimization.
Cloud service providers’ native tools and FinOps solutions rely on tags applied to cloud instances to perform showback or chargeback for cloud costs. For example, tagging cloud instances with “Testing” will allow the team to group all line items with that tag to allocate costs to testing functions.
However, this becomes challenging as the number of staff with cloud access becomes larger. Missing tags, typos, and inconsistent formatting results in blind spots that leave an incomplete picture of cloud costs.
For our users, admins can set the tags which appear in a picklist as part of the deployment process, thereby requiring tags for all infrastructure deployed and eliminating the risk of manual error in applying the tag.
Step 5. Allow developers to perform Day-2 actions on cloud VMs
Another common frustration for the IT and operations teams we work with involves simple operations for cloud VMs.
Any time a developer needs to restart or deploy a cloud instance, they need to ask someone with cloud access to carry out that task on their behalf.
Quali Torque allows the end user to perform Day-2 actions on the cloud services that they launched from the self-service catalog.
Through this approach, we’ve democratized self-service access to the cloud for the staff who need it, eliminated redundant tasks for the infrastructure expert, and increased governance over how that infrastructure is configured and operated.
Step 6. Set a schedule to automate launch and teardown for your cloud instances
Some of our customers take this approach one step further with automated workflows for their cloud services.
Let’s say, for example, that the teams who use the Amazon EC2 instance in question need it every business day, but do not need it to work outside of a specific set of hours.
In a traditional approach, supporting that schedule requires manually provisioning, launching, and then shutting off that instance every day.
Our users automate that with pre-scheduled workflows.
Administrators can set a workflow to power-on the Amazon EC2 instances at a specific time on specific days—such as Monday through Friday. Another workflow can schedule those instances to power-off at a specific time on those same days.
As a result, the team that needs infrastructure can access it via self-service and find that it’s already operational when they do, and the infrastructure admins know that the cloud service is configured correctly and will shut down after it’s no longer needed.
To learn more, watch this brief demo of Developer Self-Service with Quali Torque.