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
  2. Follow the steps to create it.  It’ll also provision an AWS API Gateway Endpoint
  3. 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!

Free up your day with our Social Media Tools

Buffer can save you up to an hour a day and grow your traffic too.

Learn More
Written by Sunil Sadasivan

Sunil is also a full-stack hacker at Buffer, who works on ops, metrics, the web, and the Android app.

  • Evan Mouzakitis

    Nice write up! I’ve done something similar for my own team, with Python and Lambda. One issue I ran into was that if the slash command had not been called in some time (~30 mins since last call), the slash command would sometimes time out before receiving a response. My solution was to just run the lambda periodically (/15mins) so that it would respond immediately when called.

    Did you experience this issue? If so, how did you overcome it?

    • sunils34

      Oh interesting, I’m curious, what’s your Lambda timeout set at. I think we set ours to 10 seconds which helped ensure we don’t see a slack timeout.

      • Evan Mouzakitis

        Ha! That was it. I had absentmindedly left it at its default value of 3 seconds.

        Cheers!

        • timothyf

          The default value for Lambda timeout is actually 30 seconds. Were you able to change the Slack slash command timeout value? The Slack timeout value is 3 seconds, and that is what is the source of timeouts.

      • timothyf

        The timeouts are not being caused by Lambda. They are being caused by Slack. Our timeout on Lambda is set to 30 seconds, and we still get Slack timeouts if the Lambda function has not been called in awhile. This is because the Slack timeout is 3 seconds and doesnt appear to be changable. This is not enough time in many cases to boot the Lambda function and return a response from a cold state.

    • engineeringathome

      There was a bug with python’s redis wrapper about the time you were experiencing this. An upgrade would solve it.

  • Yassine Alouini

    Sounds great. Thanks for sharing your thoughts!