A Shared REPL for DevOps

One of the best things to come out of Functional Programming is the Read-Eval-Print-Loop (REPL). The REPL, if you haven't heard, is basically a command line for your programming language.

Even if you haven't heard of a REPL, you've probably used one without knowing it. The most famous REPL is probably the Developer Console in your browser.

Open up the browser's Dev Console and you can evaluate any JavaScript expression in the programming environment of the live browser. Type in an expression and hit Enter: the value is printed to the Console. Any JavaScript that runs in your browser will run the same in the Console, making it an ideal way to try out code in a realistic context.

The Dev Console is a simple and popular REPL that millions of programmers use every day, but, what many don't know, is that this simple interface is the basis for one of the best ways to program that reaches far beyond the browser. REPL-driven programming, for those who know, is a subtle programming superpower.

Our question to DevOps is... What if there were a REPL for DevOps?

REPL-Driven Development

The most graceful way to code.

In REPL-Driven Development, you always put your code in the REPL before you put it in your source file. We, who love this style, like to point out that most of your time spent programming is not writing code, but understanding code. And not just understanding code, but understanding the situation, the environment, the context, and all the components that are used to piece together a system.

Even if you're very experienced, the bulk of your effort is grappling with the unknown—a new library, a colleague's abstractions, or the mysterious cause of a bug. The slowest part of programming is learning, so the best tools should help you explore and discover.

In REPL-Driven Development, when you encounter a new component, you type it into the REPL to see how it works. The REPL responds instantly, in microseconds. You never wait for a build to finish, let alone for processes to initialize or connections to ack.

The REPL maintains the live state of your program ready-to-go, so you can do a quick series of experiments in the real context of the system. Tinkering with the live system is a gentle and efficient way to discover. Never waiting on builds means your experiments are tactile and responsive. The particular behavior of some component may depend on any part of the system's context, so trying it in a realistic setting with a short feedback loop accelerates your learning.

Once you've found what you need—for example, composed a line you want to keep—you drop that into your source code. It joins the system's permanent context, and you already know exactly what it will do.

REPLs are so simple that many people don't notice their virtues. For example, all REPLs come with a built-in history that is tuned to the most natural way of remembering.

Every programmer knows what it’s like to say to yourself, "I wrote a line of code last month just like this... How did I do that again?" The history is natural to use because you can always sort-of remember the last time you did something. You always have a vague sense that it was "about a month ago, on this-or-that project."

With this mental breadcrumb, you grep backward in your REPL and find all your previous experiments. REPLs can be configured to store long-term history, creating a little coder's autobiography. I've found that these records can pay off years later.

Many of the advantages of the REPL are understated like this. Oftentimes, they are too subtle to notice.

Another touch of finesse is that the REPL encourages a coding style that leads to composable, well-structured programs that find the right balance between rigor and flexibility. This is because every time you switch to your REPL, you are only concerned with one expression and how that expression evaluates. You naturally start to build your program in terms of small components that handle the output of other components.

When your program is built up of small expressions that compose with each other, you have a functional-style program. Functional-style programs are easy to understand because each piece is easy to understand. Each piece can also be tested in isolation—it is trivial to write unit tests for code like this.

Starting your program at the REPL is a graceful path to code quality.

A REPL for DevOps

So what does this have to do with DevOps?

DevOps engineers are familiar with some of these REPL virtues because they make heavy use of command line interfaces (CLIs). The command line is not the same as a REPL, but it is pretty close.

The UNIX philosophy that inspired most CLIs emphasized stateless, composable utilities that communicate with each other by piping streams of characters from one utility to another. This UNIX style is in the same spirit as REPLs and pure functions.

Modern DevOps tools far surpass the design of classic UNIX utilities, but almost every DevOps tool still offers command line features. This is because CLIs are cheap to create and always powerful.

Adding a CLI to your DevOps tool turns it into a programming platform, in the same way that an HTTP API can create a web platform. REPLs are even cheaper to create than CLIs, and are even more flexible and extensible.

GUIs may offer a better beginner's experience, and formal plugin systems will be more rigorous, but a CLI will always be the most cost-effective way to expose an interface that is simultaneously human-usable and programmable. That is why DevOps tools still offer CLIs.

DevOps still has CLIs, but DevOps engineers don't gain all their benefits because the tools are fragmented across different environments. DevOps-relevant software runs in or on a huge variety of different data centers, devices, operating systems, programming contexts, and tool-specific contexts. This includes thousands of servers, but also every SaaS dashboard, container file system, source code repository, and every other place DevOps happens.

DevOps tools also have incompatible paradigms, so the muddiest part of the job is when you need to fit those mismatched pieces together.

The Ops Platform: A Shared REPL

The Ops Platform: where DevOps tools are pulled together into a Shared REPL.

By integrating with the Ops Platform, all the wildcats in your DevOps zoo are herded together into nice clean pens.

You build on the Ops Platform by creating one Op at a time. An Op is a logical unit of automation: one component in your system.

A SlackOp is an Op that can be run from Slack. Each SlackOp brings one automation into Slack.

As you create more SlackOps, Slack becomes a central, observable, Shared REPL. We wanted the central integration point to be a REPL so that it would be powerful and flexible. We put it in Slack so it could be shared and discovered.

In Slack, your infrastructure is laid bare for easy control and monitoring. You gain the benefits of the REPL, but not just a solo REPL—this is a Shared REPL.

Sharing the REPL introduces a new dimension of collaboration and auditability.

The Shared REPL for DevOps

Solo REPLs are powerful. Shared REPLs are supercharged.

Slack is already where collaboration and communication happens. Slack is where discussions begin and people love to congregate.

CTO.ai's big idea is that Slack can be a Shared REPL for DevOps.

To achieve this, The Ops Platform needs to bend to accommodate the wildest tools, while being productive, enjoyable, discoverable, and extensible.

You may already separate your business functions into Slack channels. Now, you can split your DevOps into channels, each channel representing one stream of operations activity: talk shop in the place where it happens.

Onboard new hires just by inviting them to a channel. It is easy to learn by watching others run Ops.

No longer fragmented across the Internet, your DevOps tools and workflows are synthesized into one Control Plane, in Slack.

Imagine DevOps with the convenience and familiarity of Slack—that’s SlackOps, and that's our mission:

The Shared REPL for DevOps, in Slack.

We hope you're as excited about this future as we are!

If you'd like to join our free Alpha test of the Shared REPL, enter your email below.

We'd love to see what DevOps in Slack can do for your team!