Searching for scissors in my house is a frustrating endeavor.
There are several reasonable locations where one would expect to find them. Several years ago, the place where they were often found was my daughter’s room. Times have changed — she is less interested in scissors these days, and now they tend to migrate into the junk drawer in the dining room. Before my daughter’s obsession they were found in the kitchen drawer along with other useful household tools. The decision to put them there confounds me and is outside of my control. When I need them, I have to ask and then search.
Why can’t they just always be in the same place? Well, they can’t, for reasons.
When companies want to automate network changes and maintenance, like me when I’m searching for scissors, they normally have to search and ask various systems for data in order to make good decisions. Sometimes the data is factual. Sometimes the data is used to derive further data and a process is invoked. Sometimes the data is scattered across disparate systems. Sometimes the systems contradict each other. Sometimes information is missing or wrong. Sometimes the data needs to be reformatted, verified, and triple checked against other systems.
There are plenty of reasons why it’s like this. Most of the time to explain the reasons requires recounting the entire history of the company.
Says a seasoned employee, “We used to be two companies and then in 2007 we merged with the other guys but never merged databases. Then in 2010 we bought a super system but some of our special legacy data was impossible to migrate so that’s how we ended up with three databases for stuff.”
We’ve all either heard or lived through this.
In these situations — which describe just about every company — the temptation is great to conclude that “the unification theory” is the thing that will fix all of this. To fix the complexities of the data sprawl and technical debt accumulated over time, the idea is inevitably put forth to aggregate and unify everything into one place. The Single Source of Truth (SSoT).
Says seasoned employee and accomplished DIYer, “Let’s spend some time and money, find all the data, and stick it into the SSoT. We’ll fix all the inconsistencies, fill in the gaps, reformat the derelict oddballs, triple check everything. We’ll code it ourselves because we understand it best. When we finish, we will decommission all the old stuff, pay back our tech debt. It will be great!”
“How long will this take?” replies the ambitious and fearless director of technology.
“Six months. We’ll write some Python, use open source tools. It’ll be cheap. It’ll be great!”
This is only the beginning of the troubles. Once this decision is made, you are not just diverted from your goals. You are actually moving in the wrong direction. Time and effort spent building the SSoT could instead be used to automate network changes.
The intention is not wrong. Companies need a simplified destination for factual data and trustworthy processes for managing networks. But the SSoT is really about applying the appropriate perspective at the right abstraction point. It is also about having trustworthy processes that can determine factual data and apply changes. Folks get caught up in the correctness of the SSoT and the idea of centralization, but this is less important than having a trustworthy process. The key thing is ensuring that automations are using correct data — the route you take to get there isn’t so important.
How Your Source of Truth is Like Ordering a Meatball Sandwich
Perspective and abstraction are important factors when discussing SSoT. Here’s a metaphor.
When I go to a restaurant, I look at the menu. From my perspective this is the SSoT for what the restaurant offers. I order the meatball sandwich with the server and now the trustworthy process begins and the perspectives shift. The server takes the order and brings it to the kitchen staff, the server’s SSoT. The kitchen staff examine the order and look into the refrigerator, their SSoT. If there are no meatballs in the refrigerator the kitchen staff can check the freezer, the other SSoT.
This is where the perspective matters. I do not care what the kitchen staff has to do. I just want the meatball sandwich, which is either possible or not. The server who takes my order also may not care how many places the kitchen staff have to look for the meatballs. The kitchen staff may have to check many places for meatballs. What I do care about is that the server applies a trustworthy process for determining if I can have the meatball sandwich. Similarly, the server only cares that the kitchen staff have a trustworthy process for finding meatballs. The “single” idea breaks down, but as long as each process can be trusted, we’re still working with good information.
How does this apply to network automation?
The goal of network automation is to automate stuff on the network, not to build databases or aggregate data. The server at the restaurant should never look in the fridge or the freezer for the meatballs. But they need to be able to get them. Find a way to apply perspective and abstraction to all the sources of truth. Find a process that is trustworthy to interrogate these sources of truth for the most correct answer possible. Then network automations can rely on those processes. That’s how we approach the Source of Truth concept at Itential — by ensuring our platform can integrate with everything else in the digital infrastructure stack, we make Itential into a kind of higher-level version of a source of truth, where the information is always trusted because it’s coming directly from the relevant sources.
Words matter. We don’t need a single source of “truth.” We need a single source of trust. Whether it’s scissors, meatballs, or IP addresses and VLANs, we need a trustworthy process that is capable of determining the answers to our questions. Forget about building the SSoT, leave your data where it is, inconsistent, unformatted, whatever, and focus instead on the process required to determine the answers. Automation promises to make our lives easier, but if you feel like you need to undertake a mammoth data integrity project before you can automate, it’s really doing the opposite. At every team, at every company, all network operations both automated and manual rely on a set of trusted processes, ways of finding the data you need. Automation is best when it meets you in reality — start practical, start where you are, and you’ll see the positive impact sooner than you think.
You can see how we make this happen in this demo from Networking Field Day.
Steven Schattenberg
Automation Architect ‐ Itential
With over 20 years of experience in a variety of tech and media companies, Steven Schattenberg has a deep understanding of how a variety of industries operates and can deliver solutions at scale. As an Automation Architect at Itential, Steven helps customers deploy automations across their network infrastructure.
