Reducing Infrastructure Requests From Hours to Minutes

At TRADE IN TECHNOLOGY, I owned an infrastructure and cloud request platform as its main developer and architect. Before we built it, the company’s support team and clients sometimes waited hours for something that only took a few minutes to provision. The person requesting the resource had to explain what they needed, somebody collected the missing information and then the request waited until the infrastructure team had time to execute it.

The commands weren’t really the slow part. Most of the time was spent between the request, the clarification and the moment when somebody was available to do the work. There were also details that lived mostly in people’s heads, like which defaults were safe, what needed approval and what to check when one of the steps failed.

The First Workflows

We started with procedures that the team already performed regularly and understood well enough to automate. I worked with TypeScript, NestJS, Python, Ansible and React to turn more than 10 of them into reusable workflows. The platform collected the information needed for each request, validated the input and executed the automation while showing the current status to the person who requested it.

Building this involved more than putting a web interface in front of some scripts. I needed to understand what the infrastructure team checked before running each procedure and which choices could be safely exposed to another person. Some actions needed approval, some needed better defaults and some unusual cases still had to go to the DevOps team because the correct decision depended on the situation.

The backend coordinated the request and kept its state, while Python and Ansible handled different parts of the infrastructure automation. I didn’t want a browser request to stay open while a longer procedure was running, so the person could leave the page and return without losing what had happened. The platform needed to know if a workflow was waiting, running, completed or stopped in a specific step, and the person responsible for support needed to see more detail than the person who requested the resource.

Permissions were part of each workflow as well. A developer asking for a common resource in a known environment was different from somebody changing a production configuration or requesting access to something sensitive. We didn’t try to solve this with one global role. The platform checked who could request, approve and execute the relevant operation, which allowed us to automate the common paths without making every available command accessible to everyone.

Using the Platform

Developers and clients could use the platform without knowing every command behind the request. We still exposed enough information for them to understand what was happening and, when something failed, the result needed to be more useful than the raw output of an automation script. This part took more work than I first expected because the same terminology that was obvious to the infrastructure team wasn’t always obvious to somebody who only wanted a resource for their application.

The platform also kept a history of the requests, which helped the support and infrastructure teams see what had already happened without reconstructing the process from messages. The normal requests no longer needed a conversation every time, while the team could still take over when a case needed human judgment.

Failures were one of the reasons that history mattered. An automation could complete the first steps and then fail because a provider was unavailable or because the existing environment was different from what we expected. Running the complete workflow again wasn’t always the correct response. We recorded the completed steps and relevant output so the infrastructure team could decide whether to continue, compensate for a change or start a new request. Showing only a red status would have moved the work into the platform without making support any easier.

The React interface changed as we watched people use the workflows. Some fields that seemed obvious to us needed examples, and some options caused enough confusion that a safe default was better than another decision for the user. We also added status and feedback where people otherwise sent a message asking if the request was still running. These weren’t large features, but they affected whether somebody trusted the platform enough to use it instead of returning to the old support channel.

From an Internal Platform to a Product

The result was easy to notice inside the company and for our clients. A request that used to move through messages and wait for somebody’s availability could now be completed in minutes or seconds, using the same validation and sequence every time. The platform worked well enough internally that we later shipped it as a product for clients.

Turning it into a product introduced differences that didn’t exist when everyone using it worked inside the same company. Clients had their own environments, naming rules, permissions and procedures, so we couldn’t keep adding special cases directly to one workflow. We separated the common orchestration from the configuration that changed for each client and made the available operations depend on what had been set up for that environment. This took more time than the first internal version, but it allowed the same platform to support different clients without pretending they all operated in exactly the same way.

It also changed how we handled errors and documentation. Internally, the person investigating a failure could often talk directly to the engineer who wrote the automation. A client couldn’t depend on that. The workflow needed clearer messages and the support team needed enough context to help without reading the source code or asking me what a particular Ansible task meant.

I liked working on it because I was involved in the architecture, backend, automation and interface, but also because people noticed the difference without us needing to explain a technical metric. They requested something and received it much sooner. For this project, that was the clearest result we could have.