What began last year as Puppet’s continuous delivery project, Nebula, has reemerged as an event-driven automation platform dubbed Relay in a bid to support tech teams with day-to-day business.

According to the company’s VP of growth, Alex Bilmes, Puppet Relay is a “full fledged version of Nebula” that evolved through customer feedback. When the company introduced Nebula as a CD tool, it quickly became clear that support for day 2 operations, something that Bilmes calls “Puppet’s center of gravity” and includes tasks like incident response, would be much more needed. 

“Our hypothesis at this point is that the build/test/prod side of the equation is relatively well handled by a number of CI/CD tools out there.” However, applications are made up of a growing number of diverging components from runtimes to cloud platforms to different service APIs. Automating processes that touch many of those elements requires quite a bit of work to make sure everything is properly connected and data handovers are secure.

“There isn’t really a system that is able to respond to the many, many different signals and events that are coming from all kinds of different systems –  whether it’s cloud providers, digital exhaust, various logging, monitoring, things like that,” Bilmes told DevClass.

This is where Relay is supposed to slot in and serve as a “sort of digital duct tape” or IFTTT for DevOps tasks. According to a blog post on the topic, it allows users to “tie a wide variety of services, APIs, and platforms together” (anything with a Relay integration) and “represent any DevOps workflow as code”. 

Workflows are the core automation method in the Relay context, and are made out of “triggers and steps”. While the latter describes the action that should be taken, triggers define when they should be executed and can be started manually, on a schedule, or when an external event happens. An example would be to create a Jira ticket and open a Slack room (step) if a certain PagerDuty alert is fired (trigger).

The choice to have the workflows backed by code surely is music to version control friends’ ears and meant as a nod to more technical users, Bilmes said. “One of the things we’ve seen a lot in low code or no code tools like Zapier and others is they’re very beauty driven. And they’re very much built for kind of less technical users. Our users really want that code-backed workflow and given our roots in infrastructure as code, it made a lot of sense for us to support that as a primary experience. We have visual GUIs to be able to show the structure and to show the runs and things like that, but the actual editing of the workflow itself is code.”

Once the workflow has been defined, Relay listens to events that could trigger operations and runs workflows as needed, while also taking care of things like connection management and monitoring. 

With IFTTT mentioned, weak points of the service that left people wondering why they should hand over their secrets to another service come to mind. “Given that we’re built for a very technical audience, we have a very different architectural model,” Bilmes explained in that context. “At a high level, it’s somewhat similar but we have pluggable secret stores and all types of components that people can sort of modularize and replace.” 

Currently Relay works with its own secret store, but soon there should be the option to hot swap this for whatever an organisation wants to use for that purpose. 

Another issue, things breaking down due to major API changes, should be caught by Puppet’s relationships with other organisations, and the fact that “every step and trigger is a separate container image, [that is] pretty easy to tweak and customize”. 

While this all sounds really useful, the now available Relay beta is restricted to tying together software as a service offerings only, since APIs here are relatively well defined and comparatively easy to handle. However, the reality for many enterprises also comprises local infra, private clouds, and other things not yet covered by the service. It is part of the roadmap though, Bilmes promised. 

“We’re starting with SaaS, and we’re starting with things that are accessible from a SaaS service. We’re sort of approaching this outside-in: we first make it really easy for people to do something – building the product with the funnel, if you will. On our roadmap is the ability to be able to speak to on-premises infrastructure. We’re doing this through a delegate model or an agent that will be able to connect to various on-premises systems. And then we can orchestrate workflows across hybrid, which is both the combination of on premise and cloud, which is what our larger customers really want.”