How to Expose Automations to External Applications & DevOps Pipelines for Self-Service Networking

One of the most important topics in network and infrastructure automation these days is getting the most out of your automations by expanding their reach, delivering them to end users in faster, safer, more convenient ways.

This is where self-service networking comes in, bringing the approach that we see in public cloud environments over to our internal network infrastructure. At this year’s Networking Field Day 31, I gave a demo walking through the impact of self-service networking and showing how the Itential Automation Platform simplifies this approach for NetOps and DevOps teams alike.

This demo came at the end of a multi-part session where we showcased how to create a workflow, integrate external systems, and build testing and validation into the automation. You can check out the full series here. For this final part, I took that workflow and walked through a few different ways you can expose an automation to end users with Itential:

• API triggers, which allow an Itential automation to be called from an external IT application or a DevOps pipeline. Plus, add built-in data validation.
• Manual triggers. Here, an end user fills out a form that you’ve built using JSON to take in input variables and validate them before either the automation runs, or an issue is flagged.
• Scheduled triggers so an automation will run on a regular, repeated cadence.
• Event triggers to kick off an automation in response to a change or changes that take place on an integrated IT or network system.

The demo also covers how both NetOps and DevOps teams can expose automations and implement RBAC to provide safeguards so automations can be exposed to others risk-free. Plus, see what it looks like when you call an Itential automation in both a ServiceNow catalog and a DevOps pipeline.

You can jump over to the full demo here, or keep reading for some takeaways.

Benefits of Self-Service Network Automation

I hear about self-service goals a lot from both the NetOps and the DevOps side of things. People say, it’s great that we can build automations, even fully orchestrate processes end-to-end, but at the end of the day, a request to run those automations will come through a ticketing system and an engineer will have to respond manually. Teams are looking for ways to deliver self-service outcomes so everything from request to delivery can be zero-touch.

Itential’s Solution

When you build an Itential workflow, you’re building an orchestration for a process that involves a set of automated steps. That can be packaged up as an all-in-one service using Operations Manager, which is your hub for turning workflows into published automation jobs. You can also include multiple workflows in one automation. From Operations Manager, you select the desired triggers as discussed above.

When we take this different approach that mirrors self-service public cloud services for internal network services, we drive a really significant shift in terms of how efficiently application teams can request and leverage the network. This accelerates innovation across your entire organization.

How to Expose Automations — Without Breaking Your Network

Of course, we can’t just give everyone in an organization full access to make changes to network infrastructure. Even thinking about it is giving me anxiety.

Itential’s Solution

Itential enables you to build governance into your automations, including pre-checks, post-checks, and robust change logging. Then, as part of exposing your automation to end users, there is another layer of access control: authentication and authorization, which can involve SSO, LDAP, tokens, service accounts, and other commonly used methods. This means that access control is wrapped up in your automation and exposure methods so you can ensure only the right users make the right changes, without any manual intervention.

If I’m working in, say, AWS, and I want to provision a new VPC, I don’t email someone, or message them, or submit a ticket. I click on a box on the screen, and I get what I need. But wrapped up in all of that is the access control that I have — if I try to request a service I’m not allowed to, it just won’t happen. That’s what we’re providing for all of your network services: the confidence you need to “give up” your automations, without actually giving up control.

Exposing Automations to External IT Applications & Pipelines

When you have the requisite guardrails built in and you have the confidence to expose network automations to a wider audience, you’ll see usage rates for your automations skyrocket. IT teams, application teams, and others will be able to skip the usual roadblock that is requesting an internal network service, and DevOps teams will be able to collaborate more effectively with NetOps teams, which is especially important as the line between on-premises and cloud continues to blur.

Itential’s Solution

I’ve already covered how you can attach an API endpoint to an automation so you can call it from an external location such as a DevOps CI/CD pipeline. This API trigger is also how we expose automations to your organization’s ServiceNow environment—but there’s a little more going on there.

For organizations that use ServiceNow (is that redundant?), we’ve streamlined the entire exposure process with Itential’s ServiceNow Application. This is the easiest way for your IT end users, who live and breathe ServiceNow, to easily leverage network and infrastructure automations published by NetOps and DevOps teams without leaving the ServiceNow ecosystem.

By offering these capabilities, we’re aiming to make automation as easy to adopt as possible so that it only enhances your work and your organization’s efficiency. If an automation solution asks for all of your end users to change up how they work, then what happens is really simple: people don’t use it. Exposing automations to external applications is how both NetOps and DevOps teams can level up the impact of this work. You’re taking something that used to delay innovation and turning it into a driver instead.

Want to see self-service network automation in action? Watch my NFD 31 demo here, or look at the full NFD 31 demo series here to track the journey from a blank canvas all the way to self-service exposure.