NFD36: Itential Automation as a Service
Itential announced its new Automation as a Service (“AAAS”) offering at Network Field Day 36.
This service is intended to help customers better add value by leveraging automation and orchestration to productize local coding. The key focus is providing tools to move customers from an Automation and Orchestration mindset to a Productization approach.
Itential sees this as continuing the evolution of automation.
This blog will briefly discuss the new offering, and will refer you to the other NFD36 blogs for more about the potential of this offering. Instead, I’ll shared some screen captures to try to give you a better feel for what the tool does.
Do go watch the recorded videos for details. Watching the demo and other screens with the accompanying explanation will be particularly helpful in understanding the Itential AAAS product
So What Does It Do?
A couple of screen captures and thoughts should give you some idea of what Itential is offering. They lead off by noting that we’ve been writing scripts and doing some degree other task-based automation. These tend to be individual rather than organizational tools, with lifecycle tied to whoever coded them.
Itential wants to shift the focus to Productization, where scripts and code are part of a service-oriented framework that makes them products that can be orchestrated and used by a team of staff.
Thus, their service could be a very useful to take in-house task-specific automation code chunks, perhaps from multiple authors with multiple technical specializations, make them products usable by others, and support orchestration: stitching them together into workflows. All while providing saving part-time coders from having to spend as much time “productizing” their code.
So what? Well, having written some home-grown code, I rapidly learned what may be obvious to the coder is not at all obvious to other users, particularly those who do not script or do not know the programming language used.
In addition, what inputs to provide, constraints on the inputs, what order to run scripts in, and so on are NOT necessarily at all obvious. Documenting it may not help that much: TMI, life is short, people get impatient.
Itential’s offering provides a framework to enable less-technical staff to safely run deployment and other automation scripts on the production network, servers, apps, etc. I understand this as taking home-grown scripts closer to the web front ends we use for provisioning cloud services, for example.
The scope here apparently could be “just” network deployment, upgrade or other tasks. But Itential’s orchestration appears intended for larger scope: namely deployment of new application platforms, locally or in the cloud, or both.
So the orchestration might tie together steps such as configuring physical network or security assets, deploying cloud networking, layering on security rules, allocating server/container/storage assets, and firing up or halting servers or processes.
Itential summarized this as moving automation from “Me to We”: shared automation.
Itential’s Presentations
There were four Itential presentations. Links to the recorded videos can be found at the end of this blog.
Itential started by discussing the evolution of network automation (Presentation #1). They then talked (Presentations #2-4) about operationalizing and orchestrating your automation scripts, and productizing them (i.e. rendering them suitable and safer for lower-level admins to run).
More About Itential’s New Offering
Itential’s new offering consists of cloud delivery leveraging an on-premises component. Specifically, there is a Gateway Cluster on-premises, interacting with the cloud-based Itential Cloud.
Ops staff logs into the local Gateway Cluster (GWC) and executes services there. The GWC reports results. Testing can be done locally on the Gateways, and production use is done by the Itential cloud.
Itential can be used to front-end and “productize” individual scripts, written in various languages and using various tools. In particular, it provides a form-based front-end to the scripts, and does input validation for user entries. This saves script authors from having to develop GUI front-ends, and from having to develop/use a small library of code to do input validation.
Itential also orchestrates complex workflows, where tasks in various technical areas need to be performed to complete a task. This could extend to e.g. deploying a new instance of a application platform.
Either way, it can be used to build a self-service catalog across various technical areas, with tooling to support stitching together the services to perform more complex combined tasks.
A final valuable aspect is to keep Ops staff from needing to log into devices. Ideally they would use the tool, and it handles all CLI or other interaction with network devices.
Demo
Itential demonstrated a workflow that adds a cross-connect to AWS. To do this, three services are used:
This simple demo in principle crosses NOC, SOC, and Cloud Ops team boundaries.
I imagine a more complete automation would also fire up cloud server and gateway instances.
Here is a sample screenshot showing a list of automation scripts installed into Itential. Service Catalog!
One aspect of Itential’s automation is validation of input. Your staff don’t have to write code to validate inputs, nor build a library of tools to do that! Instead, you specify the parameters and constraints in the GUI.
Here’s the sample screen for specifying input parameters and validation criteria:
There is also support for graphically building complex workflows within Itential Automation. A quick example is shown below.
I hope that gives some of the flavor of the Itential tools for you.
Watch the presentations for a LOT more of the detail surrounding the images above!
Pricing
Itential is offering a free trial.
Overall, the pricing is consumption-based. Their assumption is that when scripts are useful, value is easier to justify. And you shouldn’t have to pay for something you’re not using.
As an example, $750 / month gets you 120 minutes of automation when actually using it in Prod. Testing has no cost since it runs locally rather than in the cloud.
I got the impression that production runs might be spinning up servers or containers in the cloud to execute the workflows, hence costing Itential. I don’t recall that much was said about this.
In response to a question, Itential said a way for you to track consumption is in development.
Links
Itential’s home page:
Tech Field Day links:
NFD36 Delegate blogs already posted:
Miscellany
Reminder: you may want to check back on my articles on LinkedIn to review any comments or comment threads. They can be a quick way to have a discussion, correct me, or share your perspectives on technology.
Hashtags: #PeterWelcher #CCIE1773 #NFD36 #Itential #Automation #NetworkAutomation #ServiceAutomation
FTC disclosure statement: https://www.dhirubhai.net/pulse/ftc-disclosure-statement-peter-welcher-y8wle/
Twitter: @pjwelcher
LinkedIn: Peter Welcher
Mastodon: @[email protected]