Starting in the late aughts, the DevOps movement promised us smoother operations and a faster operational tempo by merging development and infrastructure roles—"you build it, you own it." Companies have embraced automation, moved away from manual configurations, and broken down silos between teams. If widespread acceptance of DevOps practices is the metric, then today the revolution isn't just well underway: DevOps has won.

So why is everything still so difficult? Even today, at too many companies, whenever you're handed an entirely new project you find that the time it takes you to move from ideation to code and from code to deployment probably hasn't decreased very much from the dinosaur days when everything required a scoping meeting and a dozen manual steps for someone else to set your environment up for you. 

Does this mean DevOps was a flawed approach?

I don’t think so, but it does expose a dirty little secret about DevOps: developers still don’t really own every part of their projects. The reality is that organizational silos remain, they’ve just been hidden by automation tooling. 

Even if everyone is making pull requests to the same YAML file, familiarity and comfort with the infrastructure that file abstracts varies wildly in ways that are very material to your ability to work with it in a production environment. This means that developers still can't really serve themselves without a lot of hand-holding and support from Ops teams. Because this is happening in Git rather than email, we pretend that it isn't manual work. But it is.

People are starting to acknowledge this. When Tempest was in London at Kubecon a couple weeks ago, we heard again and again about developer self-service, about how important it was to give dev teams tools to handle more things on their own without involving other teams. 

And obviously, here at Tempest, we agree. A big part of why we started Tempest is we’d all had the experience of not being able to do things on our own at some of the biggest and most technologically sophisticated companies in the world. 

But I’d argue it doesn’t go far enough. The only way to really deliver on the promise of DevOps is to change the way we do developer self-service—to make it possible for developers to actually spin up the resources they need without any outside help. That’s what we’re building at Tempest, and we think it’s the natural evolution of DevOps practices. 

We don’t just need developer self-service. We need true one-click deployment for critical infrastructure.  

Why automation doesn't necessarily equal autonomy

At first glance, you might think infrastructure in a DevOps environment is already automated and self-contained. Infrastructure as Code (IaC) scripts make spinning up new environments look straightforward, giving the impression that developers are fully autonomous. However, this is rarely the case in practice. Developers often can't launch new infrastructure without significant manual support, creating frequent delays and bottlenecks.

In reality, every infrastructure project inevitably encounters scenarios that existing scripts don't fully cover. Whether it's configuring new security settings, provisioning additional cloud resources, or handling unique application dependencies, developers quickly discover they still need assistance from Ops teams. Even small adjustments can require back-and-forth communication, clarifications, and ultimately waiting on Ops to manually approve or adjust resources.

This might seem like a small amount of friction, but it’s really not. Even if it takes “just” a 30 minute kickoff meeting to get started on a project, finding a time that works for everyone’s schedule can delay start by days every time. If you need to include a manager or someone higher up that tends to have their calendars booked solid, that can easily stretch into weeks. 

This dependency recurs throughout project lifecycles. Initial deployments, incremental changes, scaling resources—each stage reintroduces similar challenges. What appears as fully "self-service" infrastructure actually involves hidden layers of manual effort. These delays accumulate, forcing developers into frustrating holding patterns that reduce agility and slow innovation. Without a truly independent and intuitive platform, infrastructure self-service remains an illusion rather than reality.

Scripting operational tasks sped up infrastructure management for ops teams but shifted bottlenecks rather than eliminating them. Developers now wait in queues, dependent on ops to trigger automated resource provisioning. These queues mask organizational silos—each specialized team maintains its own ticket backlog, leading to frequent clarifications and context-switching in Slack. Dashboard metrics might show fewer open tickets but hide cumulative delays developers face.

Git-based configurations frequently used for Terraform or Kubernetes YAML also assume widespread infrastructure proficiency, which isn't realistic. A single misconfigured line can fail deployments long after code review, turning these reviews into extended training sessions and draining senior engineers' time.

The transition from traditional Ops roles to "DevOps" often didn't fundamentally integrate development and operations. Despite new job titles, everyday workflows stayed unchanged, with developers still relying on tickets to trigger pipelines. Hiring shifted from infrastructure engineering to "DevOps Engineer," but organizational structures and incentives didn't adapt, leaving cultural divisions intact.

What true one click deployment looks like

Real self-service automation fundamentally transforms how infrastructure and deployments are managed. Imagine a scenario where a developer needs a new microservice deployed to a Kubernetes cluster. Instead of filing a ticket and waiting, they simply select a predefined template labeled "Deploy microservice" from a user-friendly interface. After a few quick inputs specifying the service name, resource needs, and environment, they press a single button.

The automation instantly checks compliance, security policies, and available resources. It provisions the required environments, configures necessary databases, and sets appropriate IAM roles—without manual intervention. No handoffs, no delays.

Ops teams benefit enormously. They no longer act as gatekeepers, manually approving or executing each request. Instead, their role shifts to maintaining robust, automated policies, guardrails, and templates. Infrastructure issues trigger automated alerts directed to specific responsible teams, clearly documented with actionable insights, eliminating traditional escalations.

This approach provides developers genuine autonomy and efficiency, while Ops teams focus strategically on stability and continuous improvement rather than operational firefighting. It’s a win-win scenario that finally realizes the true promise of DevOps.

How Tempest delivers on that promise

We built Tempest precisely to realize that level of one click developer experience. And we think we've gotten pretty close!

But putting self-service in a developer portal isn't exactly a new idea—many dev portals say they do this, and the ones that don't are all trying to build that functionality in. So at this point you might wonder what makes Tempest different.  

The answer is that Tempest begins with orchestration rather than a service catalog. Many platforms start by building comprehensive service catalogs but soon find this merely highlights problems without solving core workflow and provisioning issues. Developers see available services but still encounter numerous manual provisioning steps.

Tempest flips this by prioritizing orchestration from day one. Developers use straightforward workflows built directly into Tempest to easily define and deploy resources. Simply select your resource type, configure the necessary details, and execute—Tempest manages all underlying complexities, including dependencies, execution order, and cross-service integrations.

This orchestration-first model naturally generates an automated, accurate service catalog. Every new resource provisioned through Tempest automatically populates the catalog, offering visibility without extra manual effort. Unlike typical methods requiring complex, brittle scripts across multiple systems, Tempest’s approach integrates automation into provisioning, genuinely eliminating manual bottlenecks for both developers and Ops.

Crucially, we do this in a way that doesn't require starting over from scratch for companies that are already well along in their DevOps journey. If you already have a lot of infrastructure as code automations built out in Terraform or some other service, you can import them into Tempest to create fully composable elements that you can use to create entire workflows for nearly anything your devs require. On the dev side, things really do become about as simple as "push button, receive resources, start coding.”

Wrapping Up

DevOps significantly transformed software development and operations, but it didn’t fully resolve the bottlenecks created by organizational silos and manual processes. True developer self-service represents the next evolution, ensuring developers have genuine autonomy in provisioning resources without hidden delays or manual intervention.

By prioritizing orchestration from the outset, Tempest effectively addresses these persistent issues. Developers gain an intuitive, automated workflow that removes complexity and delays, while Ops teams shift from manual execution to strategic oversight. Ultimately, Tempest fulfills the original promise of DevOps: empowering developers to innovate quickly and efficiently, unburdened by operational friction.