Relay Public Beta
Published: 2020-06-24 17:29:10

---
title: Relay Public Beta
published: true
date: 2020-06-24 00:00:00 UTC
tags: 
canonical_url: https://relay.sh/blog//relay-public-beta/
---

Today we announce [Relay](https://relay.sh/), an event-driven automation platform. [Sign up now](https://app.relay.sh/signup) and try it out! Relay connects infrastructure and operations platforms, APIs, and tools together into a cohesive, easy-to-automate whole. Relay is simple enough for you to start automating common, _if-this-then-that_ (IFTTT) style DevOps tasks in minutes and powerful enough to model multi-step, branching, parallelized DevOps processes when the need arises.

Why bother? Because for all the progress we’ve made as builders and operators, [things are more complicated than ever](https://landscape.cncf.io/). Modern applications comprise a growing variety of runtimes, clouds, infrastructure platforms, 3rd party services, and APIs. Mounting sophistication ([and complexity](https://www.youtube.com/watch?v=dtI5dMpBmQo)) of how applications are constructed complicates how we operate and manage them. As a result, accomplishing many basic operational tasks can involve touching many different components, with different APIs, different semantics, from different upstreams, vendors and dev teams. Connecting all of these components together is tough, and automating anything across them all can range from tedious to nightmare fuel.

At layers above the plumbing, [managing infrastructure stops looking like classic configuration management and starts looking like orchestrating workflows](https://relay.sh/blog/rise-of-the-apis/). However, workflows can be tricky. Connectivity, secrets handling, event listening, ordering, parallelism, error handling, and control flow all conspire to make writing workflows from scratch pretty gnarly. The complexity adds up fast. We can do better!

> “Automated workflows are the bedrock of all software organizations.”  
> — Jason Warner, CTO @ GitHub

Relay lets you represent any DevOps workflow as code, composed of triggers that listen for incoming events, and steps that define the task you’re automating. Relay does not limit what you can talk to. A single workflow could listen for alerts from PagerDuty, query metrics from DataDog, reconfigure infrastructure with Terraform, and send a notification via Slack. It’s easy to leverage pre-existing triggers, steps, and workflows, and it’s simple to make your own if the need arises.

As a hosted service, Relay supervises things on your behalf. It will automatically trigger your workflow based on incoming events, execute your workflow’s steps in parallel, notify you if you need to intervene, and keep meticulous records of everything done. Relay does this all automatically, so you don’t have to.

Today, we’re proud to announce [beta availability](https://relay.sh/) for Relay. Read on to see how it works!

## Workflows

Relay’s core method of automation is [_the workflow_](https://relay.sh/docs/using-workflows/). Workflows combine useful activities together to accomplish a particular task:

- When we detect an unused Azure Disk, delete it _(so we can save money)_
- When they go unused, nuke any AWS authentication keypairs _(so we can reduce our attack surface)_
- When a PagerDuty alert fires with a certain severity, create tickets in Jira and a room in Slack _(so we can more quickly troubleshoot issues)_

Relay lets you succinctly express these types of workflows, and beyond, [as code](https://relay.sh/docs/reference/relay-workflows/). And like code, workflows can be versioned, reviewed, refactored, and reused. We’re Puppet; [we wouldn’t have it any other way](https://www.google.com/search?hl=en&q=puppet%20infrastructure%20as%20code).

Running your first workflow is easy, and should only take you about a minute. As tradition demands, here’s “Hello, world” ([log in](https://app.relay.sh/login) and follow along!):

![Hello, world!](https://relay.sh/debec11953b60317076234251dc8c4f0/hello-world.gif)

Because workflows are code, you can treat them like code. Modifying a workflow is straightforward. Let’s change the workflow, adding a step to emit the current date:

![Change the workflow using the CLI](https://relay.sh/2105fe13ad95afadea7d0e9dc45e3976/cli.gif)

That covered [getting the CLI installed](https://relay.sh/docs/getting-started/#install-the-cli), authenticating against the service, downloading your workflow, modifying the logic, and then letting Relay know the code is updated.

## Triggers and steps

Workflows contain _triggers_ and _steps_: Triggers determine when Relay should execute your workflow: manually, on a schedule, or when pinged by an external source. Steps represent the set of actions and activities necessary to make your workflow accomplish its goals. Steps are just [containers](https://www.docker.com/resources/what-container), so you’re pretty unconstrained when it comes to what a step can do. Both triggers and steps [are easy to create, remix, and share](https://relay.sh/docs/integrating-with-relay/). With these building blocks, Relay is capable of modeling a huge variety of workflows, and executing them on your behalf. There are a bunch already written, and it’s straightforward to [make your own](https://relay.sh/docs/getting-started/).

Here’s a more interesting example workflow that [cleans up some unneeded EC2 instances](https://relay.sh/workflows/ec2-reaper/). It has more steps, including some that consume AWS credentials, and one which represents a _manual approval_ gate:

![Cleaning up some EC2 instances](https://relay.sh/18f91058f6a39345a357bc6d72855ed8/ec2-reaper.gif)

It’s easy to add, remove, or replace triggers and steps to suit your liking. Some modifications for the preceding example could include adding a webhook-based trigger for the workflow, adding a notification step at the end, or better integrating it into your GitOps setup. Perhaps a step that takes the list of terminated instances, computes their money you just saved, then buys an equivalent amount of stuff from your Amazon wish list? Ops is hard work - treat yourself!

Our examples thus far have shown short, linear sequences of steps but you can also express some pretty elaborate processes just as easily. Here’s a picture of the execution graph of one of workflows we use to manage Relay itself:

[![A more complex workflow graph](https://relay.sh/static/ed787c9f007e7856c5846c98c4c7f6fa/64756/relay-graph.png "A more complex workflow graph")](/static/ed787c9f007e7856c5846c98c4c7f6fa/065ce/relay-graph.png)

## The Relay service

Listening for events and running workflows might appear conceptually simple, but there are a lot of practical details that need to be worked out. Relay’s execution environment (and [underlying engine](https://github.com/puppetlabs/relay-core)):

- Manages [connections](https://relay.sh/docs/using-workflows/adding-connections/) to upstream/downstream APIs and services, making them securely available to the workflows that need them
- Automatically creates [_push triggers_](https://relay.sh/docs/reference/relay-workflows/#push) for your workflows, complete with workflow-specific security tokens, so you can easily kick it off from all kinds of other tools
- Automatically constructs an environment for running webhooks, so your workflows can respond to events from webhook-only services
- Sandboxes workflow and step execution, for fault isolation
- Manages your workflows with all the necessary _ops accoutrements_ (e.g. monitoring, logging, error handling)
- Supervises the execution of your workflows, invoking steps in the right order (with automatic parallelization)
- Standardizes the interfaces between all these pieces so steps, triggers, and connections are reusable and remixable across workflows

Relay takes care of this stuff so you don’t have to. Instead, you can focus on the logic of your workflow, the core of what you’re trying to automate.

After all, isn’t that the point?

## Automation for everyone

How many unique applications are running out there across the planet ([or above it](https://twitter.com/lkanies/status/1182350689529298944))? Thousands? Millions? [Bajillions](https://www.merriam-webster.com/dictionary/bajillion)? How many of them are running on identical infrastructure stacks, built with identical technology stacks, managed in identical ways at an identical scale? There’s a truly staggering variety of approaches and constraints.

If there’s no _One True Stack_, then there’s no _One True Way To Manage It_. The tools you employ should thrive in this sort of world because that’s the world we’ve got.

Relay’s core value lies in letting you tie a [wide variety of services, APIs, and platforms](https://relay.sh/integrations/) together. It’s constructed in a deliberately pluggable way. Users can readily extend the system to talk to new technologies, respond to new kinds of events, and take action in new ways…no CS degree required. Those extensions should be easy to share, so the entire user community can benefit. The ecosystems around the tools we use are every bit as important as the tools themselves.

Even though it’s early days, Relay can already do quite a lot. The future holds many possibilities: new workflows, more integrations with more tools and platforms, higher-level workflow syntax, a more streamlined authoring experience, simplified input/output from steps, and more. Early users have already given us a ton of great suggestions, and we’d love to hear yours!

## Next steps

The next step (and best step) is to [try it out](https://relay.sh/)! And if you’d like to learn more about Relay, you can check out:

- [How to get involved](https://relay.sh/blog/relay-and-open-source/), extend Relay to better meet your needs, and become part of Relay community
- [The documentation](https://relay.sh/docs/) does a great job of introducing Relay, its usage, core concepts, and extension points
- [Peruse some workflows](https://relay.sh/workflows/) to see what they can do. The code and its graphical execution plan are available on every workflow’s page.
- [Slack](https://puppetcommunity.slack.com/archives/CMKBMAW2K) - come linger in the #relay channel! The more the merrier

Thanks, and let a thousand workflows bloom!