Serverless Architectures on AWS Lambda: The OpsGenie Experience

Serverless Architectures on AWS Lambda: The OpsGenie Experience

OpsGenie hosted an AWS Meetup where our Technical Evangelist, Serhat Can, gave a presentation on this very topic, Serverless computing with AWS Lambda. The meetup was successful and it was great to open our office as a host for the first time, with plans to host more events in the future. A special thanks to Samantha Wargo, our Events Manager at OpsGenie, Mark Annati the AWS Meetups organizer, and Myles Steinhauser from Bose who also presented.


In this article, Serverless computing (Functions as a Service), specifically AWS Lambda for certain jobs is explored to explain the basics and reasoning for why it makes sense to use– with some example use-cases around OpsGenie. But first, let’s talk about the current cloud services available for running software. See the updated version of the Pizza example shown below: 

Pizza-as-a-Service-2.0-Paul-Kerrison

The image is pretty straightforward and explains the abstraction layers pretty well. A more technical - short way of explaining this is that in Infrastructure as a Service (IaaS), a deployment artifact is a Virtual Machine. Create VMs and configure machines, storage, networking, and operating systems. In Containers as a Service (CaaS), containers are configured inside other containers, to run servers, configure applications, and control scaling. While using Functions as a Service (FaaS), only run code when it is needed.

Watch a recording of a webinar on using AWS Lambda

Why use Serverless / Functions as a Service?

So far, different abstraction levels are noted but why these abstractions matter hasn’t been explained. Now, let’s talk about why it makes sense to use a solution like AWS Lambda.

Fewer operations

The first reason is that there is less code to manage. A lot of operational concerns that are normally experienced are now outsourced to AWS. There is no need to provision or manage servers, to update operating systems or language runtime.

If there is a problem in the underlying machine, it is no longer a problem. Updates and failovers are handled by the service. A great example for this is while running on AWS Lambda, AWS takes care of famous meltdowns and spectre vulnerabilities. There wasn’t a need to do anything. However there was still a need to execute patches if using EC2 and managing VMs. For the deployment, a zip file was created and uploaded it to the cloud provider. This is especially trivial if is it a small project. Simple logging is enabled and easy to use with CloudWatch. All that is needed to do is to print the log statement and go to the AWS console to see the logs within a minute or so.

traditional scale
source: https://www.enterpriseirregulars.com/115144/lambda-kicks-serverless-world-made-messages/

Continuous Scaling

Another reason to use AWS lambda is scalability. Although it has specific details, for simple usage, it is almost completely invisible. Nothing runs if the user or the system integrated with doesn’t trigger a function to execute the code. Once request counts increase, functions run in parallel. There is no need to configure or take an action. Again! All invisible. This behavior affects the pricing in a way that yields benefits and underlines another reason to use AWS Lambda.

Pay-as-you-go

AWS is real pay-as-you-go. What I mean by that is that nothing need to be paid if the code does not run. Don’t pay for the hour, minute, or even second. Pay for every 100 milliseconds for running code. Have 128 MB to 3 GB of RAM, and CPU increases along with the RAM and pricing accordingly. One of the best things is that AWS Lambda offers 1M free requests per month, which means it may not be necessary to even pay a cent for simple projects.

Serverless Providers

The benefits apply to all Serverless computing providers out there. The most well-known and used service out there is, of course, AWS’s Lambda. Microsoft has Azure Functions, Google has Google Cloud functions, and IBM has IBM Cloud functions. Auth0 offers Webtask, and some open-source alternatives exist like Apache Openwhisk and OpenFaaS. Feel free to use any desired cloud provider for the examples here.

AWS Lambda

AWS Serverless

As a Serverless provider, OpsGenie uses AWS and its Lambda service. AWS Lambda, again, is the most well known and used Serverless computing service out there. Choose to develop in Python, Java, Go, Node.js, and C#. Different versions of these runtimes are available. To run a function, it must be triggered. One of the best things about AWS Lambda is its integrations with other AWS services.

AWS Lambda is integrated with more than 20 other services. Here in the image listed below are some of the most important ones, each to be explained briefly.

API Gateway is used to create HTTP endpoints for APIs. Create an API endpoint and once a request is received, pass the payload to a Lambda function to run the code.

Another important one is the CloudWatch Events trigger. Use it to run cron jobs like regularly scheduled events. For example, to run functions every minute.

Listen to DynamoDB Table streams, trigger a Lambda function once a file is saved or deleted in S3 and more. A lot of different triggers from other AWS services are available. 

Custom solutions and integrations

It is important to point out that the integrations available in Opsgenie are built and managed by Opsgenie. Over 200 tools are available to be used with the full power of OpsGenie’s integrations framework to curate alerts. If there is an integration for a tool already, use it. It is the easiest, most powerful and recommended way.

Sometimes, there is a very specific use case or the desire to integrate with a tool that developed and used internally. In this case, use OpsGenie’s capabilities and tools like Webhooks, APIs, and Marid. Often 2 different flows are presented for these custom solutions. Either action is taken in OpsGenie like creating or acknowledging an alert, or OpsGenie triggers endpoints when a new action is taken to run code to take further actions.

Again, these custom solutions or integrations are different than the typical integrations OpsGenie has. Documentation may not exist for these customizations and OpsGenie’s customer success team may not be able to help debug for these. Though what can be done is guidance and instructions for applying some best practices.

Incoming solutions

Let’s look at two different ways of extending OpsGenie with custom code. First one is incoming. Incoming means actions are taken in OpsGenie. Use OpsGenie’s APIs and SDKs for this. Our API allows almost all actions available on the web user interface to be taken such as: executing alert actions, creating and enabling integrations, or updating schedules and escalations. For the incoming method, use any environment to run the code. In this post, see how to use AWS Lambda and see a real life use-case that features an example like this.

Outgoing solutions

The other way is outgoing. This means that OpsGenie communicates that an alert action is taken so that code is then run based on the alert data and action required.

There are two ways that OpsGenie triggers this communication. First is by webhook integration. Simply create a Webhook integration and enter an HTTP endpoint. Then, OpsGenie makes an HTTP request with the necessary payload. Use whichever service desired to run the code.

The second one is using Marid. Marid is an integration server and makes it easy to create such integrations. The downside of Marid compared to AWS Lambda is that installation and management are still required. However, it is easy to use OpsGenie-supported libraries. Use it for on-prem integrations, and connect outside securely.

An on-demand webinar that showcases this really well can be seen here.

Combine incoming and outgoing - and create a bidirectional link. The first use-case is an example of this. It combines both an incoming and outgoing way of extending OpsGenie.

Real life use-cases

Before going into the use-cases, AWS Lambda is used with OpsGenie because it requires no resource provision, no need to configure servers, and is trivial to deploy. Don’t pay if actions aren’t taken, and easily scale in case of an alert overload. It simply just works and requires almost zero maintenance.

Also be aware of that OpsGenie’s Cloudwatch integration can be utilized to get an alert if a problem occurs within AWS Lambda. This means a simple monitoring and alerting pipeline defined for code with no further afford. All that is needed to do is set up the integration. See the webinar about this as well, here! 

Enriching an alert with logs

Enriching with logs

 The first example is the custom solution developed together with Logentries. In this example, once an alert is created, OpsGenie triggers the API Gateway endpoint through the Webhook integration. Then, the Lambda function queries the related logs from Logentries API and attaches the file back to the alert through OpsGenie’s API. Detailed information and code are available on this repository. 

Attaching alert details to Slack links

Attaching alerts to Slack

In this example, a user shares an alert’s link from OpsGenie. Slack shares the link with third parties using the unfurling support. The Lambda function extracts the alertId from the link and gets the alert’s details from the API. As the last step, the slack message is updated with more information. Read this blog post to learn more and reach the GitHub repo to try the solution!

Create alerts from Slack messages

Creating alerts from Slack

 In the last example, create an alert from Slack messages. Outgoing webhooks in Slack can trigger OpsGenie’s API endpoint once a message received with the keyword chosen such as “OpsGenie” in a channel. Once the details are received, any action can be taken, in this case– create an alert. Read our blog, "Wondering how to trigger alerts from Slack messages?and reach out to the github repo to learn more about this solution.