Your organization has probably invested some serious time and money into automation. But after all that effort, chances are good you’re not happy with the results.
How do I know that? Research from EMA shows that more than 80% of network automation teams are dissatisfied with their automation efforts in some way.
One of the biggest beefs is with the source of truth.
Instead of a single sustainable system, the data shows that most organizations have needed to stitch together a “Frankenstack” of point tools. That stack results in complexity, fragility, and tech debt in their automation projects.
. . . . .
Why is maintaining an automation stack so hard?
In the beginning, you likely set out with modest goals and racked up some quick wins. You spun up a source of truth—great! You wrote an Ansible playbook—yay! So far so good.
But then you started seeing how hard it is to build something for more than just yourself or a small team of automation experts.
What you needed was a platform to scale out automation without the hassle of having to build and maintain it yourself.
What you got was the experts on your team working feverishly just to keep the stack functioning.
The goal for automation is to deliver efficiency and reliability to the organization. You didn’t sign up for an exponential investment in maintaining the automation toolset to make it happen.
. . . . .
Birth of the Frankenstack
How did we get here?
- Fixed schemas: Nearly every infrastructure source of truth or database comes with a fixed schema. If you need to evolve your data model, get ready to slap some things on the side.
- No versioning: Infrastructure management tools have historically been built without versioning, collaboration, or CI validations in mind. They expect you to add them. And you definitely need them, so now you have to build and maintain even more integrations.
- Extensions and plugins galore: Every new thing you add creates more difficulty. Most integrations create complex and opaque dependencies that are hard to validate.
For example, if you pull data from your source of truth into a deployment tool, the rendered data is embedded with business logic. If you need to change your data model, figuring out how that impacts deployment is extremely difficult.
Give this Frankenstack a few turns of the clock and you start creating a pretty painful load of tech debt.
. . . . .
Infrahub: A fully versioned data management platform
Infrahub was built to solve exactly these problems. Far more than a traditional source of truth, it’s a platform that brings infrastructure data and GitOps practices together in one place.
With Infrahub, you get:
- A flexible schema backed by a graph database
- Git-style versioning with branch, diff, and merge
- Built-in CI for validation
- Artifact rendering to drive deployments, documentation, and integrations
Instead of stitching tools together, you have a sustainable foundation for automation.
Infrahub’s role in your automation framework
Infrahub becomes the unified source of data and files that powers your infrastructure. It can:
- Synchronize data from multiple systems into one place for teams and tools
- Feed configuration deployments with device-ready artifacts
- Keep monitoring and observability stacks aligned with the latest configs
- Slot into higher-level orchestrators as part of a bigger workflow
In short, Infrahub is the engine that drives the rest of your automation.
. . . . .
Automation pillar 1: Data management
Those of you familiar with existing sources of truth will have felt the pain of modeling complex infrastructure like MLAGs or DMVPNs. As if that wasn’t hard enough, try modeling optical infrastructure, cloud resources, or Kubernetes in these tools. *bangs head on desk*
But Infrahub’s flexible schema can easily handle all of these complexities and more, with no need to mess with plugins or extensions.
Infrahub uses a graph database with a schema layer you can evolve as your requirements change.
Because the schema is easily extensible, you can start small and adapt or expand over time. No need to worry about getting it perfect on Day One, as making changes to the schema is as easy as making changes to a device.
When you want to turn designs into repeatable workflows, Infrahub gives you Generators. A Generator automatically creates all the building blocks needed to implement a design, and keeps them linked so they evolve together.
One of the most common Generator use cases we’ve seen is building out a service catalog of common changes to allow adjacent teams to safely request new services to be defined on the infrastructure.
. . . . .
Automation pillar 2: Version control
Peer review and validation are at the heart of many dev team workflows. Infrahub has recreated Git-like concepts such as branch, diff, and merge on top of the graph database to give these functions to infrastructure teams as well.
Infrahub’s version control features allow you to:
- Create branches for planned changes
- Share proposed changes with colleagues for peer review
- Merge safely after validation
Infrahub also maintains an immutable historical view of the network, giving you transparency, change auditing, and easier troubleshooting.
. . . . .
Automation pillar 3: Native CI
In the world of code, we typically validate every unit test for every change just to be sure. In the infrastructure world, the historically human-driven change management workflow made it difficult to deploy incremental changes quickly. Continuous integration automates this process and makes it possible to move fast while ensuring high-quality outcomes.
Infrahub has a built-in CI pipeline for validation. Infrahub supports CI processes by running checks on proposed changes during the review process. These checks ensure data integrity and help identify potential issues before merging. Custom checks can be implemented to enforce specific business logic or operational requirements.
The combination of a flexible schema, native versioning, and CI allows your team to manage any level of infrastructure change in an efficient, peer-reviewed, yet automated fashion. You get the best of both human oversight and automation velocity.
. . . . .
Infrahub in action
Now that we’ve covered some of the what and why of Infrahub, let’s see it work. Product Manager Wim Van Deun walks us through making a change—in this case, he shows how to add a new backbone link.
First he makes the change in Infrahub manually: He creates a branch, adds a circuit, connects the endpoints, proposes a change, and validates the change with CI.
Then Wim shows how to achieve the same outcome using a design-driven service built with an Infrahub Generator. Exposing this change management process as a service allows less technical users to make the same change safely and consistently.
Along the way you’ll see how Infrahub’s flexible schema drives the UI and GraphQL API, how Transformations produce device-ready artifacts, and how Proposed Changes combine data diffs, artifact updates, and CI checks to keep automation trustworthy.
