Photo by Propel
Nowadays, one of the most popular ways to build modern applications is to go serverless. In a serverless computing model, developers don't have to worry about infrastructure management, which allows them to focus more on designing and building applications. Organizations can also save significant costs since serverless resources are charged based on usage. To automate a serverless application, you can make it responsive to certain input events. This is generally what's known as using an event-driven architecture (EDA) or creating a serverless, EDA application.
EDA offers a few key advantages. First, you're able to handle incoming events asynchronously, which allows you to more easily scale your application. By making each component of your application a separate, event-driven microservice, you can also effectively decouple the application. This helps reduce the number of dependencies your components have with each other, and it allows you to build and deploy each component independently.
One of the most popular and basic serverless event-driven workflows involves using an AWS Lambda function to listen for incoming events, then processing those events in your application code. For example, you might have an automated system that handles a shopping order before storing the information about the order in a backend database. This tutorial will explain the basic architecture involved in building such a workflow. You'll also learn about the key AWS services that you need to build scalable, event-driven architectures to handle a variety of real-world applications.
To understand the basics of building an AWS serverless event-driven application, you need to learn a few key concepts and services.
The following concepts are referenced frequently throughout this article:
In the example application in this tutorial, you'll use the following services:
You're going to create a sample event-driven AWS microservice that stores information about incoming online orders. The architecture for this application might look something like this:
As shown in the above diagram, there are a few major components in the main microservice:
We can easily implement this microservice using the AWS console.
Finally, choose Create role.
Next, navigate to the Tables page in the DynamoDB console. From there, select Create table and use the following settings:
Choose Create table.
Now, you can create your Lambda function. Here is some basic handler code that implements the main functionality you want for your microservice:
This function makes a few assumptions about the structure of the incoming event. Specifically, it assumes that the important details of the event are contained in the <span class="code-exp">body</span> field.
To deploy this function, create an Author from scratch Lambda function from the Lambda console. Name the function <span class="code-exp">sample-function</span>, and make sure you choose runtime Python 3.9. Under Change default execution role, choose Use existing role, and then choose the <span class="code-exp">microservice-role</span> that you created earlier.
After function creation is complete, you can directly copy paste the above code into the editor. Make sure you select Deploy to deploy these code changes.
Next, you'll create a new event bus rule. Note that in this section, you're simply going to create a rule that allows any possible event message from Microservice X to arrive at the <span class"code-exp">default</span> event bus. Typically, you'll want to be more restrictive of these events.
In the Amazon EventBridge console, select the Create rule button. Name the rule <span class="code-exp">sample-rule</span>, and apply it to the <span class="code-exp">default</span> event bus. For Rule type, choose Rule with an event pattern. Choose Next.
For the Event source, choose All events. Review the warning that the console presents when you select this option. Choose Next.
On the next page, you're asked to choose the targets for this role. Choose AWS Service, and then look for Lambda function in the dropdown. For Function, select the <span class="code-exp">sample-function</span> you created earlier. This automatically sets up the current event bus as a trigger to your Lambda function along with all required permissions. Choose Next.
You can skip past the Tags page. After reviewing the details of your rule, choose Create rule.
Now you're ready to test the setup. You can do this directly from the EventBridge console. Navigate to the event bus page of the EventBridge console and choose the <span class="code-exp">default</span> event bus. At the top right corner, choose Send events. Fill out the form with these details:
For Event detail, paste the following JSON:
This is what a typical event message might look like coming from Microservice X. The most important component of this event JSON is the <span class="code-exp">body</span> parameter, which contains all the relevant fields you want to store in your DynamoDB table. It contains the <span class="code-exp">OrderId</span>, which you set as the partition key of your DynamoDB table. It also contains additional fields, such as the ID of the <span class="code-exp">Item</span> the customer ordered, the <span class="code-exp">Amount</span> of the transaction, a boolean <span class="code-exp">IsMember</span> denoting whether or not the customer is a member, and the <span class="code-exp">ShippingMethod</span>.
Choose Send. EventBridge will send this event to your event bus, which then invokes your Lambda function. In order to verify whether this worked, navigate to the DynamoDB console and choose the <span class="code-exp">sample-table</span> you created earlier. You should see that an entry has been added to your table with the same details as the JSON event.
As an important aside, note that we manually sent this event from EventBridge for testing purposes only. In a real-world scenario, Microservice X produces this event and sends it to your event bus, which then sends it to the Lambda function.
In this article, you learned how to configure multiple AWS services to create a microservice that handles incoming order requests. Specifically, you created a Lambda function that listens to an EventBridge event bus, then records information about an order into a DynamoDB table. This is a prime example of an event-driven architecture that works in real time to process incoming event streams.
Propel is a Serverless Analytics API Platform that helps companies stuck with painfully slow customer dashboards, clunky in-product analytics experiences, or no analytics at all to build their next-generation analytics products in record time. The platform enables developers to build customer-facing analytics like dashboards, in-product analytics, or analytics APIs with a few lines of code. It takes care of aggregating, caching, and controlling multi-tenant access to data without having to manage any additional infrastructure. It provides product development teams a Metrics GraphQL API to ship native-looking analytics that load blazing-fast in days not months.