Building Slack /slash commands with AWS Lambda

Sunil Sadasivan -

When AWS Lambda came out last year I was amazed.  The thought never occurred to me that web development doesn’t need to be complex, instead it can be about purely accomplishing the task at hand.  While they’re relatively early still, I think AWS Lambda and AWS API Gateway, are great examples of where web development is headed.

If you haven’t experimented with AWS Lambda yet, I’d definitely recommend doing so.  Essentially it’s a model of web development in which you no longer need to worry about the underlying architecture and how it scales.  The idea is you create and deploy mini, single purpose functions at a time, and AWS does the hard work of server provisioning, scaling and monitoring.  With Lambda, you pay for the actual running time execution of your code and how much memory you use.  If your function is never called, you don’t pay for it.  At Buffer we’ve started to use AWS Lambda for certain what I call, ‘nano-tasks’ that are typically caused by a user event like handling image resizing, generating PDFs, posting multiple images or videos to Twitter etc.

Using Slack to trigger application deploys

At Buffer, we love Slack.  Slack has helped our remote team communicate and connect and of course the integrations are lifesavers.  This weekend I was looking into building some Slack slash commands to help the Buffer team be further productive.

One thing we’ve been proud of is how easy it is to deploy the Buffer application to production.  We’ve set up @Bufferbot as a bot to help us to trigger a deploy.

For instance, to kick off a deploy, within Slack, Buffer engineers will do:

This deploy process has worked well for us for over two years and I was hoping to bring this same flow for the Respond team.  The Respond team has been deploying by manually going to a Jenkins server and kicking off a deploy from there–definitely not as smooth as deploying to Buffer.

Bufferbot and is built on top of Github’s hubot.  It’s an app hosted on Heroku and is always running.   You can imagine that while it’s always running we only really call it at most 20 times a day during the week, which is not necessarily the best use of resources.

Discovering Slack + AWS Lambda

I could have easily set up the new Respond slack deploy using the same Heroku/Hubot approach, but then I came across this article from the AWS team.  It immediately hit me that I could save money, time and ops overhead by using AWS Lambda to power my slash commands rather than using Heroku (or any other server set up).

In fact, the AWS Lambda team has done a great job setting up boilerplate templates for anyone to create their Slack slash commands.   I ended up building the /deploy-respond command in less than an hour thanks to the AWS folks (and I don’t have to worry about the ops side too!).

Deploys to Respond are as simple as:

/deploy-respond app master

Implementation

For those interested in the steps, these were the steps I took:

  1. Navigate to the AWS Lambda console page and create a new Lambda Function.  Choose ‘slack-echo-command’ blueprint
  1. Follow the steps to create it.  It’ll also provision an AWS API Gateway Endpoint
  2. Once you finish the steps, you’ll be taken to where you can alter the source for the Lambda function.  It’s there that you’ll see the template for creating a Slack echo bot.  You can follow the comments to test out your slash commands.  I’ve included the blueprint code below if you’re curious.

Have you built some cool Slack /slash commands or slack bots? We would love to hear about the Slack integrations your team uses!  We’re hoping to build much more into our Slack experience this year!