Accelerating Time to Value with Section’s CLI

The command line continues to be an essential tool for developers. It helps developers get more done. There are multiple benefits of a more responsive, faster UI. Systems hygiene tasks such as managing local processes and source control are frequently done through CLIs. Many cloud computing services, continuous integration products, and increasingly APIs now have their own CLIs.

Introducing sectionctl: Section’s CLI Tooling

Here at Section, we recently built and released our own CLI tool, sectionctl. We built sectionctl while launching our Node.js Edge Hosting solution. We wanted to create a developer-friendly experience for getting your Node.js applications running at the network edge.

“We are trying to make an unfamiliar experience a familiar one.” - Lindsay Holmwood, Director of Product, Section

We went through a couple of different ideas for how to approach this, and settled on the CLI utility. We realized that there were several small steps that needed to be followed before the Node.js edge app could be launched. These include:

1. Issuing certificates - When you set up with Section, you automatically receive free SSL certificates for all your apps. When building a new onboarding workflow for Node.js apps, we decided to automate the step of issuing the certificates. We have now added this to sectionctl.
2. Setting up domains - We want to let you easily see which domains are mapped to which applications. When you run the final command to deploy the app (sectionctl deploy), there are multiple arguments to parse. Since you may not know your account ID, application name, etcetera, this step makes it easier to see that information. Plus, if you have other workloads outside the Node.js experience – for example a more traditional CDN workload – sectionctl works really well for that too.

We went for a CLI partly because we wanted to make it easy for you to see all your applications, domains, and certificates in one developer-friendly package. We decided it was better to build a small Swiss army knife of tools to do all these things as opposed to pinging people between a web interface and a CLI to perform different tasks.

Our Developer Goals with sectionctl

sectionctl isn’t the first command line utility that Section has had. Back in the early days of Section, we had a CLI that was written in Ruby, which was essentially a helper for each of your apps. It involved quite a different way of working when compared with sectionctl – you had to be in your Section config repo to run it. Since it was written in Ruby, there was also quite a bit of set up, maintenance, and dependencies to manage to get it to run.

We took a different approach with sectionctl. We wanted a single binary you can easily download and install. It’s completely self-contained. We’ve tried to emulate other modern CLI experiences, in particular the Heroku CLI and kubectl from Kubernetes (which helped inspire the name). We wanted to provide a familiar developer experience to people who have never used our tools and platform before.

We’ve deliberately built in user experience patterns and in-app help to make it easier to interact with CLI utilities. One such example is tab completion. If you’re typing code and get stuck, you can hit ‘tab’ to get feedback from sectionctl with suggestions for which flags you can use to do your deployment. As developers, we spend so much time in the console getting stuff done.

Our ultimate goal for the developer experience here, as with the entire Section platform, is a simple, flexible developer experience that puts you in control. We wanted to build something that devs could enjoy working inside, benefitting from a feeling of familiarity despite never having used it before. We’d like people to have the same comfort they get when deploying an app to the cloud when deploying to the Edge with sectionctl. The challenge for us was to do the hard work to make solving problems easy for users.

Using sectionctl for Ongoing Management and Observability

While we built sectionctl specifically for the app creation and deployment process, we quickly realized that after the first 30 minutes when you have a real app that’s up and running, you’re going to need insight into what’s happening inside it. We have integrated two features for precisely these tasks: (i) sectionctl ps and (ii) sectionctl logs.

sectionctl ps
The sectionctl ps command lets you see the state of an application. It will return the status of all the different workloads running on Section’s Edge.

sectionctl logs
The sectionctl logs command lets you see deep into Section’s infrastructure, piping the logs from all edge endpoints back into your terminal. This allows you to see the complete log output of your app, both in the normal access logs (HTTP) and at an application level (error, warning, and debug logs).

We see both of these features as a critical part of the ongoing maintenance of your apps, letting you see at a glance how they’re deployed and functioning, so you can quickly discover which weird and wonderful errors you need to deal with!

How sectionctl and Traffic Monitor Work Together for Observability

The Section Traffic Monitor and sectionctl work together by, on the one hand giving you a summary view of your traffic, and on the other, a more granular view of your application performance when you need it.

The Traffic Monitor provides a visual experience to understand how your workloads are being deployed in different regions. This dovetails with sectionctl logs, providing deeper insights into what’s happening inside your edge workloads. This allows you to view all the output from all the workloads running on the Edge, providing an extra level of observability and debugging.

In the sectionctl logs command, we provide flags to let you filter by output. By default, when you specify your app, you are immediately drinking from the firehose, seeing all the edge endpoints your app is running in. Even if you are getting a reasonable number of requests, you will be obliterated by the sheer amount of data. The flags let you specify what you want to see so that you can get specific information about a particular endpoint, application ID, etc., making it easier to narrow in on an instance of a problem.

Looking Ahead

While we built sectionctl specifically to help users get their Node.js apps running at the edge, it has a huge amount of applicability to other workloads, such as databases – the holy grail of persistent storage at the edge.

We think about databases as another type of workload running alongside an app. We’re expecting that people will use sectionctl to get a database running, attach it to an application, and set up global replication of their data at the edge. We’re excited about what sectionctl is going to help people create.

If you’re interested in testing out sectionctl, visit the sectionctl documentation to get started.