A Journey into the Asynchronous Cloud World with Serverless Patterns

14.06.2023•Raffael Schneider
Tech Cloud native Serverless Amazon Web Services

In today’s TechUp, we’ll talk about a broad topic that might interest anyone who is thinking about how to design an efficient and elegant architecture for their own business domain in a time of endless possibilities offered by the cloud. It’s about so-called serverless patterns, established design patterns that can be provisioned and effectively used on a cloud provider like AWS. But before we dive in, I’d like to say a few words about another related topic, namely Event-driven Architecture.

The World is Asynchronous

At the past AWS re:Invent 2022 in Las Vegas, the motto during the keynote by Werner Vogels, the well-known CTO of Amazon, was: “The world is asynchronous”.

image1

Figure: Werner Vogels, CTO Amazon at AWS re:Invent 2022 in Las Vegas

He administered the metaphorical red pill of asynchronicity, the temporal offset of events, to the audience and left the blue pill of synchronicity, in this case the simultaneous concurrency of events, behind. The red pill is thus truer and closer to reality than the belief in the matrix, in which a world is unrealistically described synchronously. This was heard and so I also came to the realization of the fundamental nature of information systems, namely that they ultimately always try to map asynchronous sequences.

Thus, this guiding principle can be translated into the way we approach technology and its innovations. AWS, together with Werner Vogels, has understood how to strategically expand services that can satisfy precisely these real needs. What Vogels is getting at with the asynchronous world is that technology should be more geared towards native event-based design. The consequence of this is a decoupling of subcomponents of a given system architecture. Event-based software development, and in particular the resulting need to decouple system dependencies, brings me to another well-known figure in the tech scene…

Event-Driven Architecture

Martin Fowler, a well-known luminary known for Clean Code, Dependency Injection and the Technology Radar under the Thoughtworks flag, as well as for other architectural issues in the IT world, describes Event-Driven Architectures (EDA for short) as a pattern where the application reacts to events rather than requests. He emphasizes that EDA is a good way to build applications that respond quickly to change and scale easily.

Fowler argues that EDA improves communication between application parts by reducing dependencies between them. He also argues that EDA increases the flexibility and reusability of application parts because they can react to events independently. The concept of Event-Driven is not exactly new. A milestone talk by Fowler dates back to 2017, and a lot has happened since then. At this point, I would like to do a review and see how we can bring Event-Driven to a common denominator and prepare for serverless-pattern-based architectural proposals.

EDA in Action

So let’s recap: EDAs are a type of system architecture that uses events and asynchronous communication to loosely couple the components of an application. EDAs can help increase agility, the speed with which you can respond to new requirements, and build reliable, scalable applications.

This means that one of the most important features of EDA is loose coupling. Instead of having a static, fixed coupling of mutual dependencies, EDA allows components to be decoupled and isolated from each other. This in turn ensures that communication between components is given more weight and the possibility of asynchronicity is guaranteed.

Well-known design patterns from the EDA handbook are as follows:

  • Point-to-point Messaging
  • Pub/sub-Messaging
  • Choreography and Orchestration
  • Event-Streaming
  • Coupling of Event-Sources
  • Combinations of the previous design patterns

Features and Benefits of EDA

These design patterns are now relatively well known and are used almost everywhere. We at b-nova have already published several TechUps in which we have presented one or more of these design patterns as concepts. Just take a look there if something is not quite clear. In the context of an EDA, the patterns we will look at in more detail in a moment can ensure further features in addition to the loose coupling of components. These other characteristic features are as follows:

  • Eventual Consistency: EDA ensures “eventual consistency”, which means that all changes in the system are eventually propagated to all replicated components.
  • Variable Latency: Due to the asynchronous nature of EDA, there can be a variable delay between the occurrence of an event and its processing.
  • Idempotence: This refers to the ability of an application to achieve the same results regardless of how many times a particular event occurs.
  • Ordering: In EDA, events can be processed in a specific order, which can be important to ensure data consistency.
  • Testability through Test Pyramid: The loose coupling in EDA makes it easier to test individual components and systems as a whole.

In summary, EDA offers many benefits, including increased scalability, flexibility and agility, as well as the ability to leverage asynchronous communication and loosely coupled components. This makes EDA a strong option for many modern application architectures.

The Serverless Land

I originally came across this topic at the last AWS Meetup in Basel, where different architectural patterns were presented that had been implemented productively on AWS. An interesting website called Serverless Land was also presented, which shows how patterns can be viewed and used there. The patterns as well as the reference to an AWS-based, native Event-Driven architecture stuck in my mind and I wanted to investigate what else there is to learn there.

Serverless patterns are specific architectural and design patterns used for developing serverless applications. These applications are often referred to as “serverless” because they do not run on dedicated servers and the management of the server infrastructure is outsourced to a cloud provider such as AWS, Azure or Google Cloud.

In the age of cloud providers like AWS, EDA is particularly important because it takes full advantage of AWS services like AWS Lambda, Amazon SNS and Amazon SQS. These services allow developers to build applications that respond to events and scale automatically without having to worry about managing servers. The event-driven capabilities of AWS services such as Amazon S3 and Amazon DynamoDB also support real-time event processing, which increases the performance and efficiency of applications.

AWS Building Blocks

We probably all know how many services cloud providers like AWS now offer. It is important to understand that a basic set of these services is already sufficient to map fully-fledged business domains in an EDA on AWS. So you don’t have to know all AWS services to build a meaningful serverless architecture. Let’s therefore start by identifying exactly this basic set as building blocks for further patterns.

1. AWS Lambda

AWS Lambda is an event-driven serverless computing service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services and software-as-a-service (SaaS) applications and only pay for what you use.

2. AWS Step Functions

AWS Step Functions is a visual workflow service that helps developers use AWS services to build distributed applications, automate processes, orchestrate microservices, and build data and machine learning pipelines.

3. Amazon EventBridge

Develop event-driven applications at scale within AWS, existing systems, or SaaS applications. Amazon EventBridge is a serverless event bus solution that allows you to receive, filter, transform, route, and deliver events.

4. Amazon SNS

Amazon Simple Notification Service (SNS) sends notifications in two ways, A2A and A2P. A2A provides high-frequency, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications.

5. Amazon SQS

Amazon Simple Queue Service (SQS) allows you to send, store, and receive messages between software components at any scale without losing messages or requiring other services to be available.

6. Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as a “front door” for applications to access data, business logic, or functionality from your backend services.

Another Word on Pattern Deployment

There are different flavors of serverless pattern reusability in the serverless landscape. These flavors are based on the way the pattern is deployed declaratively. There are the following types:

  • AWS Cloud Development Kit (CDK)
  • AWS Serverless Application Model (SAM)
  • Serverless Framework
  • Terraform with native or third-party modules

The Pattern Landscape

The Serverless Land website distinguishes between Patterns and Workflows. In addition, raw snippets are also offered that complement the patterns and workflows. The main difference is that a workflow implements business logic, often using AWS Step Functions, while patterns represent more general combinations of AWS services to map a specific infrastructure part.

Two Examples

Before we get into the practical part, I would like to show you what such a pattern can look like using two case studies. The practical part will follow, but I will move it to a dedicated, second TechUp.

I. Pattern: Step Functions to Glue

Pattern: Serverless Land

Deployment: Terraform

Description: The Terraform template provisions an AWS Step Function, an AWS Glue Job, a Cloudwatch Event-Rule, an Amazon S3 Bucket, and the minimal IAM resources required to run the application. This pattern demonstrates the use of Terraform modules and provisions the following resources:

  • Amazon S3 Bucket: Uploads the sample Python script as an object.
  • AWS Glue Job that runs the script in the S3 bucket.
  • AWS Step Function that synchronously invokes the AWS Glue Job. The function waits for the job to complete.
  • Cloudwatch Event rule configured to start the AWS Step Function every 10 minutes.

Schema:

image2

Terraform:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

# terraform and AWS configurations
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }

  required_version = ">= 0.14.9"
}

provider "aws" {
  profile = "default"
  region  = "us-east-1"
}

# Variables
variable "job_temp_dir" {
  default = ""
}

# Modules
module "amazon_s3" {
  source = "./modules/terraform-amazon-s3"
}

module "aws_glue" {
  source          = "./modules/terraform-aws-glue"
  script_location = "s3://${module.amazon_s3.bucket_name}/${module.amazon_s3.glue_script_name}"
  temp_dir        = var.job_temp_dir
  s3_bucket_arn   = module.amazon_s3.bucket_arn
  s3_bucket_name  = module.amazon_s3.bucket_name
}

module "aws_sfn_state_machine" {
  source        = "./modules/terraform-aws-step-function"
  glue_job_arn  = module.aws_glue.glue_job_arn
  glue_job_name = module.aws_glue.glue_job_name
}

module "aws_cloudwatch_event" {
  source            = "./modules/terraform-aws-cloudwatch"
  stf_function_arn  = module.aws_sfn_state_machine.stf_arn
  stf_function_name = module.aws_sfn_state_machine.stf_name
}

# Outputs
output "aws_s3_bucket_arn" {
  value = module.amazon_s3.bucket_arn
}

output "aws_cloudwatch_event_rule_arn" {
  value = module.aws_cloudwatch_event.aws_cloudwatch_event_rule_arn
}

output "aws_step_function_arn" {
  value = module.aws_sfn_state_machine.stf_role_arn
}

output "aws_glue_job_arn" {
  value = module.aws_glue.glue_job_arn
}

II. Workflow: Web Contact Form Processing

Pattern: Serverless Land

Deployment: Terraform

Description: This application uses a synchronous Express workflow to analyze a contact form submission and provide customers with a case reference number.

This example uses Amazon API Gateway HTTP APIs to synchronously start an Express workflow. The workflow analyzes web form submissions for negative sentiment. It generates a case reference number and stores the data in an Amazon DynamoDB table. The workflow returns the case reference number and the sentiment value of the message.

Schema:

image3

Terraform: See here.

Conclusion

We’ve looked at a lot: asynchronous world, event-driven architecture, Vogels and Fowler, Serverless Land, patterns and workflows, AWS services like AWS-Lambda or Step Function, SNS or EventBridge and much more. I hope not all the terms were new to you, but let’s briefly summarize, explain the benefits and risks of this topic again and give a verdict on what we at b-nova think of it.

An Event-Driven Architecture is a methodology that describes how to architect software with a focus on asynchronous, event-oriented relationships where the application reacts to events rather than statically implementing pure requirements. An event can be a user interaction, a data change, or a timer trigger. EDA makes it possible to build applications that are easily scalable and can adapt quickly to changing requirements.

In the age of AWS services, EDA is particularly important because it takes full advantage of AWS services such as AWS Lambda, Amazon SNS and Amazon SQS. These services allow developers to build applications that respond to events and scale automatically without having to worry about server management. The event-driven capabilities of AWS services such as Amazon S3 and Amazon DynamoDB also support real-time event processing, which increases the performance and efficiency of applications.

The whole thing is then called Serverless, which in turn is a kind of architectural and design pattern. This serverless pattern is used for developing applications without servers. These applications are often referred to as “serverless” because they do not run on dedicated servers and the management of the server infrastructure is outsourced to a cloud provider such as AWS, but also Azure or Google Cloud. Serverless patterns offer many benefits, such as lower costs, higher scalability and faster time-to-market. However, there are also some limitations, such as higher latencies and limited resources. Careful consideration should be given to whether it is suitable for a particular project.

Serverless Land offers a collection of patterns and workflows, i.e. a variety of established, serverless-based design patterns that can be seamlessly transferred to the AWS cloud using Infrastructure-as-Code tooling such as SAM or Terraform.

Outlook on the Practical Part

Next time we will do the AWS Serverless Workshop, which will play through a fictional business case with the charming name Serverlesspresso.

We will map a workflow on AWS that incorporates various serverless patterns and three different frontend apps, one for the café display, the barista display and the customer display. This is sure to be interesting and I hope you will be there too.

Serverless Land

AWS re:Invent 2022

AWS re:Invent 2022 Keynote with Werner Vogels

This techup has been translated automatically by Gemini