GenAI is great for Runbook Automation(a.k.a why we Invested in UnSkript)

Disclaimer: This article was not written by Generative AI

The (unmet) promise of workflow automation engines.

In my software career, I have worked on developing at least four different workflow engines for datacenter and cloud automation. Now a simple Google search shows dozens of such products, several of them even open-source. Some of these products work just fine, are extensible, and can scale to manage a very high number resources. Some of them even come with a pretty and intuitive drag and drop interface to complement the workflow language, which is typically a DSL (Domain Specific Language).

Why workflow engines don’t really work.

The charm of these solutions has always been the ability to automate away manual repetitive tasks. However, in my opinion, that promise has never been fully realized. Apart from challenges such as learning a new DSL, lock-in to a vendor, developing custom plug-ins, etc., the biggest obstacle is that someone with a lot of domain knowledge has to first author these workflows in the first place. For anything that starts getting complex, users end up spending more time authoring workflows rather than performing the core activities that they were trying to automate in the first place. Maybe this one-time authoring activity is worth it for a highly repetitive task. However for complex tasks, the context of every new instance of that task is often different, breaking the workflow and requiring it to be edited. If the original author is not around or has left the company, this can be pretty difficult for a new editor to pick up, debug and edit.

Hence workflow engines for Runbook automation are not useful.

A common set of tasks that might make sense to automate using workflow engines are Runbooks used by SREs and increasingly DevOps teams for application deployments and managing runtime incidents on cloud and on-premises infrastructures. Such Runbooks were often captured as textual knowledge and instructions in a wiki. Due to the shortcomings of workflow-engine drive automation, this continues to be the case even today. The last thing an Ops team wants is to be debugging the workflow itself rather than the core incident that they were trying to troubleshoot and resolve.

Generative AI (GenAI) can be used for automatically authoring workflows for Runbooks.

The problem of manually authoring workflows can be greatly removed by using new AI approaches such as LLMs to generate Runbook code. This is not just a fanciful application of GenAI, but I feel one of the most authentic and immediate purposes for which GenAI can be put to work. We are already seeing GenAI co-pilots being used to generate application code.

Runbook generation is an even much more tractable task for GenAI. Runbooks are usually composed of sub-tasks where each task can map to a short snippet of workflow engine code. Generating this in an accurate, bug-free and hallucination-free manner for GenAI is much more feasible than generating longer application code.

Moreover, GenAI can then be used to stitch multiple sub-tasks together to create an entire workflow or Runbook. In particular, GenAI can be really helpful for dynamic authoring or editing of such a Runbook in the context of the current incident, something that would be intractable in the pure manual authoring approach.

Also, there should be fewer Compliance and Privacy concerns with AI generated Runbooks. Enterprises are justifiably worried about using GenAI such as ChatGPT from a privacy and compliance standpoint. Runbook code, however, is often internal use only and hence there are fewer concerns around compliance esp. when it comes to IP ownership. Also with the advent of open-source LLMs that can be deployed on-premises, privacy concerns are also greatly alleviated.

UnSkript’s industry-first GenAI based Runbooks.

Given my past pains and travails with workflow engines, we at WestWave Capital were on the lookout for funding a company that would provide a solution for dynamically generating and editing workflows. And we found exactly one such in UnSkript. What got us even more excited is the Jupyter-based open approach that UnSkript takes. UnSkript generates Runbook tasks in Python or similar lower code scripting languages. These tasks are then run inside Jupyter notebooks. This is a perfect fit for Runbook automation in general, because

• there is no learning of any proprietary language or code. Users can continue to work in their favorite scripting languages
• there is no lock-in to any vendor, including UnSkript. Users can always run their workflows on their own Jupyter notebooks
• GenAI has access to a large volume of code-lets and script-lets
• Humans in the loop can easily curate and modify Runbook code inside Jupyter directly, providing for an extremely agile interface where humans and AI can come together in dynamically authoring and executing Runbooks.

The power of this is immense. For the first time, the potential of workflow automation can be realized if the workflows can be auto-generated and edited with a fast human-in-the loop editing interface such as Jupyter.

And that is why we invested in UnSkript.

Be sure to check out the UnSkript website.

And here is a link to some of their open source Runbooks.