Leveraging Lambda for Serverless Slack Apps
At Niche, we heavily utilize Slack, and we love it! Not only has it allowed us to communicate and collaborate more effectively, but it also has empowered both our technical and non-technical users to leverage cloud computing in their daily work.
Many of our apps allow interaction with AWS resources via Slack commands, so they need access to our AWS account. When building these tools, this caused us to ask,“Why not just host them where the resources live–in the cloud?” Naturally, the next question in this train of thought would be “Well, what kind of hardware do we want these tools to run on?” But now, with the advent of serverless computing and functions as a service, we now have the ability to run these tools without having to worry about hardware specifications through AWS Lambda.
In case you are unfamiliar with it, AWS Lambda is Amazon’s serverless compute service, which allows the invocation of functions written in C#, Go, Java, Node, and Python. Choosing to host our apps serverlessly in Lambda saves us a lot of money in hosting costs, as AWS only charges $0.20 per 20 million requests. Paying to keep a server running and listening for AWS events or Slack commands, which occur at frequency much lower than 20 million requests per month, would be far more costly! This makes Lambda truly a great fit for Slack apps.
Here are some of our apps and what they do. Also, they’re all named after Star Wars droids! 🤓
R2D2
R2 was our first Slack app hosted on Lambda. Before we created R2, if someone on our research or data teams wanted to spin up a database in AWS Relational Database Service (RDS) to work with, they would have to be set up with an IAM profile with two-factor authentication and receive training in either AWS CLI or the AWS Console. After the database was spun up, the team member would have to manually add it to the correct security group in AWS so that they would be able to access it and reset the master credentials. Finally, on top of this, it was easy for team members to forget to spin the database down when they were done using it, resulting in unnecessary hosting costs from leaving the instance up and running overnight.
With R2D2, this whole process is much more streamlined. Firstly, we can authenticate users with their Slack IDs and a unique Slack workspace token, so we don’t need to worry about IAM permissions. Secondly, R2 is activated via a slash command and allows the user to spin up or down databases in RDS. It then also handles all of the provisioning of those databases, including adding the instances to a security group and resetting the master credentials. With a simple webhook function alongside this, we automatically check once at the end of each day to see if the instances are still live; if they are, the function then sends a notification to Slack to remind team members to spin down the database using a slash command.
DB-8
This app is along the same lines as R2D2, but works in a slightly different fashion, spinning up or down multiple databases with one command. Prior to this, our QA team would have to manually bring up multiple RDS instances needed for our staging environment and add the proper security and parameter groups. Now all instances can be spun up and added to the proper groups simultaneously with a single slash command! In addition, this app has an additional slash command that allows the user to share a database snapshot from one AWS account to another.
K-2SO
We use Apache Kafka for a few things in our backend stack, so it’s important for us to be able to check up on Kafka cluster and node health. Previously, we manually cURLed a private endpoint on an administrative instance in EC2, but output never looked nice, and we had no consistent timed checks. K-2SO does just that, allowing users to run health checks manually right from Slack, as well as turn automatic health checks on or off. The results of these health checks are shipped to the next Slack app in this list, which sends them as a color-coded formatted message.
MSE-6
SNS topics are a useful tool in engineering event-driven Lambda functions. However, giving each of your apps the ability to send notifications to Slack for every publish to an SNS topic results in a lot of boilerplate code. To avoid this, I created MSE-6, which is an agnostic notification app that we have subscribed to a single SNS topic. It parses SNS messages, determines where the message came from according to the content, and formats the message into a pretty notification for Slack. Finally, it sends the message to a specific Slack channel if one is specified, and if one is not specified, it goes to a more general channel.
For reference, here are some other AWS features we used alongside Lambda to create these apps:
We have reaped many benefits from our Slack apps, and serverless hosting makes it incredibly easy to maintain them. In future posts, I will dig further into how one or two of these apps are set up so you can try making one yourself! If there is one in particular you would like to hear about, feel free to mention it in the comments.
Also, do you want to use one of these apps as part of your job? We’re currently hiring for a myriad of positions!
