Skip to main content

Service Management use case

Infrastructure provisioning self-service software

Infrastructure provisioning self-service lets teams order a VM, cloud account or storage from standard options, checks the request against policy and budget, and builds it through vSphere, Terraform or cloud APIs once approved. USDA's National Information Technology Center went from three weeks to 30 minutes per server with Kinetic.

Book a working session

USDA Server provisioning went from three weeks to 30 minutes, with a proof of concept on existing systems in 4 days. Read the USDA case study

From request to running server

  1. Experience layer

    A portal where teams request servers, cloud accounts and storage from standard sizes and images, and see when each one is ready.

  2. Workflow layer

    Requests are checked against naming, sizing and budget rules, routed for approval by cost and environment, built through your provisioning tools and recorded in the ITSM.

  3. Integration layer

    Builds VMs in vSphere, runs Terraform workspaces, calls the AWS, Azure and Google Cloud APIs, adds the requester to Active Directory groups and records the result in your ITSM.

    • VMware vSphere
    • AWS
    • Microsoft Azure
    • Google Cloud
    • Terraform
    • Active Directory

AI in infrastructure provisioning

AI matches requests to standard builds and flags anything over policy or budget. Production, high-cost and non-standard builds are approved by people.

What AI does

  • Matches a free-text request to a standard build option
  • Flags requests that exceed policy or budget
  • Summarizes the request and its cost for the approver

Decided by people, not by AI

  • Non-standard or high-cost builds
  • Production environment requests
  • Policy exceptions

Three weeks for a VM

At USDA’s National Information Technology Center, a developer who needed a server emailed the infrastructure team. The request went into a spreadsheet behind every other open request. When a technician reached it, they built the VM in vSphere, updated Active Directory, coordinated with the cloud team and checked the configuration by hand. Average turnaround was three weeks, and the only way to go faster was more people.

That pattern is common wherever infrastructure is shared. The build itself takes minutes. The weeks come from the queue, the approvals and the handoffs between people who each own one console.

How requests run now

  1. A team picks a standard option. Small Linux VM in the development cluster, an AWS account in the sandbox organizational unit, 2 TB of file storage. The form asks for project, environment and cost center, and shows the expected monthly cost.
  2. Policy checks run before anyone approves. Naming conventions, permitted sizes for the environment, and the project’s remaining budget.
  3. Approval follows cost and environment. A standard development build can go through with no approver. Production, or anything over your threshold, goes to the manager and the platform owner.
  4. The build runs. Kinetic calls vSphere, a Terraform workspace or the cloud provider’s API, applies your tags and network rules, and adds the requester to the right Active Directory group.
  5. The record is written. A CI is created in your ITSM and linked to the request. The requester gets connection details, and the request shows who asked, who approved and what was built.

What USDA reported

After moving provisioning to Kinetic, the center reports server provisioning in 30 minutes instead of three weeks, and more than 75% of its business and service functions automated. Its proof of concept was built and demonstrated in four days, against more than a year to get started with the previous solution. The USDA case study has the details.

What you need first

Kinetic doesn’t write your infrastructure code. If builds are already scripted in Terraform or Ansible, connecting them is mostly configuration. If they are still done by hand in a console, script the first few build types before connecting them. Most teams start with their three or four most-requested builds and add others as they’re automated.

Once the portal exists, software provisioning and IT and digital operations workflows use the same request experience and approvals.

Results at USDA

Source: USDA case study

Provisioning time
3 weeks → 30 min
Services automated
75%+
Proof of concept
4 days

What you can build next

Once teams order infrastructure from a portal, software and routine operations work fit the same model.

Questions about infrastructure provisioning

Answered by Kinetic Data. Last updated .

  • Does Kinetic replace Terraform or our cloud consoles?

    No. Kinetic gives teams the request form and runs the approvals, then calls your provisioning tools to build the resources. Your infrastructure code, modules and cloud accounts stay where they are.

  • Can resources be decommissioned automatically?

    Yes, if you want them to be. Requests can carry an end date, and the owner is asked to extend or release the resource before it arrives. Released resources are torn down through the same tools that built them, and the asset record is updated.

  • How long does it take to get started?

    USDA's proof of concept took four days, against more than a year to get started with its previous solution. Timing depends on how many build types you start with and whether your provisioning is already scripted.

  • Can requesters see cost before they submit?

    Yes. Each standard option carries an estimated monthly cost, shown on the form and on the approver's screen. Requests that would exceed the project's remaining budget are flagged before approval.

Bring one process. Leave with a plan to build it.

Two hours with our team, at no cost. Bring one process that crosses your systems. We map it with you, show what Kinetic would build, and send you a written plan afterward.

Book a working session