Luke Lim • 00:04
Hi, thanks for joining today’s webinar. My name is Luke Lim, and I’m one of the solution engineers here at Itential based in the UK, working with our European customers, both in the enterprise and the service provider domains. Today, I want to talk to you about some of the interesting work we’ve been doing with managed network services that are delivered by managed service providers, and some of the real benefits that Itential has brought to them in terms of delivering network services more efficiently and more reliably as time has gone on. I then will look to drill into a specific challenge, one that I think is really interesting and was brought to us by our MSP partners to try and overcome a challenge that seems specific but was actually mirrored across many of their customers. And by using Itential, the… potential for the managed service provider to really partner and collaborate and drive a real culture of success for bringing more automation or orchestration to the network has been realized, and that’s the work we continue to do with our managed services customers. I don’t think it comes as much of a surprise to most of us or a new concept that managed service providers
Luke Lim • 01:18
are a key to enterprises and their customer base. The ever-increasing complexity of networks, the introduction of domains, hybrid Cloud, and edge computing, and all the other things that the enterprise needs is way too complex for the enterprise. The managed service provider is the key to this. They bring a lot of knowledge, they bring the scale, and they bring the ability to be able to deliver high-quality managed network services to the enterprise and continue to be the backbone of some of the largest enterprises in the world. This increased complexity that exists in the network ultimately is a challenge also for the MSP. It’s this area or these areas that Hytentl has had a lot of success with managed service providers over the years to be able to bring more and more quickly, which is ultimately a repeated theme that we all see in the industry. Hytentl plus managed service provider today has made huge gains in addressing the increased complexity of modern day networks, the introduction of devices with different ways of communicating with them, be it element management systems, third-party systems, or directly as traditionally to the CLI itself.
Luke Lim • 02:38
That all comes with the benefits of being able to evolve network automation and orchestrate more of a process end-to-end. And that’s ultimately what we’re trying to deliver here. We talk anecdotally in the industry about delivering network-as-a-service and self-service networking activities. All of that needs to be underpinned by a comprehensive ability to orchestrate process and automate network change. So taking care of the challenge of the cost of integrations, this was always a theme with managed service providers. As the vendor landscape moves, as the introduction of new technologies, SaaS platforms, and all the rest of it comes to four, managed service provider has to be able to work with that and integrate with it. By using itential, they have a platform that is very strong in that domain, and it’s something that we solve for every day.
Luke Lim • 03:33
Then the last couple of bullets here, just talk about the typical types of managed service provider network service delivery that they do. So device maintenance and lifecycle management, version control, and that kind of thing, convict compliance, should probably talk about security in there as well. From this point of view, itential has a long history with managed service providers, has delivered a number of use cases and huge value to our managed service provider customers, in these areas, and will continue to do so. We’re not going to cover these areas in that much detail today. I just wanted to make sure that I put it out there that these are the things we’re doing, and I would encourage anybody who’s perhaps not familiar with itential to have a look at some of the stuff we do here, because it’s very valuable and is a proven value add to our managed services, and then ultimately their own customers. As we’ve mentioned or as I’ve mentioned, the increasing complexity making the network or the need for managed services to be very important is just as big of a challenge to the managed service provider. The great thing to the enterprise is the managed service provider can bring a lot of knowledge to this domain all within the idea, and again, an attempt to be able to offer things back to the enterprise that says, can I request a new circuit or can I request a change to my network?
Luke Lim • 05:03
Can I operate that? Can I deliver that in a self-service manner? The managed service provider today has achieved a lot of things in that space. That’s the knowledge that they bring. But the reality is that there are some nuances or some elements of that change process. that still have to exist manually, that still are operated manually. So the customer might see a self-service portal, they might raise a service request to the managed service provider.
Luke Lim • 05:28
And then there is a whole bunch of work and activity that has to go on behind the scenes, sometimes automated and sometimes manual. What we talk about with Itential a lot of the times is differentiating between network task automation and process-driven orchestration end-to-end. And the idea of orchestrating a process is where I can start to really accelerate the value of network automation. So I can automate my tasks, I can automate things within a particular domain, domain controllers and vendor-specific technology provide a huge amount of automation. And I can also leverage automation assets built by the customer that can then be orchestrated together and fulfill this idea of self-service. And that’s where we’re going with a lot of our managed service provider customers. So back to the challenge.
Luke Lim • 06:20
Challenge brought to us by the MSP customers was not necessarily directly a technology challenge. So, The idea here is the customer has a network that they’ve built over many years. It has lots of nuances, lots of customer-specific configurations or processes embedded in it. And that is very, very difficult to automate and orchestrate across. So we’ve all heard terms like every customer is unique. Every network configuration is unique.
Luke Lim • 06:55
The devil is in the detail. And because of that, I can’t automate and I can’t orchestrate as close to end-to-end as I’d like. So that challenge is something that, along with the technology challenge, our potential is very interested in looking at with our MSP partner, mainly because we knew it would satisfy a lot of requirements, a lot of the MSPs and customers. One of the key areas in looking at this is taking that challenge and thinking, well, as an enterprise, yes, my network might be very specific, it might be very nuanced. I might have very specific configurations that have come from history or just the way that it has to be because of the industry that I’m in and the compliance that I might have to hit or whatever it is. With that specificity, the knowledge of how something needs to be done is not a complete black art. It is known by somebody somewhere.
Luke Lim • 07:52
The challenge is that knowledge may not be documented, it may not be usable in an obvious way. Often and more often than not, what we found or what our MSP partners found is that a lot of these nuances, a lot of this customer specific detail in the way the network is put together has already been built out, has already been automated by the customer engineer, by the enterprise themselves because it just is the way it has to be. An engineer on the customer side has had to automate something in their very specific way, and so they’ve built a script or a playbook or a Terraform plan, if you’re talking about Cloud, to be able to do something very specific in their network. The enterprise has a huge amount of knowledge and a huge amount of value in their own automations. The idea of the MSP pushing collaboration with a customer is where we want to start bringing some of this stuff out. And as the enterprise pushes the MSP to deliver more cheaply and more quickly, what comes with that is more of a culture and more of a push towards collaboration as well. So then the customers are more ready to share their automation assets.
Luke Lim • 09:00
So that’s the challenge, one of the ideas of how it can be solved. And by using the attentional platform, we provide an area or a place where these scripts, playbooks, terraform plans, automation assets are able to be to be shared, produced, reused and managed going forward. And the platform gives the both the MSP and a customer enough confidence that this is something that they can actually use in the long term and promotes a very, very good culture. Before I flip over to the platform, let’s have a quick summary of some of the components we’re going to look at. For those of you on the audience who have familiar attack majority with Itential, you’ll know that the ITENTIAL platform is one of the main components. We integrate very, very neatly with all sorts of infrastructure, CLI-based or not, and it’s the Itential platform where we work through our orchestration. In our low-code manner, so provide a bunch of tools for design time and runtime applications to be able to orchestrate end-to-end processes.
Luke Lim • 10:11
Further down in the architecture that we’re going to look at today here, we have the Itential Automation Gateway. Also part of the platform, also part of what our MSPs are delivering to their customers. Here is where we have our concept of network automation and being able to embrace and work with and manage high-code assets. So high-code assets, again, scripts, could be playbooks, could be Terraform plans. With managed service providers bringing their own knowledge, they can build workflows in Itential platform. They can bring their own scripts and their own knowledge, as an MSP does, to an environment within their own automation gateway, their own high-code assets. And they can build all of those things together.
Luke Lim • 10:56
However, the MSP doing that in their own, as we’ve said, does not allow necessarily some of that tribal knowledge to come out of the customer environment. And the customer, equally, may not want to, at least on day one, be learning new tools that the managed service provider is bringing to the table. So, what the managed service providers and our partners can do is deploy a separate gateway, Itential gateway, which is able to consume the customer-provided intelligence, the customer-provided assets, and then that all gets unified in the ITENTIAL platform, so we can use our platform capability to orchestrate across the top of. And it’s this idea of collaboration, this idea of being able to use high-care assets brought by different teams, different organizations, we can extend beyond two different gateways and we can go further if that’s needed, all with an attempt to, say, to drive collaboration and drive progress when it comes to, you know, the ultimate goal of delivering as close to end-to-end network service delivery as possible. So, innovation is key, innovating these ideas, innovating these kind of processes is key, and with the Itential platform, we’re going to have a look now at how that’s done. So, if we… move on to the Itential platform.
Luke Lim • 12:15
We’ll start here. I’ve got an instance of the Itential platform open. We are looking at Itential Studio or Platform Studio, which is where workflows are done. I’ve purposely started with a blank screen because I want to separate the cool-looking workflow, which we’ll click onto in a minute, but just to show you what the navigation or what the idea of promoting scripts into the low-code orchestration platform is all about. For those of you that have familiarity, you may have seen some of this before, but for those of you that haven’t, on the far left-hand side, we have all of the Itential produced or Itential curated assets. You can have workflows, we can front-end or expose workflows with forms. We can build configuration templates and all sorts of things that enable us to orchestrate and automate.
Luke Lim • 13:14
The other panel you’ll see within the canvas, so I can open and close this, but this little panel in here is all of our integration points. Just as a filling in for the detail, you can see all of the systems, all of the controllers, all of the NMS systems, and whatever else that we might have will all appear on the list on the left-hand side here. This is also where we’ll see scripts, so I’ll come back to that in a second. Another piece of the puzzle that we have is automation gateway. We saw that in our architecture diagram before, our high-level architecture diagram before. So we have an automation gateway here in showing what is conceptually, what could conceptually be the managed service provider gateway. So the intelligence, the knowledge, the scripts that the managed service provider is bringing.
Luke Lim • 14:05
So we see I’m just gonna take any example from here, adtran command.py. I’ll go back to my studio. So I’ll look for that. We can see that that script provided by the managed service provider is in there. It’s actually under the AG manager banner. So we have an automation gateway manager collection of tasks. And this is where we will see all of the scripts that have been pulled into our automation, our platform, our studio are available.
Luke Lim • 14:36
So that’s the managed service provider provided list of scripts or script capability that’s been exposed to platform. And then if we click over to the customer automation gateway, we’re looking at a script here called network ping check. And we’re going to use that as our example going forward is to the customer created and shared asset into the identical platform. So network ping check, I look at, go back to automation studio. I search for that. I can see that we have that script as well. Here is where we start to see the separate automation gateways, which can be backed off to separate repos.
Luke Lim • 15:18
We’ll look at that in a second. All coming together in the platform, which then exposes these items as low-code blocks. Now in the interest of seeing how it works. Now if we have a look at a workflow, a mimicked or dummy workflow, if you like, that’s showing some of the capability in the orchestration platform in Itential. We’re looking here at a hypothetical, relatively simple, but I think the concept will be clear, workflow that says we’re taking an example of a customer change, some incoming data to my workflow. That could be from a ServiceNow change request, could be from a form that’s published in a self-service portal for the MSP, for example. That data comes in and then we decide what kind of change it is in this evaluation task here.
Luke Lim • 16:11
And then we decide, okay, from that evaluation task, I’m going to execute my change, which in this case is a child job. I’m going to run some post-checks as a validation and then I’m going to end. So in very simple conceptual terms, we are looking at a quite simple workflow. As we saw before in the previous screen, our task list appears on the left-hand side. Now I want to say, okay, the customer has provided their automation asset, which was that script. In this case, it’s called network ping. What I want to do is take the workflow that me as an MSP has created and embed this clever, intelligent asset that the customers provided me into my existing workflow.
Luke Lim • 16:59
This could be a new workflow. This could be something that is just an API to front-end to a customer. But in this case, I’m going to use that network ping check script asset provided by my customer as the customer-specific customer nuance in my workflow. All I do, as you saw, is drag and drop it into the Canvas. Then I want to connect it up. If I connect this up, and again, those of you familiar with Itential will be well-versed in what this is doing. I want to take my network ping check, which is ultimately going to be taking some hosts from my incoming data to run this very specific pre-check against.
Luke Lim • 17:44
Then depending on whether that succeeds or fails, I want to choose my path through my workflow. So, again, this is embedding the customer knowledge, the customer-specific script that they’ve written and they manage into my managed service provider end-to-end workflow. So… For those of you from the UK who have seen a TV show called Blue Peter, here are a couple of things that I’ve made earlier. This is really just, I put these in just to expedite this process a little bit. But what I want to do is say, from my customer script, I want to run an evaluation.
Luke Lim • 18:23
And then from that evaluation, I want to decide if it’s a success, I’m going to continue. So my customer pre-check that takes into account the nuances of their environment, hypothetically speaking, is run. If it succeeds, I continue with my workflow. And my workflow, as I said before, will go and decide what kind of change it is and execute that change. If the evaluation fails, so if the customer-provided script actually returns, I’m not happy, so I would rather you didn’t do anything, it’s going to follow the red path. So it’s going to say, I didn’t succeed. And therefore, I’m not going to continue my change, I’m going to follow the red path, which, from here, I’ve said, is a task to raise a ServiceNow incident ticket.
Luke Lim • 19:07
And we can connect up the ServiceNow incident ticket to the end. I can actually remove this transition, because I’m now embedding the customer-provided script and intelligence knowledge into my workflow. And there we have it, a workflow that was doing something with MSP-only knowledge that probably got you maybe 70% of the way there. But by being able to have the customer share their script via their own mechanisms and their own automation gateway, that script can be available as a low-code task block like any other thing in my canvas to be able to be promoted in here and leveraged. As a dummy example of a workflow, that’s how the script works. For those of you that have seen it before, you’re probably not seeing a huge amount of new, other than maybe the way that the script can be brought in and leveraged as part of a workflow. Now I have the script in.
Luke Lim • 20:12
If I go back to the customer’s automation gateway, If I go back to the customer’s automation gateway, I can actually see the script itself. This is the script that has been shared by the customer, has been on-boarded into the Itential platform to be able to be used in Studio. As we said before, in the challenge that this managed service provider has with their customers, customer themselves aren’t necessarily always going to want to be managing scripts and building workflows in Itential, at least not on day one. That might be something that comes later as part of their partnership. What they want to be able to do is say, we’ve already got these scripted assets, and so 99 percent of the time they have a way that they are being managed and they’re being used. The next part of the demo, we’re going to have a look at, so what happens with a script, or a playbook, or a Terraform plan, or an asset, really a high-code asset, that the customer is using and maintaining for the benefit of the overall partnership and for the delivery of the customer’s network, and how that can impact and evolve the ongoing process required to deliver these ideas of self-service orchestrated network change.
Luke Lim • 21:38
Here’s my script, Network PingCheck. It’s in a repository called Client Scripts. Backing off this, we have the customer pipeline. If you now picture me as the customer engineer. I may have very little knowledge of Itential, I just know that I’m working with the managed service provider team who has front-ended an end-to-end orchestrated process and they need my particular automation asset that takes care of my nuances as a customer engineer. I’ll get to the stage where this has been running for three or four months and it’s all fine, but I want to make a change. I’m just going to conceptually do a very simple change to the script and see how that impacts and how it goes back into the Itential platform.
Luke Lim • 22:24
As a customer engineer, again, my interest is in my asset, I’m in a particular domain, I’m a particular subject matter expert in a particular area, so this is the script that belongs to me. Again, script could be anything, it doesn’t have to be this ping script, it’s just an example. So if I were to edit this, let’s say, I don’t know, I’m going to add just another host, just for argument’s sake, into here, 123.4. In fact, let’s do two, 5.6.7.8, why not? So I’m kind of making a change to a script, and then that goes into an embedded pipeline that I have in play, and I have had in play for years as a customer, even maybe hypothetically, maybe even before we partnered with this managed service provider. So if I commit these changes, the only real difference is that as part of the setup of this integration between the customer’s Git repository and Itential, there is an extra pipeline step that will push the script once the changes have been committed into the Itential platform, and then it will be ready to use. So added some additional host items.
Luke Lim • 23:42
just in there. So if I commit those changes, as part of whatever process I had in place, I’ve made a couple of additions which can apply to all my customer-provided scripts. They will trigger a pipeline. That pipeline will push the script back into our potential, which will then make it visible here. So if I come, oops, I come to Automation Gateway and I refresh the script list, and I go back to my network ping script, I can now see the changes for those two additional hosts that I added have been made. And because they’ve been made, because they’ve been validated by the customer’s own process they’ve now been pushed and shared to the orchestration platform, which is itential. And so every time now my workflow up here,
Luke Lim • 24:32
decides to execute the script as part of an orchestration workflow, Itential in real time will go to the relevant gateway, which Itential knows which scripts are housed where, or executed from where, and then it will just execute that latest version of that script. So the ongoing maintenance of that so-called tribal knowledge, there’s probably a better term for it, but that customer-specific knowledge of a process or something that they’re doing can be managed and maintained. in the customer’s own fashion, in the way that they want to, in the way that they always have. All they are doing is providing access to that to be able to execute and use it to the managed service provider. The key being to be able to embed that internal knowledge, that customer specificity into the end-to-end authorization workflow. To conclude, I’d like to thank everybody for their time today. Hopefully, in summary, some of the key items that are takeaways, and what I wanted to show was the need for managed service providers to deliver more and more quickly for the network and managed network services often comes in the way of delivering innovative solutions. Being able to drive services more quickly is only possible with orchestration and automation.
Luke Lim • 25:54
And then overcoming some challenges, technical and sometimes non-technical, is also possible with a platform like Itential because I’m now able to drive collaboration, drive true partnership that actually, I think managed service providers and enterprises alike are demanding of each other.