Infrastructure Automation Platforms

Forrester has alternated between two names for this market. It was evaluated as Infrastructure Automation Platforms in Q3 2019 and Q3 2020, published as Infrastructure Automation in Q1 2023, and returned to Infrastructure Automation Platforms for the Q4 2024 edition, which is the current evaluation. Both names describe the same category.

Forrester's Q3 2019 evaluation of this market included HashiCorp among eleven providers. The Q3 2020 edition, published a year later with thirteen providers, did not.

By 2020, Terraform was well on its way to becoming the default way organisations provisioned cloud infrastructure. Whatever the reason for the absence, and Forrester's inclusion criteria and vendor participation policies both shape these lists, the effect is that the tool most widely adopted for a large part of this category's work was not in the field being scored.

That is a useful reminder about analyst evaluations generally. They describe the vendors competing for enterprise procurement in a defined market, which is not always the same thing as the tools engineers are actually using.

Two generations of the same problem

The vendor lists across this lineage divide into two eras, and the split is architectural.

The first generation is configuration management. Puppet, Chef, SaltStack, and Ansible were built for a world of servers that existed for years. You declared the desired state of a machine, the agent enforced it, and drift got corrected. The unit of work was a host, and the problem being solved was that thousands of servers configured by hand diverge.

The second generation is infrastructure as code for cloud resources. Rather than configuring a machine, you declare the infrastructure itself, networks, load balancers, databases, clusters, and the tool creates, changes, or destroys it to match. The unit of work is a resource, and servers became disposable rather than maintained.

That shift undercut the premise of configuration management. If a machine is replaced rather than repaired, keeping its configuration correct over time stops being the problem. You rebuild from an image and deploy again.

The category's vendor list reflects the transition rather than announcing it. The 2019 and 2020 fields are heavily populated by configuration management vendors, and what happened to them next tells the story.

The acquisition ledger

The Forrester Wave: Infrastructure Automation Platforms, Q3 2019 scored eleven providers against thirty one criteria: BMC Software, Chef Software, HashiCorp, Micro Focus, Microsoft, Northern.tech, Puppet, Red Hat, SaltStack, Turbonomic, and VMware.

The Q3 2020 edition, authored by Chris Gardner, scored thirteen against twenty six criteria, adding Canonical, Cisco, and Resolve Systems. VMware, Red Hat, Microsoft, and Cisco led, with Chef, Turbonomic, Resolve Systems, BMC, Puppet, SaltStack, and Micro Focus as Strong Performers, Canonical a Contender, and Northern.tech a Challenger.

Follow those names forward. SaltStack was acquired by VMware. Chef was acquired by Progress. Puppet was acquired by Perforce. Turbonomic went to IBM. Micro Focus went to OpenText. VMware went to Broadcom.

Of the thirteen vendors Forrester scored in 2020, a substantial majority are no longer independent companies.

That is not a market that lost. It is a market whose defining technology generation matured to the point where the products became components of larger portfolios, which is the normal endpoint for infrastructure tooling.

The Q1 2023 edition, authored by Naveen Chhabra, scored eleven vendors, with Puppet placing as a Strong Performer and taking the maximum score in configuration management and regulatory compliance. Forrester positioned it for companies needing strong configuration management and compliance capability, which is a precise description of where that generation of tooling retains its advantage.

Inside The Forrester Wave: Infrastructure Automation Platforms, Q4 2024

The evaluation scored eleven providers against twenty six criteria across current offering and strategy.

Red Hat placed as the Leader, taking maximum scores in ten criteria including infrastructure provisioning, configuration management, integration with configuration management databases, intra-tool analytics, supported deployment options, and community ecosystem. Forrester positioned it as a good all-round tool for organisations wanting to develop mature automation and integrate technology silos.

Two of those criteria deserve attention because they describe what enterprise buyers actually need and what pure infrastructure-as-code tooling does not provide.

Configuration management database integration matters because most large organisations have an asset inventory that other processes depend on: change management, incident response, licensing, and audit. Automation that provisions resources without updating that record produces an estate the organisation cannot describe.

Community ecosystem matters because the value of these platforms is largely in the content. A module that configures a specific database, network device, or cloud service correctly is work somebody has already done, and the size of that library determines how much you write yourself.

Integrating technology silos is the phrase that explains why the Leaders in this category tend to be broad platforms rather than specialists. Enterprise estates are not homogeneous. There is cloud, there is virtualisation, there is networking equipment, there is storage, and there is a mainframe somebody keeps promising to retire. A tool that automates one of those well and the others not at all leaves the coordination problem intact.

Drift is the problem nobody solved

Both generations of tooling share a failure mode, and it is the reason infrastructure automation programmes lose credibility.

Declarative infrastructure works on the premise that the code describes reality. Drift is what happens when reality changes without the code changing: somebody adjusted a security group during an incident, a support engineer resized an instance, a console change was never reflected in the repository.

Once drift exists, the tooling faces an uncomfortable choice. Enforce the code and revert the change, which may break something that was fixed manually for a reason. Or accept reality and let the code become fiction.

Most organisations arrive at a partial third option: the code describes most things approximately, everyone knows there are exceptions, and nobody trusts a plan output enough to apply it without reading every line.

Configuration management's continuous enforcement model addressed this directly, which is part of why Puppet retains an advantage in compliance scenarios where proving a configuration state matters. Infrastructure-as-code's plan-and-apply model is better for creation and weaker for ongoing assurance.

The practical consequence is that organisations serious about this run detection continuously rather than assuming the repository is authoritative, and treat unexplained drift as an incident rather than as a tidiness issue.

What agents change

The current development is agents writing and applying infrastructure changes, and the risk profile differs from agents writing application code.

An application defect is caught in review, testing, or at worst in production behaviour that can be rolled back. An infrastructure change can delete a database, open a network path, or alter permissions, and some of those are not reversible in any useful sense.

Infrastructure automation has an advantage here that application development lacks, which is that declarative tooling already has the necessary safety mechanism. A plan output showing exactly what will be created, changed, and destroyed before anything happens is a natural review point, and it is machine-readable.

The sensible pattern that follows is agents generating the change and producing the plan, with human approval on anything destructive, and full automation only for additive changes within defined boundaries. That is a policy decision rather than a product feature, and it is one worth making before someone makes it implicitly.

The related requirement is attribution. When an agent applies a change, the audit record needs to show that it was an agent, under whose authority, from what instruction. Without that, incident reconstruction gets considerably harder, and the identity problem this creates is the same one appearing across every category where software acts autonomously.

Where this sits now

Infrastructure automation has become foundational rather than differentiating, which is what the criteria contraction from thirty one to twenty six and the vendor consolidation both indicate.

The interesting activity has moved up a layer, into platform engineering and internal developer platforms, where the question is not how to automate infrastructure but how to present it to developers as a self-service capability with guardrails. The automation tooling becomes the engine underneath a product that other engineers consume.

That relocation explains why the enterprise buyers in this category increasingly value breadth, silo integration, and ecosystem over the elegance of any particular abstraction. The people choosing are building a platform, and a platform needs to cover the estate that exists rather than the one that would be tidier.

The organisations getting value are the ones that treated automation as a product with users rather than as a project with a completion date. The ones that did not have a repository of scripts written by people who have since left, describing an estate that has since changed, which is roughly where manual administration started.

Forrester does not endorse any vendor named here, and tier placement should not be read as a recommendation to buy.