Rich Martin • 00:04

Hello and welcome, everyone. Thanks for tuning in. My name is Rich Martin, your friendly guide for all things technical marketing at Itential. Today, we’re going to continue a session that I’m super excited about when we started around operationalizing and sharing automations with the Itential Automation Service. If fun was illegal. I am super excited to be joined by my criminal co-conspirator, Peter Spergata. Peter, give us a couple of bits about yourself.

Peter Sprygada • 00:35

Yeah, thanks, Rich. It’s great to be back. I’m super excited to see what kind of trouble we can cause on this particular episode. So yeah, for everyone joining, again, my name is Peter Spergata. I’m the chief architect here at Itential. And I spend a lot of time really just focusing on the direction of our product portfolio and really just thinking of new and innovative ways that we can build products and solutions to really help you address your automation and orchestration needs. Well, that’s great.

Peter Sprygada • 01:05

That’s really what I’m dealing with.

Rich Martin • 01:06

Yeah. And so, you know, innovative and fun, for sure. And I think that’s exactly what we’re talking about here is something innovative. And as a continuation, we are really wanting to double click into this session on what it looks like to use the Itential Automation Service. In our last session, we kind of did a deep dive. We talked about the personas and the challenges. We’ll recap that a bit, but really what we want to do again is kind of take these roles again.

Rich Martin • 01:35

And the persona really is a very natural one for me as Richard, the operator coming from a network engineering background. And of course, Peter, who are you in this drama?

Peter Sprygada • 01:47

Yep, so I’ll continue down that path as the developer here that’s really focused on just simply writing automations. I’m not much of a network guy anymore. I’m just a developer who writes code, but I’m here to support you and your team and make sure that you’ve got the things that you need to be successful.

Rich Martin • 02:05

Okay, well, let’s jump right in. And I’m gonna need you to kind of set the groundwork here in the framework for what are we looking at? Now, I see we’ve self-censored ourself a bit, but I feel like there’s a strong feeling behind this slide. So why don’t you walk us through this? And I take it this is from the perspective of the Peter, the developer.

Peter Sprygada • 02:25

It is, you know, and here’s one of the challenges, you know, that, that, uh, you know, I faces as a developer, you know, it’s like, I love writing code, I build a lot of code, I love solving problems, uh, you know, and network automation problems are some of the tougher ones to, to ultimately be able to have to solve, you know, with code, but you know, the, the, the challenge with, um, you know, writing code to talk to the network is how do I ultimately get that code in a place that allows Richard and his team to be able to use it in their everyday life, right? Because as developers, you know, most of us don’t write code to not be used. We write code to be used, right. And to solve problems, that’s why we write code. But the, you know, the challenge is I’ve got a lot of different ways to write code and depending on what it is I’m trying to solve, I’m going to use different tools. In some cases, I may want to go really hardcore and, and write just native Python code with, uh, you know, with libraries like net Miko or Nornir and be able to really focus on, you know, solving very complex problems, uh, using a language like Python. In some cases, I might be attaching some cloud-based stuff to it and therefore it, I just gravitate naturally as a developer to, to leverage any Terraform because I don’t have to write every line of code. You know, I want to use, use the tools that are out there and use them in the way that they were intended to be used. And then of course, you know, with me and my history and my background, you know, I’m always partial to writing Ansible playbooks and being able to leverage, you know, the massive ecosystem that is Ansible and leverage, you know, the ease of use of developing playbooks. But here’s the challenge that I really have. It’s that I can write these things, I can run these things, but how do I get them built in such a way that the organization can start to coalesce around them, right? But how do you, Rich, you and your operations team be able to use these things? And so I start looking at each one of these things, and what I tend to find is that there’s really only one way to operationalize, or there’s, let me say it differently, I have to vertically operationalize each one of these things. What do I mean by that?

Peter Sprygada • 04:25

Well, I mean that for all of my Ansible playbook work, I kind of have to go out and make my investment in Ansible Automation Platform. And then for all my Terraform stuff, I might be looking to deploy Terraform Enterprise. And then for all my custom Python stuff, maybe I’ve got to go buy an off the shelf package. Maybe I’ve got to add more development time. Maybe I have to find other developers who are proficient at building UIs and APIs and application middleware and so forth. And so what I end up finding at the end of the day is I’ve got a vertically integrated stack for every single one of these tools that I’ve had to go out and build just for the sheer purpose of being able to get your team to start investing in making use of this stuff. And then of course, in turn, now you’ve got the challenge of back into the swivel chair world of, if I want to run Automation X, I’ve got to use Ansible Automation Platform versus Automation.

Peter Sprygada • 05:17

Wow, wait a minute. No, that was written in Python. No, wait a minute. That one was written in Terraform. And now it’s like we get into this tough space of it’s like we’ve just added an awful lot of complexity and awful lot of costs just simply because we wanted to operationalize all of these scripts that I’m writing.

Rich Martin • 05:31

Now, this is interesting, and I don’t think you’re blaming Richard, the operator here for all of this, but I think it’s interesting. How does one find themselves into this situation? For instance, you were the brave soul that said, hey, you know what? I know some networking. I know some development. We need this. This is a gap we have, being able to automate network things.

Rich Martin • 05:54

I’m going to step into this role and do it. It sounds like on the left-hand side here, you’re picking the fun tool of choice you want to use, right? Because there’s some fun in that. You like to write code. You like to see it being used. How does somebody find themselves into this poor soul on the right, struggling with the burdens of these heavy boxes that they have to lift?

Peter Sprygada • 06:12

Yeah, I think that you’re absolutely right and that is the important takeaway here is that it really all starts and if you think about where this journey started, right? This journey all started with maybe all I ever did first is I wrote a very simple Ansible playbook or a simple Terraform plan or Python and then as I got more used to the tool and I got more comfortable with the tool and as my use cases became more complex and I became more comfortable attacking more complex use cases, bigger use cases, I may have decided that certain tools were better equipped to handle those problems and therefore that’s what I start doing. But what I started to realize is that in order for me to actually operationalize this thing, in other words, for me to convince Richard’s boss, the operations manager, that I want to attach my code to the production infrastructure, he’s going to tell me that, okay, but I need logging and I need enterprise control and I need integration with SSO and I need, you know, and his list is getting longer and longer and longer and I’m looking at this thing and I’m thinking, oh man, now I got to go build all of these different bespoke ways of interfacing with all of these different things. Wait a minute. I’m a network guy, right? That’s, I mean, I write network automation, that’s what I enjoy doing, but I don’t really want to go and build and maintain my own SSO system. I don’t want to go build and maintain my own logging system.

Peter Sprygada • 07:31

There are plenty of things out there, but I also don’t want to have to buy a commercial package for every single one of the technologies that I made a decision to invest in.

Rich Martin • 07:39

And that’s a great insight too, because this, you know, depending on where somebody else is in their automation journey, so to speak, we might be giving them the insight that they don’t normally have, which is how to avoid technical debt.

Peter Sprygada • 07:53

That’s right. That’s right. That’s right. Because I mean, right. And, and, and, and, but that’s the point is that every single one of these, you know, let’s just, let’s just stop. in a fantasy land for a minute and assume that money is no object and therefore sure I can go buy all these commercial systems. Sure. No problem. But I still have to build them. I still have to maintain them. Right. That’s, you know, and that’s taking time away from me from being able to actually focus on solving problems.

Rich Martin • 08:17

Right. And that’s precisely what we want to show folks today is with a solution that we’ve come up with. It actually, you know, helps both sides of the equation, the team of Richards and the team of Peters get the job done that they’re focused on doing and not have to spend extraneous time helping one another in a way that we should. We really don’t need to be helped. We really need to focus on the things we need to get done. And from our perspective as the operator, don’t tell me you’re going to get me out of the world of dashboards and swivel chairing and then give me a new set of dashboards to swivel chair around. Right. That’s not helpful. And that’s not a good relationship, Peter. It’s not. You’re absolutely right. It is not. All right. Well, then let’s let’s land on what we’re talking about here with what you get with Itential.

Peter Sprygada • 09:08

Yeah, so we’ve thought about this problem a lot and we really thought about how do we bring together a singular service that works for both the developer side of the NetDevOps team as well as the operator side. And that’s really kind of where Itential Automation Service came from. We really wanted a service that was both SaaS delivered but also had an on-premises component, which is what we’ve delivered, and it really focuses on tapping into the key capabilities of both of those teams, because honestly, you need them both to run your infrastructure. You really do. They exist for a reason in both of them, but they both have very different needs. For instance, on the NetDevOps side, we really want to be able to work with a platform that allows us to deliver on a single platform for executing our automations. In other words, I don’t want to have to learn different ways of writing code just simply so I can integrate it with a platform.

Peter Sprygada • 10:03

I want to focus on writing my code. committing that code and then publishing that code. That’s really what I want to focus on. I’m going to use Git for that. I think the industry is de facto standardized there. But I also want to be able to not only standardize on my source control, but ultimately be able to standardize then on that platform by which I run on. Conversely, on the operator side, the reality is, and correct me if I’m wrong here, but I don’t think you really care what language.

Peter Sprygada • 10:32

I decided to write any given use case.

Rich Martin • 10:34

You hit the nail on the head. I don’t care and I don’t want to know. I just want to be able to run the thing and make sure it runs well and know what’s going on.

Peter Sprygada • 10:44

Exactly. With the web service then over the top of it, we now have the ability to publish those automations and share them really with the team. As I’m writing things in real-time, we can have the web service being updated based on what I’m doing and making new capabilities available to your team, fixing maybe bugs in current implementations, whatever the case is. But doing it in such a way that doesn’t require your team to sit down and have to relearn a new tool, a new way of doing things, a different way of doing things, just to simply be productive and continue to do what you do and that’s operate the infrastructure.

Rich Martin • 11:22

Yeah, that’s fantastic. Let’s take a little deeper click into what this looks like. Walk us through what’s going on here. This is behind the scenes of what we’re talking about. If you go back to our previous session, we get really into the nuts and bolts of this. You can see it, but walk us through the high-level code. Now, you already mentioned in the world of the developer, the builder, the automation engineer here, what are those three steps that they like to do?

Rich Martin • 11:48

Write code, commit code, publish code.

Peter Sprygada • 11:51

That’s right. That’s right. Because that’s the world I’m living in now. It’s all about I’m writing, again, whether it’s playbooks or Python scripts or whatever it is. It’s like I’m writing code, I’m getting that code committed to my Git repositories, and I’m making it available for the operations team. But again, I want to be able to do that on my terms. I don’t want to have to have a prescriptive way that is defined by the operations tool in terms of how I write that code. I want to focus on the problem, I want to pick the right tool for the job.

Peter Sprygada • 12:20

And then I want to write the code to solve the problem and then make it available. That’s really what I want to do and be able to really operationalize my automations in a very uniform way really across any technology.

Rich Martin • 12:37

Right. And then the intersection point between what you do, Peter, and what I do, or the team of Richard’s do, right, as the operator, what is the technology here that we’re looking at that helps bridge that gap between the two?

Peter Sprygada • 12:49

Yeah, and so that’s where we see the attention automation service. So basically available through our attention cloud, that is the SaaS based UI interface that you can use as an operator for launching services. So they get exposed from gateway and then you can execute them. So as I’m doing my work, things are updating in real time within gateway. And this includes everything from not only making the service available, but also defining what the input parameters look like through something we call decoration, through ultimately being able to dynamically build environments, right, which is another key element. I don’t want to spend my day having to make sure that every gateway I deployed in my infrastructure has the right versions of every library under the sun. It’s really just a scenario by which I want to focus on solving my, my automation use case by writing code and then making it available.

Peter Sprygada • 13:39

Conversely, right, you don’t want to be in a situation where you have to intrinsically understand that it’s this type of automation written with this technology. So my input is going to come this way, right? You simply want to run it. You want a very consistent framework to run within because that’s what you can then build into your standard operating procedures, which is really kind of what drives your operations team.

Rich Martin • 14:00

Precisely, precisely. And I think that that’s interesting to note here. And the one last thing maybe that I’ll ask you about is how intrusive is this solution to your day-to-day, you know, operation as a developer? Meaning, are we asking you to jump through lots of wild hoops in order to integrate your, your code into a network service? Thank you.

Peter Sprygada • 14:23

You know, that’s the beautiful part of this is, you know, when we set out to build this technology, this was a kind of a defining principle that we put, you know, on the table, so to speak, proverbial table, you know, day one, and that is, we wanted to build this technology in such a way that empowered the net DevOps or the automation engineer, whatever title that individual may hold, to be able to build the automations they need to build and not be encumbered by the framework or the technology by which they build them on. And that was really kind of the mantra by which we went forward with. So as I’m sitting there writing code, and I’m thinking about how best to solve certain problems, honestly, I can stay very focused on just doing that and not have my hands tied by, oh, I really want to do X, Y, and Z, but the platform will only allow me to do X and Z and so forth. You know, we got to throw Y out, I really can focus on just solving problems.

Rich Martin • 15:14

Fantastic. All right. Well, I think with that, that’s a great leeway into let’s taking a look at what the actual demo looks like. So I’m going to don my full operator persona now as Richard, and let me share my screen. And if I can figure that out, we will continue.

Peter Sprygada • 15:32

Yeah, always the challenging part. There’s always the two challenging parts. Can I get my screen shared and can I talk and type at the same time?

Rich Martin • 15:40

Okay. So like you just said, as an operator, my insertion point into this solution is through the web front end, right, to the cloud front end that allows me to run the automations, the automation services that you’ve created for me, right? And so what am I looking at here now?

Peter Sprygada • 16:01

So this is actually, this is your screen to a degree. We’re looking at the operation screen, but this screen is actually custom tailored to you. What I mean by that is, what you see here is what you’ve been given access to. So within the application, we can control who has access to what, and so this becomes over time your screen, and these are the things that you can do on the infrastructure. You can see what are the things that I want to run, what are the things that I have run, what are currently maybe things that are scheduled to run in the future or are currently running. These are all things that you can do from the operations screen.

Rich Martin • 16:39

Okay, fantastic. Now, from what I was told in a Slack message that you’ve created an automation for me to run, I really appreciate that and I’m excited to see that. So why don’t you walk me through as an operator this new automation service you’ve created for me. Where do I need to go here?

Peter Sprygada • 16:56

Yeah, absolutely. So as we talked about, right, we needed an automation to ultimately collect the running config. Correct. I don’t know why, but obviously you need it for something.

Rich Martin • 17:05

You don’t need to know why. That’s our business. I just need your help in automating it.

Peter Sprygada • 17:11

Fair enough, fair enough. So we could run it from here, but I’m gonna have you go to the automation screen on the left-hand side, and that’s just gonna list again. It’s just another view, and it shows you all the automations available. You’ll note that there’s a new one here for you.

Rich Martin • 17:23

You’ve been very busy for us. We really appreciate this.

Peter Sprygada • 17:26

I have, I have. Remember that, remember that. So yeah, so we’ve added a new one here called show running config. Yep, there it is. And so if you go ahead and click on that, we can go ahead and launch that. So you can run this against any host in your infrastructure. You just simply plug in the host name or the IP address.

Peter Sprygada • 17:43

Okay, I’ve got one right here. Surely go out and grab the running config for you.

Rich Martin • 17:48

All right, well, let’s take a look and see what you’re… what your wizardry has given to us. I know that once that’s run, I go to activities and we get the output here. That’s correct. Let’s take a look. I gave you the command to run. You ran it. That looks great. I wish I could say we were done here, Peter, but I have a little issue.

Peter Sprygada • 18:12

Okay.

Rich Martin • 18:12

Yeah, and I don’t expect you to know this, but I’m going to tell you now, I can’t expose this with that password there. So what I need you to do is I need you to obscure that.

Peter Sprygada • 18:27

Oh, yes. OK. I think I yes, I think I remember. I remember something along these lines.

Rich Martin • 18:33

I know it’s been a while since you’ve actually been in a real network. Yeah. Or land. But but yeah, we you know, I could have access to it, but there are other Richards on my team that should probably should not see that.

Peter Sprygada • 18:45

I understand. Well, give me give me just one moment here. I can actually just update the script on the backside. And, you know, that’s the beauty of this, right, is that I can actually go in. I can actually make updates to the script completely independent of anything you’re doing and make them available to you almost instantaneously. So let me go ahead. And this will only take a minute. Let me go ahead and push my change in to get. So I wrote my code.

Peter Sprygada • 19:06

I’ve committed my code and I’ve just published my code. So right now, if you go ahead and try and run that again, let’s see if this captured kind of what you were looking for.

Rich Martin • 19:16

1. All right, so I’ve just executed it.

Peter Sprygada • 19:23

And so that’s the beauty of what Gateway is doing is it’s actually pulling this code in real time. So even though I just published it to Git, I didn’t touch the server at all. I didn’t touch the web service, obviously I didn’t touch the web service, I don’t own the web service. All I did is I made a change to my script and I just published it to Git.

Rich Martin • 19:39

And I think from your perspective and my perspective, we’re both benefiting from the fact that this is not a complex process, right? I can literally sit here with you and help you tune this code. I don’t need to know the code. I don’t want the environment that it runs in. I want to be able to, quite honestly, click the button, fill out the form, and get the output. And if it doesn’t look right, I need to talk to my buddy, Peter, so that I don’t have to call him on a Saturday while he’s watching the game, right? That’s right.

Peter Sprygada • 20:08

Like you did last time, by the way.

Rich Martin • 20:11

You’re welcome. But we all suffer. When I suffer, we all suffer. So that being said, right now, we were able to go through and update the script. I get it in real time. My job’s easy, quite honest with you, right? I’m the consumer here.

Rich Martin • 20:28

And all I have to do is just wait for you to do your work. But your work doesn’t necessarily… isn’t necessarily, if you’re doing things a different way, this easy, right? And I think that’s the critical piece here. Now, that being said, Peter, I don’t want to make your job more complicated. That being said here, I am super excited about this. This is useful. My team is going to be excited.

Rich Martin • 20:51

But I know what’s going to happen. There’s this particular Richard on the team that is going to come back and say, I need to be able to see what the defaults are set to. And I don’t have a way to do that here. You’re just showing me what’s changed. I’m just showing you what’s changed. Can you update this to give us the option so that we can look at what the defaults are set to?

Peter Sprygada • 21:09

So, yeah, let me ask you a couple of questions here. Just I want to make sure I confirm, you know, kind of what we’re looking for here. So my understanding is, you know, this solves your use case, but kind of now you’re asking for the ability to see the equivalent of show running with the defaults.

Rich Martin • 21:26

Correct. And I know this is kind of an add-on. It wasn’t the original ask, but this is going so well. And I can see how quickly you can churn updates out. I think this would be very helpful because, again, I know there’s a Richard on my team that’s always wanting to see the defaults.

Peter Sprygada • 21:40

And do you need the updates? He said the updates. Do you need the defaults every time? No, no, no, no, no, no.

Rich Martin • 21:47

Actually, most of the time it’s this. But there are certain cases where we need to see the defaults just to double check without assuming. OK. All right. Yeah.

Peter Sprygada • 21:55

Well, I think I think we can do that. I don’t think that sounds too bad. Let me quickly here make a couple of changes on the backside. And I think that we can we can do this. So I’m actually going to make a change here to give you a new new option that allows you to select the default. So give me just a minute to finish up my my coding changes. You go right ahead. I’m writing my code and getting it getting it committed.

Peter Sprygada • 22:20

All right. So we’re just waiting for that to up. Okay, good. So I’ve just published all the new code, and so I’ve given you a new option. So if we go ahead and take a look at our same job here, the show running job.

Rich Martin • 22:33

Okay.

Peter Sprygada • 22:35

You may need to refresh your screen so it can pick up the latest changes in the web UI. But now.

Rich Martin • 22:43

Okay. I see something different here.

Peter Sprygada • 22:45

Yeah. So this is another great example of, I was able to just update the repository and simply by the update of the repository, I’ve added giving you a new checkbox here for turning on or off the need for defaults.

Rich Martin • 22:58

Yeah. And by default, it’s off. So that’s fantastic. Because that’s normally what’s going to happen except for that one Richard.

Peter Sprygada • 23:04

Of course, now the million-dollar question is, does it actually work?

Rich Martin • 23:07

Of course it works. You’re batting 1,000 with me now, Peter.

Peter Sprygada • 23:13

Now all of a sudden you like me. I love you, Peter.

Rich Martin • 23:16

You have made my life so much easier. Look at what we got here. Thank you very much. This is precisely what we need. Now I can keep that Richard quiet and all the Richards happy. The other Richards on the team happy as well.

Peter Sprygada • 23:32

Excellent, excellent. And, you know, from my standpoint, it was literally it really wasn’t too bad. It was, let’s see, one, two, three, four line update to my Python script, a quick change in my decorator, publish it all to my Git repo. And this is all there was to it. Make it available to you in the web UI.

Rich Martin • 23:49

And so, and so, and that’s the point, right? The point here is to make it easy for both sides of these teams. In our first session, Richard and Peter didn’t get along too well, right? That’s right. You know, there was some natural friction between us. We didn’t understand each other’s technology. Like, I just need to run the automation.

Rich Martin • 24:09

It must, from my perspective, this should be simple. And then we find out it’s not that simple, right? If we’re trying, if I have to build the environment, basically I have to be like a developer light in order just to run certain automation, certain scripts, things like that. So in this case, this is really where we bridge that skills gap. It’s a skills gap that doesn’t need to exist between the teams just in order to run an automation. And we want to really present an interface into the solution from both sides that works for them, not asking them to do something outrageous, out of bounds, or just wacky, just to integrate into what we want to do. We want to integrate with what you guys do.

Peter Sprygada • 24:47

Yeah, that’s exactly right. And I think that by really focusing on having a component that is well in tune with the developer side and a separate component that’s well in tune with the operator side, it really just kind of makes the whole system flow in a much more natural way. Or I’m not asking you to learn my tool. You’re not asking me to learn your way of doing things. We can both focus on what our job is and focus on really just solving problems together as opposed to fighting over what is the right tool or the right way of doing things.

Rich Martin • 25:24

Yeah, no, that’s great. And I just think it’s a great way to end the demo unless you’ve got something else you wanna mention or add.

Peter Sprygada • 25:32

No, I don’t. I think, you know, I think the, you know, this really tries to show how we’ve created that separation. And again, just trying to create more of that, that natural and seamless integration between what our capabilities are and how organizations and teams want to work together to ultimately solve, you know, some of the networking challenges with automation.

Rich Martin • 25:53

Yeah. You know, and I’ll add one last thing here too. You know, there’s a lot of technology behind this. We’ve covered it today’s session. We’ve covered in that earlier session together, especially with the CLI and the behind the scenes on the gateway side of things. But you know, what’s interesting here? There’s a, there’s a, you know, maybe this is the marketer in me while I can’t technically marketing market this, maybe this is like a, you know, building better relationships between coworkers as a service.

Peter Sprygada • 26:20

Well, that’s one way to look at it. Absolutely. Absolutely.

Rich Martin • 26:26

Well with that, if you have found anything exciting about what we’ve been talking about, you will be even more excited to find out you can try it for free. Yes, free, no credit card required. You can take a look at any of the things we’ve done, we’ve talked about. And all you have to do is go to Itential.com forward slash free dash trial, Itential.com forward slash free dash trial. Once again, thank you very much, Peter. I really appreciate your time and your energy and having fun with this because it is innovative and both fun, I think for both of us.

Peter Sprygada • 27:02

I agree. I appreciate you having me on board. And yeah, this has been fun, but hopefully it’s also, you know, kind of touched on a bit of a nerve, you know, out there that this stuff is real and, you know, can really solve some real challenges today.

Rich Martin • 27:17

Absolutely. Well, thank you again and thank the audience for tuning in until next time we’ll see you. Bye-bye.