marbot, our submission to the AWS Serverless Chatbot Competition

Three things Michael and I love to do most: prototyping innovative products, playing around with the latest technology and learning new things. That is why we decided to take part in the AWS Serverless Chatbot Competition. We’d like to introduce marbot, our chatbot, to you and share the backstory of its creation.

marbot

Challenge

The AWS Serverless Chatbot Competition started on August 10 with the following conditions:

Create a working bot for Slack that runs on AWS Lambda. Applications must use AWS Lambda and Amazon API Gateway for bot logic and integration. Applications cannot be hosted on any other hosting platform. Use of Slack APIs, such as the Slack Events API, is encouraged but not required.

On top of that AWS provided the following submission recommendations:

  • Integrate Slack APIs, such as the Slack Events API
  • Utilize additional AWS services
  • Submit application to the Slack App Directory
  • Showcase natural language processing of chat conversations

But what to build?

Idea

Working as DevOps engineers in various teams we have always been looking for a tool to share on-call duty among many shoulders without the need for organizational overhead. We came up with the idea of building a chatbot to combine Amazon CloudWatch with Slack.

We defined the following feature set as minimum viable product:

  • Receiving alerts from Amazon CloudWatch via Amazon SNS
  • Escalating alerts if a team member isn’t acknowledging within 5 minutes
  • Managing alerts by accepting, passing or closing them
  • Analyzing alerts in a daily summary
  • Grouping alerts with a dedicated alarm gateway for each channel

How did we implement the chatbot?

Implementation

The following figure is showing an architectural overview of marbot. We used a bunch of services and APIs.

Serverless Architecture of marbot

Are you interested in the details? Read on!

Serverless

The Serverless Framework simplified the provisioning and deployment of all the resources needed to setup the environment.

AWS Lambda and Amazon API Gateway

We used the API Gateway and Lambda for creating our backend and implemented endpoints for incoming events from Slack as well as from CloudWatch via SNS.

Amazon DynamoDB

DynamoDB is our favorite NoSQL database on AWS. marbot is storing channel endpoints, alarms together with their escalation state, and Slack authentication credentials.

Amazon Kinesis Streams and Amazon Kinesis Analytics

To provide daily team statistics marbot is analyzing event data with the help of Kinesis Streams and Kinesis Analytics. The statistics generated by Kinesis Analytics include the number of received alarms, time to acknowledge, time to close and much more.

Amazon SQS

marbot needs to escalate alarms to the next level if a team member is not responding. We implemented the needed scalable timer with SQS and Lambda. The solution is similar to what I’ve already described in Integrate SQS and Lambda: serverless architecture for asynchronous workloads.

Amazon SNS and AWS CloudWatch

All you have to do as a marbot user is to send your CloudWatch alarms to an SNS topic. The SNS topic is then forwarding the alarm to the marbot backend.

No EC2 instances needed. The whole architecture relies on highly available and scalable AWS services.

Summary

marbot is accessible to the public and free to use. More and more teams are using marbot to connect Amazon CloudWatch and Slack to spread alerts among their team members.

Try marbot now! We are looking forward to your feedback.

Read on


Share

           

RSS

  RSS

Newsletter


Andreas Wittig

Andreas Wittig

I’m the author of Amazon Web Services in Action. I work as a software engineer, and independent consultant focused on AWS and DevOps. Hire me!

Is anything missing in my article? I'm looking forward to your feedback! @andreaswittig or andreas@widdix.de.


Published on
Tagged with AWS, Serverless, Chatbot,