How Itential’s Patented Integration Innovations Accelerate Network Automation & Orchestration Adoption

Morgan Stern • 00:00

Hello, everybody. Thank you for joining us today for our webinar, How Itential’s Patented Integration Innovations Accelerate Network Automation and Orchestration Adoption. My name is Morgan Stern. I’m the VP of Automation Strategy at Itential. Today, I’m joined by my frequent collaborator, Itential’s Head of Solutions Engineering, Karan Munalingal. How’s it going today, Karin?

Karan Munalingal • 00:22

Hey, Morgan. Hello, everyone. Super excited to talk about our patents today, Morgan. So let’s get into it.

Morgan Stern • 00:29

Absolutely. In today’s session, Karin and I are going to talk about two important patents that Itential recently announced and how those patents enable capabilities in the Itential platform to deliver powerful integrations that can unlock new multi-domain use cases for automation and orchestration. As always, if you have questions, please ask them along the way in the chat window, and we will respond in the chat window. All right. With that said, let’s get started. All right. For us to talk about how these patents are so important, I think it really is useful to talk about the reality of the way networking has evolved, and the level of complexity that’s been injected into these environments. So to do that, I wanted to talk about the way it’s been and the way it is. If we think about the way it was, and this was the way it was for a long time, companies had relatively simple network environments. They might have a connection to the internet, they’ll typically work with a service provider that would connect their branch offices, and then they’ll have a data center or two. But pretty static environment, pretty predictable in terms of what they needed to deal with, and relatively small number of suppliers, like as in vendors, and a small number of folks that they had to interact with.

Morgan Stern • 01:47

That is a stark contrast to the way things are today. Today, as we like to say, the Internet exploded on my network kind of thing. We are seeing all kinds of technologies that have been introduced into networks. In addition to the traditional IP networking, we start to see over-the-top applications and software as a service applications like ServiceNow. We see the hyperscalers coming in as people are transitioning workloads to AWS, Azure, GCP. We start to see overlay technologies like SD-WAN popping in. We also start to see security applications and SASE applications really becoming this additional layer on top of the existing network.

Morgan Stern • 02:35

Now, for folks who are charged with managing these environments, they recognize the complexity here, that each one of these services, each one of these tools, each one of these technologies, really has its own way of interacting with the network environment. So typically, you’ll get some set of tools from the vendor. You may augment that with additional things, but each vendor’s got their own implementation, their own syntax, their own APIs, their own tools. So the challenge for most of the folks who are charged with managing these networks is, how do I navigate all across all of these different tools? How do I maintain skills across all of these things? Then how do I start to translate between all the different data formats?

Morgan Stern • 03:25

Because what happens is things stack on top of one another, that for my SASE to work means that the rest of my networking needs to work, which means my data center needs to work, which means I need to be able to get access to service now. These are all interconnected things. So the complexity of the traditional network environment really has become sufficiently difficult for most folks to be able to navigate. And that’s what we’re really here to talk about is, what can we do to deal with these two issues? One around managing APIs, the other around managing data formats. So let’s talk a little bit more. As I mentioned, each one of the vendors will usually supply folks with their tool.

Morgan Stern • 04:08

It isn’t the lack of tools that’s a problem, it’s just this explosion of tools that are the problem. But each one of those tools is custom made for that specific vendor, for that specific technology. In this environment, really, for most vendors that are in these competitive spaces, they obviously want to make sure that people use those features and capabilities that are unique and adding value to the business. They will structure all of their tooling, they will structure their API all around their specific product and their specific technology. Where it starts to become more complex is in a lot of environments, it isn’t just one vendor, there may be multiple vendors. Even if you’re dealing with the same technology, whether it be Cloud, IP, security, whatever, you’re already getting into a situation where you’ve got to then translate and context switch when you’re jumping from one tool to another. So what we start to see then is this need for the engineers and the folks working in the network are now having to maintain almost like a different knowledge base, a different mental context as they jump from, well, if I need to do this in Azure, okay, I need to be thinking about using the Azure CLI, I’ve got to use the tooling for there versus if I jump to AWS, AWS CLI looks very different.

Morgan Stern • 05:36

It’s different in even some of the conceptual, like functionality pieces are very different. And so this creates a lot of overhead for folks as they’re trying to manage their network and do the job of delivering applications and capabilities to their end users. This overhead really starts to take its toll as you start to just layer technology on top of technology. So, the industry in an attempt to kind of solve for this has gone in, I think, two diametrically opposed directions. On the left, you see the sort of highly abstract models. On the right, you see the highly specific implementations. And we’ll talk about both of those, right, on the highly abstract side.

Morgan Stern • 06:24

The idea here is, well, if everybody is generally talking about the same stuff, but they’re using different terminology, maybe I make a standard that lays on top of that that is more abstract and more generic. So that instead of talking about a specific implementation, I talk about a type. So in the router industry, you have routers from Cisco, you have routers from Nokia, you have routers from Juniper. But they’re all routers. They all do general things. So let’s talk about those in a very abstract way. And so you see standards bodies and technical bodies like the telemanagement form or the Metro Ethernet form in an attempt to kind of streamline and avoid this very bespoke integration.

Morgan Stern • 07:16

What they’re doing is stepping in and saying, I’ll tell you what, let’s define some of these things in a very abstract way. And that way, it’ll simplify things for people that need to talk to deploy a network capability. Theoretically, you’re going to have a lower cost of integration because if each vendor aligns to MAF or aligns to TMF, well, then they’re all doing a little bit of the integration work ahead of time, and they’re delivering something that should work. The reality is that doesn’t quite work when you go to deploy. And the bigger problem is that it forces everybody to adapt to a lowest common denominator feature set. Which means you nullify as a vendor, you all of your differentiating capabilities get nullified because you’re really focused on this kind of commonality as opposed to the things that make you unique. Which not only to the vendors, but also to the implementers, it really stifles their ability to be innovative because they’re still conforming to this least common denominator kind of situation.

Morgan Stern • 08:19

So the other end of the spectrum would be staying in that highly specific world where every vendor is able to preserve their API and their data format 100%. so that they can leverage their unique features and the end users can deploy the unique features. Problem there, right, is what we’ve already talked about. That becomes very complicated to work with, requires multiple tools, requires multiple sets of expertise. And it’s an ongoing high cost to interoperate, not just to do that initial integration, but then to just manage that overhead that I mentioned earlier around just mental context switching every time I need to jump from one technology to another. And underlying a lot of these conversations, lately it seems that people want to focus on source of truth, that regardless of how I express my data, I want to consolidate it all under one single source of truth, so that any systems, people, tools can just go to one place to get data. Now, at Itential, I think we see the benefits of both of these pieces on the spectrum.

Morgan Stern • 09:38

Like there are times when it’s extremely useful to use abstraction. The problem is, when you only use abstraction, you lose a lot of capability. So, the technologies and the research and development that we’ve done at Itential that’s resulted in these patents was really how to solve for what can we do to enable abstraction when it’s useful, what can we do to preserve specificity when it’s useful. And Karin, I’d like you to just kind of talk a little bit about how we’ve implemented.

Karan Munalingal • 10:13

Absolutely, Morgan. So let’s let’s talk a little bit about how Itential helps solve the challenges that Morgan has brought up right thus far. So from my Itentialist perspective, there are two sets of capabilities that we have focused on in order to provide a more balanced approach on this spectrum between highly abstracted and highly specific. The first one being Itential’s ability to quickly integrate with technologies, both commercial off-the-shelf or someone who is building proprietary in-house that you see across enterprises and CSPs environments, whether they’re programmable or non-programmable. Some of the technologies that we work with have APIs, and most of the vendors these days are required to provide APIs for their systems. But then you also have some of the older tools or network focus devices that are still CLI operated that are non-API driven. Granted that the integration is fast and easy that Itential provides, customers can now take advantage of all the vendor specific APIs and capabilities rapidly as part of their automation and orchestration strategies instead of having to wait until the standard body says everyone has to implement this particular single API in order to interact with five different vendors. Right. So that’s the first is the integrating part, integration part with multitude of technology in their own cloud native fashion. The second piece that Atensial has focused on is its ability to leverage the integration capability but also providing data integration strategies to provide a level of abstraction, as when Morgan mentioned, where it makes sense. So a lot of times when you start putting abstractions down at a connectivity level, you’re not solving the larger problem. When you have thousands, like 90% of folks out there who want to consume services, that’s where abstraction makes a lot of sense. So from our perspective, what Atensial has focused on is providing tools and capabilities within the platform so enterprises and CSPs can make it very easy from a consumption perspective for their own customers to take advantage of the investments that they have made in network and cloud and data center, etc., across all these domains. Right? Because essentially, it’s not you’re talking vertically to a single system when someone is requesting services, it most likely goes across multiple of these domains.

Karan Munalingal • 12:50

So making it easy, where northbound, no one has to understand how complicated it is, how complicated your network is, becomes critical. And the last piece I’m going to share, Morgan, from my potential perspective is, our end goal is to help preserve the fidelity of vendor specific APIs, which enables our customers to leverage the best out of every technology that’s out there in the market, but also enable a distributed source of truth model via API federation to take advantage of data being stored across appropriate sets of technology to drive these services rather than, you know, everyone trying to focus their time on consolidating all of that in one place. Morgan, back to you.

Morgan Stern • 13:35

Thank you, Karin. I think as you’ve heard us talk about in the past around the source of truth thing, our expectation is as the networks continue to evolve as they do, that it really becomes critical to support this distributed source of truth model. Because there’s a lot of distributed information when you start to think about the Cloud providers, when you start to think about some of the controllers, like data center controllers or other SDN controllers, there’s a lot of data that changes very dynamically. And so we feel like it’s critical to recognize that at any point in time, there are going to be different systems that are authoritative from a source of truth standpoint. And we want to enable our users to be able to define that based on their environment, based on their unique situation, so that at any point in time, they can go to the right resource to get authoritative data that they can use as part of their orchestrations and automations. So what we’re going to do next is kind of break the patents into two categories. The first one being the patent related to navigating APIs and API structures. And then we’ll talk about the data transformation patents after this.

Morgan Stern • 14:52

We already talked about the complexity of modern networks. One aspect of this is when you think about all of the different logos you see on there, every single one of those logos has its own unique API. In some cases, they’re talking about the same stuff. Karin, you and I were talking about this in preparation for the call. You mentioned a good example of this being some of the Cloud providers APIs. Do you want to talk about that for a minute?

Karan Munalingal • 15:19

Yes, sir. So, as everyone knows who has ventured out in the cloud world, Amazon, Google, Microsoft, they’re all out there to out-invade each other. And what that means is every single day, every single re-invent, or any of the Microsoft events, you’ll hear about the new capabilities that they’re pushing out for the consumers to take advantage of. And what that means is from a programmable sense, there’s a lot more APIs that are coming through. But what’s interesting there is, as Morgan mentioned, conceptually, when someone says, I need infrastructure being stood up in one cloud versus the other, it means the same thing, right? You need a private cloud, you need an EC2 instance within, you need network access control, et cetera. So, across these three clouds, the way that they have defined their APIs, They do similar things, but the data structure and how you interact with the API is slightly different. And as you can see in this particular example, right, me having to go ask everything about a VNet or an AWS VPC or a GCP VPC, I might have to invoke 12 APIs from AWS to gather all that information, bunch that together, and provide that to the end user. On the other hand, I can just issue a single API to GCP and it tells me everything about that particular private cloud that someone has spun up and its infrastructure with it. So what’s important here is as customers and enterprises and CSPs continue to invest and take advantage of the right tool for the right job, even though the concepts of security, infrastructure, network sound similar, them having to interact and decipher which APIs to hit in order to get certain sets of information becomes very hard. It’s untenable over time, right? And that’s why, you know, from my Tendrils perspective, there has always been a focus, how can we make this easy for end consumers? So whether they’re connecting into AWS or Azure or GCP, can we make it easier for them to get information about their assets that they have deployed or they want to deploy? So it’s a single network API rather than them having to manage multiple APIs underneath that might be potentially changing over time, right? APIs are APIs, every modern technology is now providing those right at the gate.

Karan Munalingal • 17:53

But that does not necessarily mean that they’re all the same, right? And that’s one of the examples that we’re trying to showcase here, is when we go into the demonstration, you will see how one of the patents that Itential has come up with helps with this level of abstraction, where we can be network intelligent, focus on multiple of these domains, and then provide single API, network API, northbound, so someone can actually say, hey, give me all the information about all my infrastructure, doesn’t matter if it’s across one cloud or all three clouds. So back to you, Morgan, for a further explanation on the architecture.

Morgan Stern • 18:31

Okay. Thank you, Karin. So let’s talk about how we’re doing what Karin just described. The patent is listed here. It’s systems and methods for dynamic federated API generation. Quite a mouthful. There are a couple of pieces that I wanted to talk through before I explain the process just so that you understand the different components that we’re talking about. Down at the bottom, you see the network. You’ll see three different networks.

Morgan Stern • 18:58

Those could be different technologies, different vendors, different domains altogether. But they’re connected into the Itential platform through adapters. Adapter is our functional component that connects the network to our system and we have a unique way of generating adapters so customers and users can generate their own adapters for free very easily from a web app on our site. Additionally, as Karin will show you, we host an open source site with adapters for a lot of the most popular systems, but the idea of an adapter is the adapter is the thing that provides the connection between the network technology and the Itential platform and subsequently that adapter understands APIs, it understands data structures, and understands all of those kinds of things. Each adapter when it’s created is configured such that it can talk to what’s listed and here is the adapter router. The adapter routers job is to basically provide the routing in between each of those individual adapters in the Itential platform. What we’ve done, and when we talk about abstraction, this is really the primary area where we’re leveraging the ability to do abstraction. We’re defining a series of entities. An entity is just a network resource that would be common across multiple different technologies.

Morgan Stern • 20:31

In a few minutes, we’ll talk about how a device is a entity. In that entity layer, we’ve got a database that lists all of those models. Then wrapping around that, we have what’s called the broker layer. The broker layer’s job is to really help to coordinate all these different pieces so that ultimately, we can expose a common API up to the business logic layer, which is where the workflows and the orchestrations exist, which is where people interact with the system. Within this patent, there are really two processes that are highlighted. One is the process for generating the federated API, which I will talk about first, and then we’ll talk about the next one. In this one, as I mentioned, when you install an adapter, basically, that’s going to be a request for an API interface, which then generates the broker instance, which goes into that entity database, grabs the models.

Morgan Stern • 21:27

The adapter is then formally registered with the system, and the system will ingest all of the APIs that are associated with that adapter. Every call, every function that you want to get from that system becomes ingested. We start to build models of that and maps of that so that we can generate one master federated API list that would be the aggregate, the combination of all of those different APIs in one master list. That master list can then be exposed and used by the automations and the orchestrations and the end-users, so that they actually see the connectivity to all of those different systems. From one workflow, I can very simply navigate and call to all of the different APIs, as opposed to having to understand all of those different formats, I’m just presenting it in a very simple way. I will have a create VPC on AWS, I’ll create an Azure Cloud, I’ll have all of those different things, but I don’t need to understand all of the routing of the API and the structure. I just see the function, I can call it, and then the broker layer will manage how all of that gets distributed and directed.

Morgan Stern • 22:49

The second part is this process for routing API calls, which is what I was just talking about. A user or a workflow or an orchestration or an event will make a call to the API from the business logic layer. The system will basically generate the language agnostic messaging, it will transmit it to the broker. The broker then figures out, which of the systems, the adapters that are registered are compatible with this call, and then it will route the API call to a compatible adapter. All of that complexity gets then pretty much hidden from the end user. What’s really cool about this is, this is all very dynamic. As new systems come into the platform by adapters, all of these databases, all of these mappings will dynamically get recreated so that at any point in time, whenever a user or an orchestration is requesting functionality, we’re going to go to what’s available based on that point in time.

Morgan Stern • 23:57

Okay, Corin, can you kind of talk about an example of all of this brokering and API functionality and abstraction by talking about devices?

Karan Munalingal • 24:08

Yes, sir. So as Morgan just discussed, right, from a northbound perspective, Configuration Manager is one of Fidential’s internal applications, right, that exposes and takes advantage of the brokering capability here. So in this specific example, we have a device broker, and underneath the device broker, we have adapters that are connected to multiple different types of technology across multiple different domains. So as you can see from left to right, right, Automation Gateway is an intentional product as well, that is connected to all the non-programmable assets. So all your usual devices, network devices, firewalls, routers, etc. And then, you know, keep going to the right, you have orchestrators provided by some of your vendors, you have controllers, as well as, you know, cloud platform, cloud providers that have their own set of APIs that enable users to interact with the resources within their own cloud. So how does this all work? So as Morgan mentioned early on, when you start onboarding adapters within the Itential platform, they start registering themselves as potentially someone who can take actions on the concept of a device, right? So on the left-hand side, Automation Gateway can talk to routers. They can say, hey, I understand routers, firewalls, switches, et cetera. Then on the right, all the way to the right, we have cloud platforms. So when you onboard an AWS adapter, that adapter understands the concept of a virtual private cloud, VPC, right?

Karan Munalingal • 25:45

Same thing with Viptela or Versa or some of the other SD-WAN technologies. They understand edge sites and edge devices. So as customers continue to start plugging in these adapters, the adapters now say, hey, I’m able to manage a concept of a device underneath me, so please put me in that list. And northbound, what happens is, as you can see in this example, you have functions like list devices. Is the device alive? Get configuration about that device or set config. So from a configuration manager application perspective, instead of that app learning how to talk to each one of those individual adapters differently, because they all have different sets of APIs and data structure, all it has to do is talk to those four functions.

Karan Munalingal • 26:34

So when someone goes into the config manager application and says, hey, I want to list all devices that I have in my network, that particular action, the device broker actually sends that out to every adapter that registered itself as a device-owning adapter. We’re going to see this later on during the demonstration as well, where when we actually go to the Config Manager base in the background, it’s actually sending that request of Flizz devices to AWS adapter, Meraki adapter, automation gateway adapter. Then it aggregates all the information that comes back and presents that to the end-user as a single pane of glass and all the infrastructure that is being managed. At the same time, imagine another application, potentially outside of Itential, who wants to get some level of config information from a VPC or an SD-WAN edge device. Instead of them having to figure out what APIs to call, they can just call Itential’s API to say, get config. And we can actually, the broker understands that someone is asking to get configuration about an SD-WAN policy or SD-WAN edge device, and it’s going to automatically route that to that specific controller that said, hey, I can manage and own that device, right? So what this does is eliminates the need for northbound application or app dev teams in order to figure out which APIs to hit, especially if their infrastructure is distributed.

Karan Munalingal • 28:09

And you’re going to see a live example of this as part of our demonstration today, where I’m going to discuss a little bit more on how everything is happening. How do adapters get onboarded? How does everything happen in a more dynamic fashion rather than, you know, point-to-point static? Morgan, back to you.

Morgan Stern • 28:29

Okay. So now that we’ve talked about the first patent, let’s talk about the second one. The second one is focused on the data formats and data structures challenge. And we’re going to talk a little bit more about that in a moment. But for now, thanks for watching. Similar to when we talk about the difference in APIs, we’re now confronted with the fact that not only are the APIs different, but in a lot of cases, the data formatting is different. As we’ve said, vendors are going to orient their data formats around what makes their product unique and special.

Morgan Stern • 29:01

They want to expose the most important functionality so that they can offer a differentiated feature set so that they can have value in the market against their competitors. But similar to the API thing, in a lot of situations, they’re describing the same features in different ways as Karin is going to explain.

Karan Munalingal • 29:23

Thank you, Morgan. So as Morgan alluded to it, APIs are one thing, right? But when you’re trying to provide a more seamless way of consuming your network, we work in a very uneven landscape of interaction with programmable and non-programmable assets. As you can see on the left-most side, we’re working with devices that are NetConf operated, right? And that’s the data structure that we have to deal with. At the same time, you have your usual Cisco CLI, and that’s the response that you usually get. And on the right-hand side, granted that we’re talking about ACLs, when you ask AWS, hey, please describe all the network ACLs that I have as part of this VPC, this is the actual response you will get. So to a human, this is three different types of responses. Granted that we’re revolving around automation and orchestration to a machine, how can we make this easier, right? So whether it’s someone requesting to create, read, delete ACL, let’s make it easy for them to request that. And underneath, let’s take advantage of, you know, I-10 shows capability around data integration and manipulation that enables enterprises and CSPs to actually manipulate and say, just give me two pieces of information, which is your, you know, client IP that you want to potentially block from your network or allow within your network, as well as the port and potentially the destination. With those three pieces of information, just those three, someone within the Itential platform can now map to whatever the data structure the end system requires. That way, you’re not running around asking vendors to go change and conform their piece to whatever service now or an API understands. From an end-user’s perspective, let’s make it very easy. They only have to provide you a minimal amount of information, and you take that information, manipulate it as much as you need to in an easier format, and then distribute that to these three different sources that are actually going to provision the network assets and the network resources. And we’ll talk about this as part of the demonstration as well, Morgan, so if you want to move forward with the next piece. Okay.

Morgan Stern • 31:47

All right, so, as we’ve talked about the difference in data formats, let’s talk about the patent, right? This one’s systems and methods for improved data modeling and translation. So Karin showed an example, the one on the left was of a YANG representation of a data payload. And YANG, being sort of the evolution of some of the network CLI things, very well optimized for talking about network concepts and network constructs. So nodes are typically routers and switches, links, routes, services, those kinds of things. But it’s a very specific language for describing those kinds of things, very structured. On the other hand, you may have information about the same kinds of entities, nodes, relationships, groups, features, but expressed from an API-based system.

Morgan Stern • 32:44

And so what we’re doing as part of the patent, when you think about this, we’re saying, well, both of these are describing things that have some commonalities, in some cases, some very real differences. Not everything is the same. As we’ve talked about earlier, abstraction isn’t always a great thing, but what we wanted to be able to do was say, well, let’s take both of those kinds of payloads, both of those data formats, let’s translate them into a common, human-readable format. So for the Itential platform, we’re using JSON because it gives us a very clean mechanism for being able to translate a NetConf-specific payload or a REST-based payload into a common, very human-readable format. Once we do that translation, we’re going to present that human-readable, very common thing up to users and applications, so that as a writer of orchestration workflows, I don’t need to be constantly concerned about how I’m going to translate this into the specific payload. I can use that common human-readable format to interact with, and then I can have a plug-in at the end that would do the translation. What’s happening is we’re translating in two ways.

Morgan Stern • 34:04

One is from the specific into a human-readable common format, and vice versa, so that as a user, I’m seeing the common format, I’m interacting with that, I’m saying, I want to make a change here, I want to add an interface, I want to change a port, I want to change a setting. Once I select that action, either real-time or through an orchestration, that translation then works in reverse. I go from the common readable format back into the specific piece so that the change can be made to that end device. It’s bidirectional, but the advantage of having something that’s common and human-readable means I can write one set of orchestrations, one set of workflows. I don’t need to be as concerned about the specific technology I’m interacting with. I just need to be thinking about what is the business and some of the technical logic that I need to apply to the situation so that I can accomplish the change that I need to accomplish. Now I’m going to hand things over to Karin.

Morgan Stern • 35:07

He’s going to demonstrate a couple of the features and then I’ll be back to wrap things up.

Karan Munalingal • 35:12

Thank you, Morgan. Before we jump into the demonstration, what we’re going to show today, we’re going to focus on the whole concept of API federation, how the federation layer comes into picture providing that level of abstraction. But also the data integration strategy, which enables you to take advantage of all the disparate APIs that all the vendors actually have and they’re purposeful. These are the two that we’re going to cover today as part of the demo. On the right-hand side, you’ll notice from a demo architecture perspective, we are going to be interacting with things like AWS, and Meraki, and the Automation Gateway, which talks to things like F5 load balancer, Arista switches, Juniper routers, etc. With that, let’s go ahead and jump right into the demonstration. All right, so before we jump into the platform to show you how the, you know, Itential’s patented technology helps a lot of our customers as part of their automation orchestration capabilities, one thing I do want to discuss is the whole concept of pre-built collection, right? As Morgan and I discussed early on, integration is critical so customers can take advantage of automation at a larger scale to provide more value to their business, right?

Karan Munalingal • 36:33

So from our perspective, we want to eliminate the integration tax and for that purpose, you’ll notice we’re providing a lot of out-of-box adapters as Morgan discussed, right? Adapter is how we connect into systems, take advantage of their APIs in order to make changes into the network or the cloud or any other domain, whether it’s an ITSM system or source of truth, et cetera, right? I’ve currently filtered the adapter list here, but we have close to 250 of these already open source, but the concept here is, you know, in addition to Itential providing all of these right at the gate, because we can take advantage of the open API specs the vendors are providing, these are auto-generated. At the same time, if you don’t, if customers don’t see any on the list that they would like to integrate into as part of their automation strategy, we have also open source the ability to build one of these Itential adapters yourself. So we have a lot of customers today that build their own adapters to their own internal technologies or even commercial off-the-shelf technologies to automate and orchestrate across. Now that we have covered the pre-built library here, let’s jump right into the platform. The first part of the demonstration, what I’m going to showcase today is how do we onboard and enable these adapters and what happens when you enable some of these adapters that take advantage of the device broker that we initially discussed.

Karan Munalingal • 38:08

This is the Admin Portal, the Admin Essential on the left-hand side, you’ll notice these are all the adapters that I have already onboarded within this particular instance of Automation Platform. What I’m going to do now is quickly go into Configuration Manager application just to show you which devices are currently being federated through the Automation Gateway integration that we have. Then we’re going to come back here and turn on the AWS adapter, which was onboarded but stopped, the Azure adapter, and the Meraki adapter. When I do that, once I turn these things on, the adapters on, it’s going to go through the whole process of registering itself as a device owning adapter within our ecosystem. Then it’s going to dynamically pull all the assets that it can see so someone can take action on it within the Config Manager application. Let’s quickly go here to Config Manager application here. On the left-hand side, you’ll notice there is a long list of devices.

Karan Munalingal • 39:10

These are all non-programmable assets. I can go into the F5 and you’ll notice I can load live configuration on the F5 device. I can take backup on these device. Everything that I’m clicking on within this application could also be done via an API or within one of our Automation Studio. You can actually automate and orchestrate that. But the further point is, you’ll notice there are currently 33 devices that we’re federating through Automation Gateway, and it tells you the origin here. What we’re going to do next is go back to the Admin Essentials portal.

Karan Munalingal • 39:45

I’m going to turn on all three of these adapters. First one being the AWS, second one we’re going to turn on the Azure, and I’m going to also turn on Meraki. Once the adapters come up, they’re in the process of registering themselves as a device owning adapter within the platform. Once I come back to the Config Manager page, and let’s hit refresh here, we should see. The device list go from 33 to a larger number because every adapter currently is federating that real time. So you’ll notice the number went from 33 to 55. So what does that mean right in addition to us federating across the automation gateway integration. Now if I look for an access point, we should now see these are all the access points being federated through Meraki. So when I click on one of these, you’ll notice, I have the same experience from an end users perspective. I’m not dealing with writing any code, this automatically registers itself and pulls all the AP so I can just load config.

Karan Munalingal • 40:56

And it kind of shows me all the configuration. The one thing you’ll notice, right, the configuration of an access point or switch that Meraki manages is slightly different than a CLI device so this is a JSON object coming back. And you will see the same thing if we now go look for an AWS device right so let’s get rid of this queue. And I’m going to do the same thing. I’m going to let’s go look for a VPC here on this list. And you’ll notice. These are the VPCs, right? So it’s associated with the AWS adapter. When I click on it, I can take the same set of actions against this VPC, just like I was able to do against an F5 device, a Cisco router, or even a Meraki access point, right? The point being, when someone’s on board, a customer on board’s an adapter within the platform, it takes advantage of the whereby the configuration manager application only has to interact with a smaller set of APIs instead of having to remember and know exactly which APIs to hit against every single system to pull that set of information, right? So a lot of our customers take full advantage of their distributed set of controllers that they have, but this gives you a unified view because of our patented technology that enables you to plug and play vendor technologies that you might have and take advantage of their native APIs in order to give you this seamless experience. Right, so that was the first part of the demonstration is to show you how the adapters register and how we dynamically pull this list across those technologies to give you this potential view. The second part of the demonstration, we’re going to focus on the data integration and the manipulation strategy, right? And for that, what I’m going to do is go to this screen.

Karan Munalingal • 42:55

So as we talk about, you know, abstraction is good at certain levels, right? You want to make it easy for your end users to take advantage of your network and cloud innovation as well as investments. So how do you do that, right? Today, when someone has to go do something across three different technologies, they either would have to write, you know, three different scripts or a completely separate data model, or they’re going to try and homogenize that into one. From our perspective, in this particular example, what we’re showing you is. We’re trying to block an IP, but you can’t just block IP on one system. If you’re trying to secure your entire infrastructure, you potentially have your network devices or firewalls where you want to put an ACL.

Karan Munalingal • 43:44

You have AWS infrastructure, so you might want to create NACLs. You might have Panorama at play, so you might want to use their APIs to create a security rule. In this example, what we’re showcasing is this is an incoming payload or incoming schema from a, let’s say it’s Splunk or D3 or what have you, one of the SOAR platform that has figured out that someone is trying to attack your infrastructure. This is the set of information that we get. One thing that you will notice here, as Morgan mentioned, is we have centralized towards JSON as our common model that we can take advantage of in order to now distribute and apply and provide information to other systems that may not use JSON down the line. On the left-hand side, this is our incoming payload that tells us everything about that security threat. But once you get the thread, now the automation has to go interact with three or four different systems because we have to block that client’s IP there.

Karan Munalingal • 44:48

In this specific example, we’re taking the source IP and the destination IP, the port. We can directly just drag and drop and provide a straight link. This is a payload that is required by my networking team for them to actually go provision ACLs on the network devices, the firewalls or the switches. In order for them to do that though, when I get a source IP from Splunk or Phantom, they’re just giving me a pure IP address without a netmask. So in order for their automation or their script to work, I have to manipulate that where I have to add a slash 32. So you’ll notice there’s a lot of methods available here on the right-hand side that enable you to do that very easily, and that’s exactly what I’ve done here.

Karan Munalingal • 45:43

I have taken the source IP as a variable coming from Phantom, and I’ve applied a slash 32, and that gets passed onto an input for somebody else’s automation or a script. Now, let’s say I have decided, as part of my block IP automation, I also want to do this against AWS NaCl. I wanna create a NaCl entry to make sure my infrastructure is safe. For someone, they have to understand the API, they have to understand the payload, If I know what is the input required for my NaCl API, which I’m going to show you an example, it’s very easy for me to reuse the same existing incoming schema, manipulate the data real-time without having to write a single line of code, and then provide that information to a AWS API. Because naturally, ServiceNow or a ticketing system, or even a SOAR platform doesn’t necessarily just talk to AWS naturally. Someone has to write some level of coding.

Karan Munalingal • 46:51

In this example, what I’m going to show you is, let’s go ahead and add a brand new schema here. We’re going to say, this is a three pieces of information that the AWS API requires in order for it to go and create a new NaCl entry. I’m going to take advantage of this infer schema, and it automatically generates a JSON schema for me based on the JSON payload here on the right, which I’ve gotten from the documentation. Let’s call this AWS NaCl payload. Once I save it, you’ll notice now it’s available. So what am I supposed to do here? All I want to do is I want to map the source IP to the CIDR that I’m trying to block here.

Karan Munalingal • 47:35

So as you notice, I can very easily just drag and drop and now it’s mapped here. So the data coming into the source IP address will automatically flow into the CIDR block. At the same time, you’ll notice when I try to drag this particular destination IP, or let’s call it the port because that’s what it’s asking for. The port is a string that I get back from Phantom. It’s not going to allow me to do that because within our platform we automatically do data validation. So what it’s going to tell me to do is I have to manipulate this data and convert that into an integer for me to actually perform this transformation. So let’s take advantage of some of the methods here, and I’m going to call a parseInt, and I’m just going to drop it to the canvas here.

Karan Munalingal • 48:22

So now what I can do is I’m going to pipe this string into a parseInt and it’s going to actually convert. So this method is going to automatically convert that into an integer, and now I can map that to both from as well as to. So we have a tighter NACL being provisioned within AWS. At this point, I’ve shown you how someone can take data from one system or multiple systems, manipulate that, and then use it to other systems downstream. Once I build it, I’m going to go ahead and save it, but I can also run this. You’ll notice we enable customers to do validation on input as well as output. In this case, it’s going to validate the incoming and let me know if even the incoming is wrong from systems like Phantom or DT, etc.

Karan Munalingal • 49:11

I’m going to run it. It successfully validated and ran. You’ll notice at the bottom that it has successfully created the payloads required by different systems. So the first example here is it required a slash 32, which we use this method to automatically add. At the bottom, it was a brand new payload that we had to create for AWS NaCl. So just by reusing this potential capability within the platform where you can do data manipulation, now I can extend this capability where northbound, whether the service request is coming from a human or a machine, all they have to do is provide us with this schema. And downstream, you can start adding additional capabilities like blocking on Azure, blocking on GCP, blocking on Panorama. All you have to do is take the data coming from here, map it and conform it to whatever is required by the southbound or the network-focused technologies.

Karan Munalingal • 50:13

Right, so what this helps eliminate is a need to go to places like Phantom and ServiceNow and tell them, hey, I don’t like your payload, so go change that, right? Instead of disturbing the piece northbound and making it easier for the consumers, we can now take advantage of potentials, data manipulation and integration capability in conjunction with the automation and orchestration strengths in order to provide this sort of an end-to-end orchestration, right? So I’m going to throw it back to Morgan. That was the end of our demonstration that covered both of our patent focused on API federation as well as data integration.

Morgan Stern • 50:55

All right, thank you, Karin. So in conclusion, just to kind of wrap, like why does this matter? Why does all this integration and federation and data transformation capability matter? When I talk about benefits, I usually like separate from business side and from the technical side. On the business side, this has a significant reduction in cost for any kind of integration and data management activities, which have become a real challenge, as we’ve talked about for a lot of organizations. So by leveraging this capability, they can not only reduce the cost, but also reduce the time, which means they can integrate with more things in less time. This enables teams to have a reduction in the tools and a lot of the overhead.

Morgan Stern • 51:39

They can speed up to be able to take advantage of a lot of these new capabilities and really start to innovate. Some of our customers are using this to avoid vendor lock-in. So by having abstraction in the right places, they can introduce new vendors more easily. It also gives them a common platform to settle on for self-service capabilities. So to expose to their internal end users and their internal consumers, it makes it easier for them to offer a very diverse set of network capabilities. On the technical side, well, this creates a normalized data model, which gives you the ability to do all kinds of automated operations on that data. We see pretty dramatic reductions in software development time.

Morgan Stern • 52:23

We also start to see more teams able to engage because the tools become a lot easier for them to use. And ultimately, it results in much faster and more standardized adoption of multi-domain technologies. So, I wanted to wrap things up and also remind you, if you’ve got questions, you can put them in the chat. We’ll answer them there. Also, I wanted to thank you, Karin, for participating in today’s call. I really appreciate your input, and I want to thank all of you for attending the session and look forward to sessions in the future with you. Thank you.

Karan Munalingal • 52:56

Thank you, Morgan. Thank you, everybody.