Introducing sls-dev-tools — Improving the Serverless developer experience.

Ben Ellerby
Dec 16, 2019 · 4 min read
Image for post
Image for post
https://theodo-uk.github.io/sls-dev-tools/

Having led several teams running 100% Serverless infrastructures in production there was a clear area of the Serverless developer experience that could be improved.

In short, it’s the feedback loop of deploying a function code change and getting visibility on if it’s been called, what the metrics are looking like and having quick access to any logs.

Taking inspiration from the frontend developer experience we wanted to have an equivalent to chrome dev tools, but for our backend Serverless functions.

Image for post
Image for post

I’m very pleased to announce the early-stage release of Serverless Dev Tools (sls-dev-tools). It’s completely opensource, solves a few core pain points for our team — and has a lot of features and improvements that we can build out in an opensource community.

What is sls-dev-tools trying to do?

It’s trying to allow developers to get feedback and metrics on their function deployments without opening the cloud provider web console (in our case AWS) — staying in their IDE and terminal.

What sls-dev-tools isn’t trying to do?

sls-dev-tools is not trying to provide complete Serverless Observability in your staging, UAT or production environments. It is not a distributed logging visibility too, it’s not an alert platform and it’s not a tracing tool.
There are several amazing companies providing Serverless Observability (e.g Thundra, Lumigo or Epsagon).

sls-dev-tools is in short, Chrome Dev Tools for the Serverless World.

How to get started?

Well, if you’re using AWS Lambda functions, you can use this tool today — otherwise, you’ll have to wait or open a PR or Issue to support other cloud providers.

It doesn’t matter what framework, language or IaC you’re using, the tool uses CloudWatch Logs to generate all the metrics it needs.

Install

  • npm install -g sls-dev-tools

Usage

As sls-dev-tools is based off the AWS SDK authentication will happen automatically if your credentials are set-up within environment variables or in the ~/.aws/credentials directory.

Image for post
Image for post

Run

  • sls-dev-tools -n {YOUR_STACK_NAME} -r {YOUR_REGION} [-t {START_TIME}] [-p {PERIOD}]
  • The start time defines when you want your graphs to start from, and the date format for the start time is YYYY-MM-DD/HH:mm
  • The period defines the size of the buckets in seconds. This means if you give a period of 3600, the line graph will group the invocations and errors into 1h chunks, and the bar chart will show the average response time over the hour for the last 6 hours during which invocations were made.
  • To get the stack name, log on to AWS CloudFormation and it is shown in the overview section of stack info. It may not be what you expected e.g. it might have -dev on the end, so worth checking if the dev tools are not working.
  • The region is the AWS region, for example, us-east-1.
Options:
-V, --version output the version number
-n, --stack-name <stackName> AWS stack name
-r, --region <region> AWS region
-t, --start-time <startTime> when to start from
-p, --period <period> precision of graphs, in seconds
-h, --help
  • Choose a function with the arrow keys, and press enter to see the metrics for that function.
  • If you get an AccessDenied error in which case you must add the GetMetricData permission from CloudWatch in the IAM console on AWS.
  • If you’re not seeing any data in the graphs, try changing your start date to make sure you have had invocations since then.
  • The line graph shows the number of invocations and errors that occurred within the time period.
  • The bar chart shows the average response time of the invocations within the last 6 time periods that had some invocations.

We need your help!

Image for post
Image for post
https://github.com/Theodo-UK/sls-dev-tools

If you find this tool useful or have any feedback please get in touch via GitHub issues or Twitter

We are also actively looking for contributors and will be available to help you find good first issues, code review and assistance on developing out any new functionality.

Docs: https://theodo-uk.github.io/sls-dev-tools/

Serverless Transformation

Tools, techniques, and case studies of using serverless to…

Ben Ellerby

Written by

VP Engineering at Theodo and AWS Serverless Hero. Working with startups to launch MVP’s and large corporates to deliver in startup speed.

Serverless Transformation

Tools, techniques, and case studies of using serverless to release fast and scale optimally.

Ben Ellerby

Written by

VP Engineering at Theodo and AWS Serverless Hero. Working with startups to launch MVP’s and large corporates to deliver in startup speed.

Serverless Transformation

Tools, techniques, and case studies of using serverless to release fast and scale optimally.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store