One of my favorite perks of my position at Itential is the opportunity to have great conversations with all sorts of people in different technical engineering backgrounds. From programmers, application specialists, and network engineers, there’s always a wide variety of topics to talk about (especially around automation and orchestration), and an even wider range of opinions and viewpoints. As a self-proclaimed networking nerd, these conversations really get me thinking. One of the biggest topics that tends to come up is why we use JSON as the fundamental method to represent data in our platform. It’s an important question that I want to answer for you.
But before we dive it, it’s important to address the elephant in the blog. Depending on who’s reading this, it’s possible to spark the fires of a techno-religious war around what IS the best data format — and as I pay homage to the data format warriors who have fallen from previous skirmishes, I want to reiterate that my purpose here is to simply communicate Itential’s point of view. I hope we can all appreciate differing opinions, and only time can really tell whether they turn out to be correct, incorrect, or end up in some sort of in between, indeterminate quantum state.
Now that we’ve cleared that up, let’s talk about JSON.
Why You Need a Standard Data Language
One thing we can all agree is on that we live in a time and space where there is an ever accelerating, seemingly never ending, selection of choices for every sector of IT infrastructure. In that same vein, different groups are making choices to which technology goes best with their own needs. The systems and applications teams identify and select the best hardware and software they need for compute, and the network teams identify and select the best hardware and software for networking based on their specific criteria.
This approach to decision making leads to an incredibly diverse ecosystem of hardware, software, and applications. If IT operated efficiently in silos, this wouldn’t pose a challenge but the reality is that it doesn’t work that way at all, and to operate efficiently IT teams must automate and orchestrate across ALL of these systems and technologies they’ve chosen. A fundamental requirement to accomplish this is a common and flexible format to represent data across these diverse systems.
Why Itential Chose JSON
Most of these IT systems and solutions have some sort of API available, which does make automation and orchestration more straightforward, and many of these are REST-based and have support for accepting and receiving data natively in JSON. And there’s good reason for that – JSON has seen a rise in popularity through its history, which is documented by Infoworld. Looking at the trends, it stands to reason that JSON will only continue to grow moving forward and potentially become the de facto standard for data representation for APIs (or at least an expected and supported option).
But it’s not just a technology fad, like some sort of data format Tamagotchi. Its popularity is due to some very solid technical and usability reasons:
As a data format, it’s very lightweight especially compared to other text-based formats that use extensive tags.
Smaller and compact data sizes may not seem like a big deal, but when looking at scale this becomes very advantageous, and we believe that the number of different systems that make up the IT ecosystem will continue to grow over time so scale needs to be top of mind.
JSON is more human readable than other popular data formats.
I know this one will ruffle some feathers, but consider this context: from the perspective of a network practitioner, who hasn’t had daily exposure to a standardized data format, compare an object defined by JSON to one defined in XML and ask which looks more readable. The idea of using curly braces { and } to define an object is actually understandable for a non-programmer who uses the JunOS network CLI because it encapsulates a block of related configuration commands, and the JSON name:value association makes a lot of sense instinctively. Once this has been digested, it’s straightforward introducing data types to the non-programmer. All of this is especially important because network teams must make up lost ground in the race to automate compared to other areas, and if this makes it easier to get up to speed, that helps everyone.
JSON has a popular and growing share in the developer ecosystem.
For the programmer, from its beginning, JSON borrowed some conventions from C so it immediately looks friendly to people who are familiar with programming languages like C/C++/C#, Java, Javascript, or Python. All of which are still some of the most popular programming languages today according to this and this. That results in helping to make JSON a very well supported data format in popular (and even many less popular) programming languages, as you can see from the bottom of the list here.
Developers have already shown how it can be used to create complex structure with the object and type primitives it provides. Because of the format, many programmers find it much easier to manipulate JSON objects to extract and transform data to be used between different systems. In fact, our data transformation feature leverages JSON schema to define a rigid structure for incoming and outgoing data and the flexibility of the JSON format to make it straightforward to manipulate that data inside of the same automation task.
While this cannot possibly detail every possible reason we chose JSON (that would take up too much time and I’d forget to feed my Tamagotchi — and no one wants that), hopefully you understand a few good reasons why JSON makes the most sense for representing data within our platform and why we’re seeing it become popular in many other applications, systems, and platforms.
Itential’s Approach to Data Transformation
When automating between different systems, it’s necessary to manipulate data received from one, or more sources, so that it meets the standard for an API call to another system. Many of the programming libraries that support JSON make it very easy to do this in code, but the majority of network experts don’t have a programming background. This is why we created an intuitive, visual method for non-programmers to map and manipulate data between systems which helps the non-programmer overcome the skills gap previously required for network automation.
If you’d like to learn more about how Itential can leverage JSON schema and JSON objects to help network engineer and developers make automation and orchestration more efficient, watch our recent demos on Data Transformation for NetOps and Data Transformation for DevOps. You can also check out a free version of our JSON Transformation Designer here.
Rich Martin
Director of Technical Marketing ‐ Itential
Rich Martin is the Director of Technical Marketing at Itential. Previously, Rich has worked at several networking vendors as a both a Pre-Sales Systems Engineer and Systems Engineering Manager but started his career with a background in software development and Linux. He has a passion for automation in the networking domain, and at Itential he helps networking teams to get started quickly and move forward successfully on their network automation journey.
