The guide is free and divided into different sections for you to find the content easily.

• The first section - Introduction - is ideal for beginners as it will go into what AWS Step Functions is and all the terms that the rest of the guide will use.

• The second section - Features - is ideal for everybody that wants to learn the basic features that AWS Step Functions provides out of the box. Later in the guide, there is a section with more advanced features.

• The third section is about Integration Patterns. One of the main advantages of Step Functions is that it can integrate with over 200 AWS services, as well as external services and manual process. In this section, you will learn how that is done.

• The fourth section is about costs. This is a section that everybody should watch as in this part of the guide we go into detail on how the different workflows are charged as well as how you can optimize your workflows with costs in mind.

• The fifth section is about developing applications using AWS Step Functions. Here you will learn how to do it with infrastructure as code - AWS SAM or AWS CDK. And many features that will help you in the development like IDE tools and testing capabilities.

• The sixth section is all about the more advanced and specific features that AWS Step Functions offer. This is a great section if you have to solve one particular problem or you want to become an expert in the service.

• The last section is all about examples and patterns using AWS Step Functions. Here you can see different architectures that were built using this service and how the problems were solved. This is a great section for more advanced users and for people that are already building applications with this service.

1. Introduction

This section is ideal for beginners as it will go into what AWS Step Functions is and all the terms that you need to know in order to follow along the guide.

In this first video, you will learn what AWS Step Functions are, what are the main use cases and benefits.

In this video, dive deep into AWS Step Functions, exploring key concepts such as types of states, and how they are visually represented. It covers the eight types of states, and state management. It talks about the different workflows (standard and express) and when to use each.

This video explains the distributed map state in more detail, that allows you to write Step Functions to coordinate large-scale parallel workloads within your serverless applications. You can iterate over millions of objects such as logs, images, or .csv files stored in Amazon S3. The distributed map state can launch up to ten thousand parallel workflows to process data.

If you want to learn more about the distributed map state and how some companies are using it, check this blog post where I talk with CyberGRX about their solution.

2. Basic features

This section is ideal for everybody that wants to learn the basic features that AWS Step Functions provides out of the box. Later in the guide, there is a section with more advanced features.

Intrinsic functions

The Amazon States Language provides several intrinsic functions, also known as intrinsic, that help you perform basic data processing operations without using a Task state. Intrinsic are constructs that look similar to functions in programming languages. They can be used to help payload builders process the data going to and from the Resource field of a Task state.

Error handling

One of the best features of Step Functions is all the different mechanisms that it provides for error handling. In this video, you will learn about Step Functions error handling mechanisms: retries, fallback states, and redrive.

3. Integration patterns

This section is about Integration Patterns. One of the main advantages of Step Functions is that it can integrate with over 200 AWS services, as well as external services and manual process. In this section, you will learn how that is done.

In this first video, you will learn about the three integration patterns available in Step Functions and when to use each.

In this video, you will see an example - with code demo about the integration pattern to run a synchronous job.

In this video, you will see an example - with code demo about the integration pattern to wait for a callback.

4. Costs

Understanding costs and how much the different AWS resources cost us is an important part of the architect job. In this video, Ben Smith, Developer Advocate for AWS, talks about how the different Step Functions workflows are priced and how you can do interesting optimizations to get the best price you can from running your workflows.

5. Building and developing Step Functions

There are many ways to build and develop Step Functions. You can build them from the console or as code. In this section, you will learn the different options you have to build them.

The first video shows the Step Function Workflow Studio. In my opinion one of the best UIs in the AWS Console. The Workflow Studio is a tool that helps you to build workflows visually.

If you like to work with your workflows as infrastructure as code, you might be interested in this other video, where you can learn how to create workflows using AWS SAM and ASL (Amazon State Language).

Also, you might be interested in using AWS CDK to build your workflows, and this video shows you the native AWS CDK way to build the workflows and also how to integrate the ASL template into your CDK application.

If you like to use Workflow Studio from your IDE, you can use it from Visual Studio Code if you are using AppComposer. This video shows how you can do it.

Now that you know how to build and develop your workflows, you might need to test them and debug them. If you are using the AWS Console and Workflow Studio, you can take advantage of the visual capability of debugging the workflows.

Also, if you are using Workflow Studio, you can use the Test State functionality that allows you to test every state before deploying the workflow. This is really handy when building complex integrations when you want to test permissions, payloads, and intrinsic functions.

And finally, if you are into writing unit tests for your workflows, Step Function provides a framework called Mocked Service Integrations that allows you to write this kind of tests and keep them as code in your repository. Unit tests are always a good practice when you are building any kind of application. You can use them to make sure that all the changes you don't break the existing functionality.

6. Advanced features

This section is all about advanced and specific features that AWS Step Functions offer. This is a great section if you have to solve one particular problem or you want to become an expert in the service.

One feature that I won't call it advanced but I want to mention here is the capability of Step Functions to integrate with over 200 AWS Services natively, without the need to use a function in the middle. This video shows more about this integration.

If you need to invoke an external HTTP Endpoint and you don't want to use a Lambda function, you can do this directly from the workflow, using the new HTTPs endpoint task state. In this video, you will learn how to use it.

For the ones using Generative Artificial Inteligence in their applications, you can integrate Amazon Bedrock directly to your workflows. This video shows you how.

If you need to have multiple versions of the same workflow available, for example, for your deployment stages, you can take advantage of this feature of Alias and Versions that Step Functions provides. You can update independent versions of the workflow and have alias pointing to the right version you are interested. This video shows you how to do it.

7. Patterns and useful architectures

This last section is all about example architectures and patterns using AWS Step Functions. Here you can find different architectures that were built using this service and how the problems were solved.

The first video is a conversation with Ben Smith, Developer Advocate for AWS, in where he presents a series of very useful patterns that you can use in your applications to make them better and to solve complex problems easily.

This video is an example of an asynchronous application for transforming content with AI. You will learn how to embrace event-driven architectures and how the different concepts that were exposed earlier in this post come together into one architecture.

This video shows how to build a synchronous workflow using Step Functions and API Gateway. In this way, Step Functions can be the backend for your APIs.

This video explains the Saga pattern and how to implement it using Step Functions.

In this video, James Beswick, Developer Advocate for AWS, explains how Serverlesspresso uses Step Functions and EventBridge to orchestrate the different coffee orders.

8. Conclusion

And with that, you arrived at the end of the guide. Congrats!

By now, you should have enough information to start building your own applications using Step Functions.

In this comprehensive guide, you will learn everything from the basics to advanced features of AWS Step Functions, including integration patterns, costs, development options, and real-world examples. Ideal for beginners and experienced users alike, this guide covers all you need to know to start building applications with Step Functions.

If you want to get notified regularly when I create new content like this, you can subscribe to my newsletter.

And please share this article if you find it useful!

In this article, you will find a list of resources that can be useful when getting started building applications with Amazon Bedrock.

Amazon Bedrock

What is Amazon Bedrock?

Amazon Bedrock is a fully managed service that offers a selection of high-performing foundational models along with a broad set of capabilities to build gen AI applications.

Let's go into that definition and break it out in parts.

• Bedrock is a serverless service

• Bedrock offers many foundational models. Bedrock hosts those FM and you using the same API can switch the model your application is using.
  You can find models from AI21, Anthropic, Cohere, Meta, Stability AI and Amazon.

• You can also adapt your models with data, either by fine tune them using your own data-sets or by creating knowledge bases to your data.

• Bedrock offers a set of capabilities to build Gen AI applications. Capabilities that range from RAG - retrieval augmented generation, Bedrock Agents, Guardrails, and many other features that allow you to build secure Gen AI applications.

Amazon Bedrock Features

Bedrock response streaming

Knowledge Bases and Agents

Amazon Bedrock and AWS Lambda

Lambda and Python

Lambda and NodeJS

Amazon Bedrock and AWS Step Functions

Launch blog post - Build generative AI apps using AWS Step Functions and Amazon Bedrock

More related content...

• Check my blog post with resources about building AI Serverless applications, where you can find a full demo of this topic.

• [Spanish] - Aprende sobre como construir applications de inteligencia artificial generativa con serverless

The guide is divided into five sections, each addressing different topics:

Section 1: Introduction to Data Streaming applications: In this section, you will learn what are data streaming applications, some advanced patterns, and get a short introduction about Amazon Kinesis family of service.

Section 2: Amazon Kinesis Data Streams: The second section provides an general view of the fundamental concepts of Kinesis Data Streams.

Section 3: Amazon Kinesis Data Streams and AWS Lambda: The third section provides an in-depth understanding of the fundamental concepts of Kinesis Data Streams when paired with AWS Lambda to consume and put records into the stream.It caters to both beginners and experts, delving into the inner workings of this service.

Section 4: Kinesis Data Streams and Amazon EventBridge Pipes: In the fourth section, you will discover a new way to consume records in real-time from your streams. How EventBridge Pipes can help you out and why it is an alternative to AWS Lambda in many cases.

Section 5: Amazon Kinesis Firehose: The final section goes into details on using Amazon Kinesis Firehose, how to build a simple pipeline, and how to use AWS Lambda to transform records in almost real-time.

So, without further ado, let's dive into the world of Amazon Kinesis and unlock its full potential!

Happy learning!

1-Introduction to Data Streaming

To understand data streaming, you first need to grasp the traditional data processing approach. In the past, data was often stored in databases and processed in batches. However, this method had its limitations, especially when dealing with massive amounts of data in real-time scenarios.

Data streaming, on the other hand, enables continuous data flow, processing data in real-time as it arrives and does real time alerts, actions, analytics or ML processing. Think of it as a never-ending river of information, constantly being analysed and acted upon.

Use Cases of Data Streaming

Now that you understand the significance of data streaming, let's explore some of the compelling use cases where it truly shines. Data streaming finds applications in various industries.

• For instance, in the Internet of Things (IoT) realm, sensors continuously stream data from connected devices, allowing real-time monitoring and analysis of critical systems.

• Financial institutions benefit from data streaming to process high-frequency trading data swiftly and detect fraudulent activities in real-time.

• Social media platforms use data streaming to track trending topics, analyse sentiments, and provide personalised content to users.

Data streaming platforms

At the core of data streaming are streaming platforms like Apache Kafka, Apache Flink and AWS Kinesis. These platforms enable the ingestion, processing, and delivery of data in real-time. Ultimately, the choice of data streaming platform depends on your specific requirements, such as scalability, real-time processing capabilities, and integration with other services.

Data Streaming vs. Event-Driven Architectures

You might wonder how data streaming differs from event-driven architectures. While both concepts deal with handling real-time data, they have distinct characteristics and use cases.

Data streaming is all about continuous data flow, processing data as it arrives. It focuses on the seamless, real-time movement and processing of large volumes of data from various sources. Think of it as a river of data, constantly flowing and being processed.

In contrast, event-driven architectures are focused on the exchange of events between different components of a system. These events represent significant occurrences in the system, triggering specific actions when they happen. It's like a series of interconnected event triggers and listeners.

The key distinction lies in their primary focus: data streaming is about the continuous flow of data, while event-driven architectures focus on the meaningful events within a system.

Data streaming patterns

Let's talk about some of the most common and useful patterns when building data streaming applications: change data capture, content enricher, content and message filtering, and translator pattern. And finally, you will learn a pattern to ingest log data efficiently.

In this video, you will learn some useful patterns when building data streaming solutions.

Introduction to Amazon Kinesis

Amazon Kinesis is a family of services that is great for real-time big data and building data streaming applications. The Kinesis family offers many services to perform specific tasks and integrates natively with many AWS services.

The services available in the Amazon Kinesis family:

• Amazon Kinesis Data Streams: a low latency streaming ingest at scale

• Kinesis Data Firehose: allows us to load streams of data into S3, Redshift, and other services

• Kinesis Video Streams: allows us to process live video data in real time.

In this video, you will learn the basics from Amazon Kinesis. Why you want to use it? What problem is it solves? Also, the video gets into the details or Amazon Kinesis Data Stream and Amazon Kinesis Firehose.

2- Amazon Kinesis Data Streams

Kinesis Data Streams take the data generated by different producers and ingest them into shards. Then the different consumers will read that data from the shards.

How Shards works?

Kinesis Data Streams has 2 modes for provision capacity to those shards, on-demand or provisioned. No matter which mode you chose, you are going to have shards. A shard is a unique sequence of data records in a stream and provides a fixed unit of capacity.

Each shard can support 5 read transactions per second or 2 MB per second. And they can write up to a 1000 records per second up to a maximum total write of 1 MB per second.

Inside a shard, you are going to have records. Records are an immutable unit of data stored in a shard. They are composed of a sequence number, a partition key, and a data blob.

The partition key is a value that determines in which shard the record will be stored into. The sequence number is unique per partition key and Kinesis Data Stream will assign it to the record when writing it to the stream. Records are put in order inside the shards, but the order is not guaranteed between the shards.

Capacity mode

If you need to to increase the throughput of your stream, you need more capacity in your stream, to increase that you need more shards. The capacity mode for a stream determines how the capacity is managed in the stream, currently Kinesis Data Stream supports on-demand and provisioned mode.

In this video, you will learn what is Amazon Kinesis Data Streams, what are the shards and how you can use different ways to provision capacity to your stream. At the end of this video, you will see how to create a stream using AWS CDK.

Get the code (make sure that you are in the branch 01-create-stream):

https://github.com/mavi888/cdk-kinesis-data-streaming-demo/tree/01-create-stream

3-Kinesis Data Stream and AWS Lambda

You can use AWS Lambda to consume records from Kinesis and process them on real time or to put records in a stream. AWS Lambda is a great service to integrate with Kinesis Data Streams as it can increase it capacity as needed to support a big load of records coming it way.

In this video, you will learn how to put events into a Kinesis Data Stream from AWS Lambda using AWS SDK and AWS CDK. And in the second half you will learn about consuming events from the stream and triggering functions using Event Source Mapping and AWS Lambda.

Get the code:

https://github.com/mavi888/cdk-kinesis-data-streaming-demo/tree/02-lambda-consume-produce

Advanced Event Source Mapping

Typically, when data stored in a Kinesis data stream is consumed by an application, it is that consumer's responsibility to track-or checkpoint- a stream's last known position that was successfully processed. The event source mapping takes care of checkpointing for you, so your Lambda function code can purely focus on the business logic for processing an event or set of events.

You can consume the records from a Kinesis data stream from Lambda, every time there are records in the stream a function can be triggered. For simplifying that you can use an event source mapping.

An event source mapping is a Lambda resource that reads from an event source and invokes a Lambda function. You can use event source mappings to process items from a stream or queue in services that don’t invoke Lambda functions directly, like DynamoDB, Kinesis, Amazon MQ, MSK, SQS, DocumentDB.

In this video, you will learn most of the features from Event Source Mapping (or ESM).

Trouble shooting ESM

Sometimes things don't work, or even worse they stop working. And how you trouble shoot errors when working with Lambda and Kinesis Data Streams. In this video, Anahit shares with us a lot of strategies on what to do when you are working with Kinesis Data Streams and Lambda and suddenly things stop working. How to trouble shoot your event producer and consumer to figure out where the problem is.

4-Kinesis Data Streams and Amazon EventBridge Pipes

AWS Lambda is not the only way to process and consume records in real time from a stream. Amazon EventBridge Pipes can also consume and process records from the stream and deliver it to different targets.

In this video, you will learn how to create production like data pipelines using Amazon Kinesis Data Streams and EventBridge Pipes. You will learn how to store your analytic data in your data lake, while at the same time process your events as they come in in your Event Bus.

Get the code: https://github.com/mavi888/cdk-kinesis-data-streaming-demo/tree/03-kinesis-pipes

5-Amazon Kinesis Firehose

Kinesis Firehose is a service that helps with the ingestion of data, the processing or transformation of data, and storing it in some destination, like a database or data lake.

Kinesis Firehose is a fully managed service that provides near real-time streaming ETL - extract, transform and load. It scales automatically and it is low cost.

Kinesis Firehose is a ETL, that receives data from different sources. It supports over 20 different sources, like AWS SDK using the Direct Put, Amazon KDS, Kinesis Agent, and many open sources agents.

The transformation of data is optional, but it provides built-in transformations, like converting the data from JSON to Parquet or ORC, dynamic partitioning, and others. And for more complex transformations you can use AWS Lambda.

And finally the last step is the load. In here Kinesis Firehose will store the data into different databases, data lakes, like S3, Redshift, OpenSearch, or you can send to API Gateways or HTTP endpoints to third parties or custom solutions. So you can utilize them later on.

Kinesis Firehose use cases

You can use Kinesis Firehose for different use cases:

• Collecting click stream analytics, you can ingest the data in real time and deliver it to your data lakes enabling your marketers to take action on the data.

• IoT analytics is a common use case for organisations that use IoT in where they send the data from connected devices and produce near-real time analytics

• Event analytics, to understand how much downloads, transactions or other operations your users do.

• Log analytics is quite a common use case. In here you can collect all the logs with firehose and then detect application and server errors as they happen and identify the root cause by collecting and monitoring the log data

• Security Monitoring is another use case in where the network security logs are sent to firehose and they are monitored in near real time to analyze when there is a potential threat and then notify the security department

Kinesis Firehose characteristics

Kinesis Firehose more relevant features when using S3 as a data source:

• You can configure the buffer size and buffer interval. These two parameters allows you to configure how fast data will move from your source to your destination. Buffer size can go from 1MB to 128MB and buffer interval goes from 1 minute to 15 minutes. The first of these thresholds that gets hit will be sending data to S3. Using this parameters you can configure how fast your data gets to S3 and how small your files are in S3.

• Convert the data from JSON to Parquet or ORC. Parquet and ORC are more efficient than JSON for storing and for making queries.

• Kinesis Firehose provides a way to backup the original records if you want and allows you to register any failure in the transformation.

• Dynamic partitioning allows you to continuously partition streaming data by using keys within your data.

• Data transformation. With Firehose you can invoke a Lambda function to transform your incoming data and deliver the transformed data to your destinations.

In this video, you will learn what is Kinesis Data Firehose, what is used for, what features it has and how it integrates with AWS Lambda and Amazon S3.

Kinesis Firehose and AWS Lambda

In this video, you will learn how to create a Kinesis Data Firehose with AWS CDK that puts records into S3. You will learn 2 configurations, a basic one that just puts the records and a more advanced one that will transform the records using AWS Lambda as they come in to Firehose before putting them in S3.

Get the code for the simple solution: https://github.com/mavi888/cdk-kinesis-data-streaming-demo/tree/04-kinesis-firehose

Get the code for the advanced solution: https://github.com/mavi888/cdk-kinesis-data-streaming-demo/tree/05-kinesis-firehose-lambda

Conclusion

Congratulations on reaching the end! This guide is quite extensive and not intended to be read all at once.

By now, you have gained knowledge about building data streaming applications with Amazon Kinesis, you learn about the different services that are in the Kinesis family, you learn how to use Kinesis data streams with Lambda and EventBridge Pipes, and how to use Kinesis Firehose with Lambda for doing transformations.

Well done on completing this guide!

Are you looking for a similar guide but for Kafka check it at ServerlessLand

The article is divided into five sections, each addressing different topics:

Section 1: Hosting Your Application with App Runner: In this section, you will learn about the powerful capabilities of AWS App Runner and how it can efficiently host your applications.

Section 2: Understanding DynamoDB Basics: The second section provides an in-depth understanding of the fundamental concepts of DynamoDB. It caters to both beginners and experts, delving into the inner workings of Amazon DynamoDB.

Section 3: Designing Your DynamoDB Table: This section introduces the Single Design method and guides you through the process of designing your DynamoDB table. You will learn effective strategies to create optimal table structures.

Section 4: Implementing DynamoDB in Your Application: In the fourth section, you will discover step-by-step instructions to implement the concepts learned in the previous sections into your own application. This practical approach enables you to apply the knowledge effectively.

Section 5: Adding Event-Driven Characteristics: The final section demonstrates how to incorporate event-driven characteristics into your DynamoDB application. You will explore mechanisms to react to database events and leverage them in your application's architecture.

By the end of this post, you will have gained a solid grasp of all the covered concepts and be well-equipped to determine if DynamoDB is the right database solution for your specific needs. Additionally, you will have the ability to design efficient access patterns and become familiar with AWS services like App Runner and DynamoDB.

This guide stands out for its level of detail, making it one of the most comprehensive resources available for mastering DynamoDB. Each section includes accompanying videos and code samples, allowing you to apply the concepts in a practical manner.

So, without further ado, let's dive into the world of Amazon DynamoDB and unlock its full potential!

Happy learning!

1. Hosting the webapp using AWS AppRunner

What is AWS App Runner?

AWS App Runner is a powerful and intuitive service that simplifies the deployment and running of web applications in the cloud. It eliminates the need to worry about infrastructure, allowing you to focus on your code and deploy it quickly and easily. App Runner combines the benefits of AWS Fargate and AWS Lambda, making it an ideal choice for developers who want to deploy their applications in the cloud with no hassle.

With App Runner, you can start with a GitHub repository or a container image in AWS Elastic Container Registry (ECR). The service will automatically build and deploy your application, and any changes made to the code will trigger the CI/CD pipeline, which will rebuild the application on the fly. You can also use multiple branches for multiple environments and customize your application's settings, such as the number of vCPUs and memory required, as well as how the application should scale.

Once your application is deployed, you will receive a public endpoint that you can use. App Runner takes care of the scaling and load balancing of the application, allowing you to focus on your code. The pay-as-you-go pricing system means that you only pay for what you need.

To create an App Runner service, you can simply configure the compute settings, and you will receive a public endpoint to use. The infrastructure is handled by the cloud, freeing you up to focus on your code.

For more information, you can visit the AWS App Runner page.

The following video goes into more details on how AppRunner works

Service Source Types

AWS App Runner offers two different types of service sources: source code and source image. Regardless of the source type, App Runner takes care of starting, running, scaling, and load balancing your service. You can use the CI/CD capability of App Runner to track changes to your source image or code. When App Runner discovers a change, it automatically builds (for source code) and deploys the new version to your App Runner service.

To learn more about these two service types, please refer to the AWS App Runner documentation.

Source Code-Based Services

For this demo, we will focus on services based on source code. Source code is the application code that App Runner builds and deploys for you. You need to point App Runner to a source code repository with a supported runtime. App Runner will then build an image based on the base image of the runtime and your application code. Finally, it will start a service that runs a container based on this image. You don't need to provide container configuration or build instructions such as a Dockerfile.

Check the supported runtimes for more information.

Demo Instructions

In this demo, you can use a NodeJS app that is stored in a GitHub repository. AppRunner will automatically build, deploy, and host it in the cloud for you.

You have two options to perform this demo:

1. Console: You can use the AWS Management Console to follow along. The video below demonstrates how to use the console for this demo.

2. Infrastructure as Code: The video demonstrates how to perform the demo using AWS CDK. You can access the NodeJS application code from the GitHub repository here. For the AWS CDK infrastructure code used in the video, you can find it here.

The following video, shows how you can deploy and host a NodeJS application using AppRunner.

2.Amazon DynamoDB 101

Amazon DynamoDB is a fast, flexible, serverless NoSQL database service that delivers single-digit millisecond performance at any scale.

Data Models

DynamoDB supports two main data models: key-value and wide-column. These data models are highly efficient for retrieving items.

The key-value data model allows you to retrieve one item at a time using a primary key. It functions like a massive hash, enabling fast retrieval when the primary key is known.

For more complex access patterns, you can use the wide-column data model provided by DynamoDB. In this model, the hash is still required, but the value for each hash record is a B-tree. A B-tree is a data structure that enables quick element retrieval and range queries.

Main Components

DynamoDB organizes data into tables. You can create or delete a table with a simple API call. Each table contains items, and each item has attributes. Every item requires at least one attribute, which is the partition key. Optionally, you can define a sort key, which becomes another required attribute for each item.

The combination of the partition key and sort key (if defined) forms the primary key, which must be unique. Each item can also have additional attributes, and the set of attributes can vary from item to item.

DynamoDB also supports secondary indexes. While primary keys allow access to data, secondary indexes provide alternative ways to retrieve data efficiently. There are two types of secondary indexes: local secondary indexes and global secondary indexes.

Operations

DynamoDB offers three main types of operations:

1. Item-based operations: These operations are performed on individual items in a table.

2. Queries: Queries operate on a group of items that share the same partition key in a table or secondary index. This group is referred to as an item collection.

3. Scans: Scans retrieve all items in a table, which can be useful when you need to analyze or process the entire dataset.

Pricing

DynamoDB is a cloud-based NoSQL database service that charges customers based on the amount of data stored and the amount of data read and written. The pricing is as follows:

• Storage costs: Based on the amount of data stored per month, measured in GB-month. This includes data and indexes.

• Read capacity units (RCUs): Charged for data read from DynamoDB. One RCU is charged for each strongly consistent read per second, two for transactional reads, and half for each eventually consistent read per second (up to 4 KB).

• Write capacity units (WCUs): Charged for data written to DynamoDB. One WCU is charged for each write per second (up to 1 KB), and two WCUs for each transactional write per second.

For detailed information on DynamoDB pricing, refer to the Amazon DynamoDB Pricing page.

This video covers more in detail the most important concepts for DynamoDB

Amazon DynamoDB under the hood

In this section, you will delve into the inner workings of DynamoDB. Two Principal Engineers, Somu Perianayagam and Akshat Vig, provide insights into how DynamoDB functions.

The video begins by discussing the history of DynamoDB and highlights the distinctions between Dynamo and DynamoDB. It then delves into the architecture that powers DynamoDB and explains why this database is exceptionally fast. The video concludes by covering several essential features of DynamoDB, such as indexes, streams, backup and restore functionality, and transactions.

For a comprehensive understanding of DynamoDB's architecture and performance, you can refer to the following resources:

• Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service: This article provides an in-depth exploration of the design and implementation of DynamoDB.

• Meet the database that supports Amazon.com: This article offers insights into how DynamoDB supports Amazon.com and the scale at which it operates.

DynamoDB is a NoSQL database created by Amazon for their website, amazon.com. It was developed because the existing database systems couldn't handle the load required for the site's cart system. DynamoDB became popular within Amazon due to its scalability and predictable performance. However, teams using Dynamo had to manage their own infrastructure, which was a drawback. In 2012, DynamoDB was launched as a fully managed service, providing the flexibility of NoSQL with the convenience of not having to worry about servers. It gained popularity and became the default standard for key-value stores internally at Amazon. Dynamo and DynamoDB have some differences, such as Dynamo being single-tenant and requiring more configuration, while DynamoDB is multi-tenant and offers simplified APIs. The architecture of DynamoDB involves request routing, authentication, metadata lookup, and replication of data across multiple availability zones.

DynamoDB is a highly scalable database service that uses partitions to handle reads and writes. Each partition can handle a certain amount of reads and writes per second. The number of partitions needed depends on the requested throughput. In the past, admission control was done at the partition level, assuming uniform distribution of traffic. However, real-world workloads are often non-uniform, leading to hot partitions and throttling. To address this, admission control was moved to the table level, and smart placement algorithms were introduced to efficiently distribute partitions. DynamoDB Streams allows customers to consume changes in their tables in real-time, enabling features like event-driven programming, backup, and restore.

Check this interview with two of DynamoDB engineers.

3.Designing Your DynamoDB Table

Is DynamoDB the right database for you?

When considering adopting DynamoDB as the database for your application, the first question you need to answer is whether DynamoDB is the right database for you.

At AWS, we believe in the concept of database freedom, which means choosing the right database for your specific data requirements, access model, and scalability needs. AWS offers 16 different types and engines of databases for various purposes. So, why should you consider DynamoDB?

In this beginner's guide, you'll explore the top reasons why DynamoDB is the best NoSQL database for your next project. DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. It's an ideal solution for applications that require low latency and high throughput at any scale.

Adopting DynamoDB

Now that you know DynamoDB is a good fit for your needs, let's discuss the steps you need to take for adopting and migrating to DynamoDB:

1. Get yourself trained in DynamoDB characteristics: Familiarize yourself with the features and capabilities of DynamoDB. This will help you make informed decisions during the adoption process.

2. Understand Single Table design: When building applications with DynamoDB, it's beneficial to learn about the concept of Single Table design. This design approach can simplify your data model and improve performance.

3. Design and build DynamoDB tables and indexes: With the knowledge gained from the previous steps, you can now design and build your DynamoDB tables and indexes based on your application's data access patterns.

4. Convert and migrate your data: If you are migrating from another database, you'll need to convert and migrate your data to DynamoDB. Depending on the data source, you may need to perform some preprocessing to prepare the data for migration.

5. Code your application: Develop or modify your application code to interact with DynamoDB using the appropriate access patterns. This step may involve significant developer effort.

6. Deploy and test the migrated application: Deploy your migrated application to the cloud and thoroughly test it. This step ensures that your database is provisioned correctly and that your application functions as expected.

By following these steps, you can successfully adopt DynamoDB for your application. This section covers step 1, and the following sections will walk you through the remaining steps in the adoption process.

For detailed guidance on determining if DynamoDB is appropriate for your needs and planning your migration, refer to the following resource:

• How to determine if Amazon DynamoDB is appropriate for your needs, and then plan your migration: This article provides valuable insights and considerations for evaluating DynamoDB's suitability and planning a successful migration.

Introduction to Single Table Design

The main concept behind single table design is to organize your data in a way that allows you to retrieve all the data you need to solve a specific access pattern with a single query. The goal is to design your table in such a way that you can fulfill all your access patterns with the least number of requests to DynamoDB, ideally just one.

Single table design is based on the idea of denormalization, where you store related data together in a single table rather than spreading it across multiple tables. By doing so, you eliminate the need for complex joins and enable efficient queries that retrieve all the required data at once.

To effectively implement single table design, you need to carefully consider your access patterns and design your table schema accordingly. Each access pattern should have a corresponding index or set of attributes that allow you to retrieve the required data efficiently.

By leveraging single table design, you can achieve high performance and scalability in DynamoDB while minimizing the number of requests and simplifying your application logic.

Implementing single table design requires careful planning and understanding of your application's requirements and access patterns. It is recommended to review the provided resources and explore further documentation to design your DynamoDB table effectively.

If you want to deep dive in the single table design concept you can check this video.

Design a DynamoDB Table with Single Table Design

In this section, you will learn how to design a DynamoDB table using the single table design approach. By following these steps, you can efficiently model your data for maximum performance and scalability.

Here is an overview of the steps involved in designing a DynamoDB table with single table design:

1. Create an Entity-Relationship Diagram (ERD): Start by creating an ERD that visualizes the relationships between your entities. This diagram will help you understand the structure of your data and identify the primary entities and their attributes.

2. Identify Access Patterns: Determine all the access patterns required by your application. This involves identifying the different ways you need to retrieve and manipulate data from the table. Consider the types of queries you'll need to perform and the data you'll need to retrieve for each query.

3. Model the Primary Key Structure: Design the primary key structure based on your identified access patterns. The primary key consists of a partition key and an optional sort key. Choose meaningful attribute(s) that will allow you to efficiently retrieve the required data for each access pattern. You may need to denormalize your data and duplicate it in different parts of the table to optimize query performance.

4. Satisfy Additional Access Patterns: In some cases, you may have access patterns that cannot be efficiently satisfied with the primary key alone. In such cases, consider using secondary indexes or DynamoDB streams to address these additional access patterns. Secondary indexes allow you to query the table using different attributes, while streams enable capturing and processing changes to the table in real-time.

You can also refer to the following resource for more information:

• 7 Common DynamoDB Patterns for Modeling and Building an App with Alex De Brie: This video provides insights into various patterns and strategies for effectively modeling your data in DynamoDB.

By following these steps and considering your application's requirements, you can design a DynamoDB table using the single table design approach, resulting in a highly performant and scalable data model.

Remember to adapt these steps to your specific use case and consult the provided resources for more detailed guidance.

If you want to see how I design a table for an application using those for steps mentioned above check this video.

4.Implementing DynamoDB in Your Application

Provision Amazon DynamoDB Table and Indexes with AWS CDK

In this section, you will learn how to provision a DynamoDB table and global secondary indexes using AWS CDK (Cloud Development Kit). AWS CDK is an infrastructure-as-code framework that allows you to define and provision AWS resources using familiar programming languages.

Here are the steps to provision the DynamoDB table and indexes using AWS CDK:

1. Install and configure AWS CDK: If you haven't already, install AWS CDK and configure it with your AWS credentials. You can refer to the official AWS CDK documentation for installation and setup instructions.

2. Create a new CDK project: Start by creating a new AWS CDK project using your preferred programming language (e.g., TypeScript, Python, Java). This project will contain the infrastructure code for provisioning the DynamoDB table and indexes.

3. Write the CDK code: Write the AWS CDK code that defines the DynamoDB table and indexes. You can use the AWS CDK constructs provided by the AWS SDK for the programming language you're using. Define the table, primary key attributes, and any global secondary indexes you need. You can refer to the following resources for sample AWS CDK code:

   • AWS CDK DynamoDB Code Examples: This GitHub repository contains sample AWS CDK code for provisioning a DynamoDB table and indexes.

4. Deploy the infrastructure: Once you've written the AWS CDK code, you can deploy the infrastructure by running the appropriate AWS CDK deployment command. This command will create the DynamoDB table and indexes in your AWS account based on the code you've written.

5. Test the provisioned DynamoDB table: After the infrastructure is deployed, you can test the provisioned DynamoDB table by performing various read and write operations using the AWS SDK or other tools. Verify that the table and indexes are functioning as expected and serving your application's access patterns efficiently.

By following these steps, you can provision a DynamoDB table and global secondary indexes using AWS CDK. This allows you to define your infrastructure as code and easily manage and replicate your DynamoDB setup across different environments.

Code your application

Once you have the infrastructure ready, it's time to start coding your application to support the new access patterns. This section will guide you through six steps that you can follow when writing your application.

1. Configure the AWS SDK in your application: Set up the AWS SDK in your application to interact with DynamoDB. This includes providing your AWS credentials and configuring the SDK to connect to the correct AWS region.

2. Configure and pick your test library: Choose a test library for your application and configure it to run tests against your DynamoDB infrastructure. This will allow you to test your application's interactions with the database.

3. Create models: Define models for your application that map to the DynamoDB table and indexes. These models will help you work with data in a structured way and provide an abstraction layer between your application and the database.

4. Modify controllers: Update your application's controllers to handle the new access patterns. This may involve making changes to the logic for retrieving, creating, updating, and deleting data based on the specific requirements of your application.

5. Check routes: Review and update the routes in your application to ensure they align with the new access patterns. Verify that the routes are correctly handling requests and interacting with the DynamoDB table and indexes.

6. Ensure middleware is working: Test and validate any middleware that you have in your application, such as authentication or request validation middleware. Make sure that the middleware is functioning correctly and properly integrating with your DynamoDB infrastructure.

Additionally, in this section, you will learn about DynamoDB expressions, which are powerful tools for working with the database:

• Key condition expressions: These expressions define the conditions for retrieving items based on the primary key attributes. You can use key condition expressions to perform operations like equality, comparison, and filtering on key attributes.

• Filter expressions: Filter expressions allow you to further refine the results of a query or scan operation. You can use filter expressions to apply additional conditions to the data retrieved from DynamoDB.

• Condition expressions: Condition expressions are used to ensure that specific conditions are met before performing write operations (e.g., put, update, delete). They enable you to add conditional logic to your write operations.

• Update expressions: Update expressions define how attributes of an item should be modified during an update operation. You can use update expressions to add, remove, or modify attributes of an item.

• Projection expressions: Projection expressions determine which attributes should be returned in the query or scan results. You can use projection expressions to specify the attributes you need and optimize the data retrieval process.

By following these steps and understanding DynamoDB expressions, you can build an application that effectively interacts with your DynamoDB infrastructure and supports the desired access patterns.

How to Migrate Data to DynamoDB?

Once you have the infrastructure ready and your application coded, if you are performing a migration, it's time to start converting and migrating your data. The following section will provide you with a set of tips to help you build a migration plan.

AWS Database Migration Service (AWS DMS)

The recommended option for migrating your data is to use AWS Database Migration Service (DMS). This service is designed to facilitate database migrations and can be a valuable tool for your migration process.

However, if you are using the single table design approach, AWS DMS might not be the best fit, as it creates separate tables for each table in the source database. If you are migrating from MongoDB and still want to explore using AWS DMS, I have included a detailed blog post in the resources that explains how to perform a live migration from a MongoDB cluster to Amazon DynamoDB.

Custom Script

Due to the unique structure of your application table using the single table design, you will need to create your own customizable script for migration.

Your script will consist of two parts: retrieving the data from the original database and saving the items into the DynamoDB table.

Retrieving the data from the source

Most databases allow you to export data in formats such as JSON or CSV. If that is the case, you can store those exported items in Amazon S3 and then upload them to DynamoDB.

For databases with custom export formats, you may need to build a script that performs the data extraction for you.

The result of this step is having one file per entity in Amazon S3, and potentially some additional files for relationships if you are migrating from a relational database.

Importing the data to DynamoDB

You have a couple of options for importing the data:

1. Create a table file in Amazon S3 and import it into DynamoDB.

2. Process the items one by one and upload them to DynamoDB.

DynamoDB provides a feature that allows you to import data from Amazon S3 into a table, handling capacity management and data import for you. With this feature, you can import a file stored in Amazon S3, formatted like the DynamoDB table, into DynamoDB. However, note that this feature requires creating a new table; you cannot import data into an existing table.

To build the table file for direct import into DynamoDB or to iterate over the dump files from the database, you will need to create a process to handle that. You can leverage AWS Step Functions distributed map, which is a state type in Step Functions that iterates over items in a JSON or CSV file and executes a set of states. The maximum parallelization with Distributed map is 10,000.

Deploy and Load Test

In this step it's time to deploy your migrated application to the cloud and conduct various tests to ensure that your database is provisioned correctly. This section will guide you on how to perform load tests to verify the correct configuration of your table.

Before you begin, make sure you have completed the necessary steps to deploy your application using AWS CDK. You can find the code in the resources.

To load test your application, you can utilize tools like Artillery.io, which allows you to run load tests against your serverless applications. I have included a video in the resources that demonstrates how to run Artillery in a Lambda function for load testing.

During the load testing process, it's important to monitor the performance and metrics of your application. Amazon CloudWatch provides a powerful monitoring solution, and you can use AWS CDK to build CloudWatch dashboards for visualizing and analyzing your application's metrics. The resources include a video that explains how to build Amazon CloudWatch dashboards using AWS CDK.

By deploying your application and conducting load tests while monitoring the performance metrics, you can ensure that your database is provisioned correctly and that your application is capable of handling the expected workload.

5.Adding Event-Driven Characteristics

The final section of this guide explores the addition of event-driven characteristics to your application by leveraging DynamoDB Streams.

What are DynamoDB Streams?

DynamoDB Streams is a powerful feature provided by DynamoDB that allows you to capture changes in a table. Whenever a record is inserted, modified, or deleted in a table, an event is emitted into the stream. These streams provide a time-ordered sequence of modifications within a table, and the data is stored for 24 hours.

With DynamoDB Streams, various applications can consume these stream records in real-time and perform operations based on the events captured.

In this section, you will gain an understanding of what DynamoDB Streams are, when to utilize them, and how to get started with DynamoDB Streams and AWS CDK.

You can learn more about DynamoDB Streams in this video

Acting on streams events

There are multiple ways to take action on the events sent over DynamoDB Streams. One simple approach is to leverage Amazon EventBridge Pipes. Pipes connect sources to targets, reducing the need for specialized knowledge and integration code when building event-driven architectures. For example, you can easily connect DynamoDB Streams with an Amazon SNS email subscription to receive email notifications whenever changes occur in the application.

Check the following video to see how to do it.

Filtering subscription messages

By utilizing SNS message payload filtering, we can filter the messages received by the email subscription, optimizing our application for our specific use case without making changes to the consumer or the receiver.

Watch this video to see how you can use this feature from SNS.

Conclusion

Congratulations on reaching the end! This guide is quite extensive and not intended to be read all at once.

By now, you have gained knowledge about Amazon DynamoDB, learned how to design a single table, implemented it as infrastructure as code and in your application's codebase. You also discovered how to develop, test, and deploy an application that utilizes DynamoDB effectively. Lastly, you explored the integration of event-driven architecture features to your application using Streams and Pipes.

Well done on completing this guide!

You can watch the whole session here:

Introduction

AWS re:Invent 2022 - Keynote with Dr. Werner Vogels

Synchronous backend

The simplest backend

In this video, you will learn how to build the simplest backend from the talk using AWS SAM and Nodejs.

Load testing and Artillery.io

In this video, you will learn about Artillery.io, how to build load tests and how to run them using AWS Lambda.

Learn more about Artillery.io in their site.

Lambda invocation modes

In this video, Julian Wood explains a lot of different concepts related to Lambda and how it scale. In minute 6, you can learn about the invocation modes.

AWS X-Ray

In this video, you will learn what is AWS X-ray and how to get started using it.

Lambda features mentioned

• Blog post when it was announced Lambda support for Graviton2

• Blog post when it was announced Provision concurrency

• Blog post about announcement of Snap Start

AWS Lambda power tuning

Access to the open source library.

Lambda response streaming

In this video, you will learn what is Lambda response streaming and how to do a simple example using NodeJS

In this video, you will see how to use Lambda response streaming with Amazon Bedrock

API Gateway direct integration

Here you can find an example of code on how to do to the API Gateway direct integration with Amazon DynamoDB.

AWS Step Functions

In this playlist, you can learn more about Step Functions.

https://blog.marcia.dev/orchestrated-apps

Real time backend

API Gateway Web sockets

In this video, there is a simple example of API Gateway with lambda using Web sockets

AppSync with Web Sockets

In this video, you will see an example of how to do real time web applications using AppSync and GraphQL subscriptions.

AWS IoT Core

In this video, James Beswick explains how to use AWS IoT Core and how he used it to build Serverlesspresso.

Did you hear about ServerlessVideo during re:Invent? Check it out here.

Multi-region applications

I have a full playlist with videos and concepts about building multi-Region applications. Check it out.

https://blog.marcia.dev/global-event-driven-applications

Links related to "Developing and operating MARVEL SNAP on AWS serverless"

Try Marvel Snap: https://www.marvelsnap.com/

Second Dinner: https://seconddinner.com/

Stress test loader: https://github.com/seconddinner/stress-test-loader

Amazon.Lambda.AspNetCoreServer package: https://github.com/aws/aws-lambda-dotnet

Watch the talk

Code Whisperer

Example: Bed-time story

In this video, you can learn more about the architecture and the design patterns behind the bed-time story generator created by David Boyne. Also in the video you will find a link to a blog post and the code for this solution.

What are Event-driven architectures?

More on event-driven architectures in this blog post.

Amazon EventBridge Scheduler

Amazon EventBridge Pipes

Amazon EventBridge Event Bus

Learn more about EventBridge Event Bus in this blog post

Example: Automatic video dubbing

Learn more about this solution by checking this blog post

Code for this application: https://github.com/mavi888/sam-ai-helper

Orchestration vs Choreography

AWS Step Functions

I have so many videos related to Step Functions that I will share with you a blog post where you can find them all. This blog post keeps updating as I create new videos related to this topic.

https://blog.marcia.dev/orchestrated-apps

New announcements from Step Functions

Call HTTP endpoints directly from a state machine

Build generative AI apps using AWS Step Functions and Amazon Bedrock

Generative AI for developers

Amazon Bedrock

Check this article about Amazon Bedrock for Serverless

In this video, learn how to use Bedrock with Lambda and Python.

In this video, learn how to use Bedrock with Lambda and NodeJS.

In this video, learn how to return responses from Bedrock streaming back from a Lambda function

NEW from Bedrock

Agents for Amazon Bedrock is now available with improved control of orchestration and visibility into reasoning

Serverless Video

Try ServerlessVideo

Guide on how to migrate using Lambda and Mongo Atlas

13 videos

https://serverlessland.com/content/paved-path/lift-and-shift-a-web-app-to-serverless/1-introduction

Summary talk about this migration

Blog post summarizing the migration: https://blog.marcia.dev/lift-and-shift-a-web-app-to-serverless

Guide on how to migrate using App Runner and DynamoDB

14 videos

https://serverlessland.com/content/service/dynamodb/guides/using-dynamodbto-build-webapps/introduction

What is Serverlesspresso?

Serverlesspresso is an interactive serverless application showcased at AWS re:Invent, AWS Summits, and other events. It allows you to order coffee from your phone. It comprises three front-end applications, and a backend built primarily with Serverless services, such as AWS Step Functions and Amazon EventBridge.

Get the code

Watch this talk

Learn more how Serverlesspresso was built

Serverlesspresso extensions

• Introducing Serverlesspresso Extensions blog post

• Building ad-hoc consumers for event-driven architectures

Event-driven architectures

Serverlesspresso is built on top of Serverless services and using Event-driven architectures.

Check all these blog posts with more details about Event-driven architectures and the services used to develop these applications with AWS.

• Introduction to Event-Driven architectures

• Introduction to choreography and Amazon EventBridge

• Introduction to Orchestration and AWS Step Functions

• Serverless Land EDA page

• Material in Spanish

(this is a post that keeps updating constantly)

Serverless Badge

AWS Step Functions

Step Functions Distributed Map

Learn how CyberGRX cut ML processing time from 8 days to 56 minutes with AWS Step Functions Distributed Map

Amazon EventBridge

Pipes

Learn about the new feature of EventBridge

Learn how to use it...

Learn patterns that EventBridge Pipes help you to implement

Other services ...

Amazon CodeWhisperer

AWS AppRunner

AWS App Runner now supports retrieving secrets and configuration data stored in AWS Secrets Manager and AWS Systems Manager (SSM) Parameter Store in an App Runner service as runtime environment variables.

Let see it in action

More ...

You can find more information about what happened in 2023 on serverless, by reading the quarterly post from the Serverless Developer Advocates.

• Q1

The code

The backend code: https://github.com/mavi888/kinesis-firehose-demo

The webapp code: https://github.com/mavi888/voting-app-amplify

Building everything in the console

Amazon Kinesis

If you want to get a summary of the most relevant information in one go, check David Boyne's presentation from AWS re:Invent 2022.

AWS Lambda

Lambda Functions URLs

Check this example using Lambda functions URLS

10GB of ephemeral storage

Learn more about Lambda Storage

Support for Typescript Lambda functions with AWS SAM

Support for Typescript Lambda functions with AWS CDK

Lambda Powertools for Typescript

Feature flags with AppConfig and AWS Lambda

Lambda event filtering

Amazon Step Functions

Intrinsic functions

Unit testing Step Functions

AWS EventBridge

EventBridge Scheduler

Read the blog post for this launch

EventBridge Global Endpoints

Learn more about multi-region serverless applications

Other Services

AWS CDK v2

Kinesis Data Stream On-Demand

DynamoDB infrequent access table class

SQS DLQ redrive

AWS Amplify new Studio

More ...

You can find more information about what happened in 2022 on serverless, by reading the quarterly post from the Serverless Developer Advocates.

• Q1

• Q2

• Q3

• Q4

Why to build a multi-region serverless application and why not?

This video talks about what is a multi-region active-active architecture and why you might need one, and why you don't need one. Also, it covers why the strategies are different for serverless than for traditional applications.

Read and Write Data patterns for Multi-Region architectures

This video talks about data patterns for writing and reading data in multi-region architectures. If you have an application that is deployed in multiple Regions you need to check this video as you will learn the benefits and challenges of the most common data patterns.

DynamoDB global tables

Global tables build provide you with a fully managed, multi-Region, and multi-active database that delivers fast, local, read, and write performance for massively scaled, global applications.

Global tables replicate your DynamoDB tables automatically across your choice of AWS Regions.

In the following video Kirk Kirkconnell, Developer Advocate for Amazon DynamoDB explains the basic concepts and helps you get started with global tables.

And if if you want to implement Global Tables in your AWS CDK project, you need to watch this video.

Amazon Route53

When we talk about multi-region applications, we cannot forget how traffic flows between the different regions.

Amazon Route 53 is a DNS service that gives developers and businesses a reliable and cost-effective way to route end-users to Internet applications. Route 53 provides DNS service with 100% availability. The distributed nature of the DNS servers helps ensure a consistent ability to route end users to your applications. Amazon Route 53 integrates seamlessly with other AWS services and can map domain names to load balancers, Amazon EC2 instances, Amazon S3 buckets, Amazon CloudFront distributions, and other AWS and non-AWS resources Route 53 helps improve your application's performance and reliability of end users. If you're running your application in multiple regions around the world, you can easily set up routing to send each end user to the best location for them, or you can re-route users to a different location if the primary one becomes unavailable.

In this video, you will learn how DNS works and how Route53 is in the DNS infrastructure and about different routing strategies that Route53 provides and how you can leverage those.

In this video, you will learn how to use Route53 latency routing policy to build a serverless application to route users to the closest Region.

Building global event driven applications

Having a multi-Region strategy for your event-driven applications can help you fail over to another Region during a service disruption, increasing the availability and reliability of your applications. In this session, learn how to implement a multi-Region strategy with serverless services such as Amazon EventBridge, Amazon DynamoDB, Amazon S3, and more. Also, discover some best practices that can help your application become more resilient when a failure occurs.

More videos are coming soon!

Resources

• More information about EventBridge Global Endpoints

• Learn more about replicating secrets

• Learn more about multi-Region keys

• Creating a multi-Region secure app

• Replication of Amazon Cognito user pool example

• How Auth0 does multi-Region

Code

• Serverless Failover demo

• EventBridge Global Endpoint

Getting started

In this article, you can learn the basic integration patterns, queues, pub/sub, buses, and others:

• Introduction to Event-Driven architectures

EDA visuals are a great reference to learn about event-driven architectures.

This link will take you to the landing page for Serverless Land in where you can find more information related to the topic.

• Serverless Land EDA page

Enterprise integration patterns:The book Enterprise Integration Patterns, written by Gregor Hohpe and Bobby Woolf, describes 65 patterns for the use of enterprise application integration and message-oriented middleware as a pattern language; this website contains the catalogue of patterns and many other great resources

Choreography

This article goes in depth in many features of Amazon EventBridge and how to design your EDA applications taking advantage of this service.

• Introduction to choreography and Amazon EventBridge

In this video, you can learn more about the best practices to design and build EDA applications.

In this video, you can learn about initial phase of design of EDA systems and how to design your events.

In this playlist you can find all the talks for the GoTO EDA Day 2022.

Use Amazon EventBridge to Build Decoupled, Event-Driven Architectures
Get an overview of EventBridge, the basics of event-driven architectures, a deeper dive into EventBridge capabilities, and how best to use it in your serverless applications

Using AWS X-Ray with Amazon EventBridge
Example application shows how to use AWS X-Ray with Amazon EventBridge, using the AWS Serverless Application Model (AWS SAM)

Amazon EventBridge resource policy samples
GitHub repository containing sample implementations for Amazon EventBridge resource policies, multi-account design patterns and cross-Region event routing

Orchestration

This article talks about the building orchestration process and gets into the details of building applications using AWS Step Functions, and many of its features.

• Introduction to Orchestration and AWS Step Functions

Orchestration or choreography?

This video explains both patterns and helps you to decide which one can be the best approach for your problem.

En español

Este link te lleva a un post con mucho material en español sobre el tema.

• Material en Spanish

Before getting started with EDA it is important to understand a key concept that is tight vs loose coupling.

Coupling is the measure of dependency each component of an application has on one another. For example, a components need to call another in order to complete its task and the order in which things are called matter.

Tightly coupled systems can be particularly effective if the application has few components or if a single team or developer owns the entire application.

However, when components are more tightly coupled, it becomes increasingly likely that a change or operational issue in one component will propagate to others. For complex systems with many teams involved, tight coupling can have drawbacks. When components are tightly interdependent, it can be difficult and risky to make changes isolated to a single component without affecting others. This can slow down development processes and reduce feature velocity.

Tightly coupled components can also affect an application’s scalability and availability. If two components depend on one another’s synchronous responses, a failure in one will cause the other to fail. These failures can reduce the application’s overall fault tolerance.

Reducing coupling is the act of reducing interdependency between components and the awareness each component must have of one another. Event-driven architectures achieve loose coupling through asynchronous communication via events. This happens when one component doesn’t need another to respond. Instead, the first component may send an event and continue without impact should the second component delay or fail.

When communicating with events, components only need to be aware of the independent events. They don’t require knowledge of the transmitting component or any other components’ behavior (e.g., error handling, retry logic). So long as the event format remains the same, changes in any single component won’t impact the others. This allows changing an application with less risk.

When asynchronous events abstract components from one another, complex applications become more resilient and accessible. For example, in this case we have event producers and event consumers all connected using an event broker. There are many patterns like this that we are going to see during this series.

Core benefits of EDA

A shift in mindset is required when building an event-driven architecture because of the unique characteristics and considerations of asynchronous systems. Yet, this architecture style offers important benefits for complex applications:

• Build and deploy applications independently in loosely coupled applications. Development teams working on individual services have fewer dependencies. Changing one service will have less risk of impacting others.

• Build new features using events without changing existing applications. (Extend your applications) Since components emit events, event-driven architectures are easily extensible. Events can also be analyzed for business reports and audits.

• Scale and fail components independently in loosely coupled components. Applications with loosely coupled components have fewer single points of failure, as well as increased resiliency.

Key concepts of event-driven architectures

An event is the signal of a changed state, such as an item in a shopping cart or a credit card application. Events occur in the past (e.g., “OrderCreated” or “ApplicationSubmitted”) and are immutable, meaning they can’t be changed. This helps in distributed systems because there are no changes across components to keep in sync. Events are observed, not directed. A component that emits an event has no particular destination nor awareness of downstream components that may consume the event.

Event-driven architecture possesses these key components:

• Event producers publish events. Some examples include front-end websites, microservices, Internet of Things (IoT) devices, AWS services, and software-as-a-service (SaaS) applications.

• Event consumers are downstream components that activate in events. Multiple consumers may be found in the same event. Consuming events includes starting workflows, running analyses, or updating databases.

• Event brokers mediate between producers and consumers, publishing and consuming shared events while mitigating the two sides. They include event routers that push events to targets and event stores from which consumers pull events.

Queues

Point-to-point messaging is a pattern in which producers send messages typically intended for a single consumer. Point-to-point messaging often uses messaging queues as its event broker.

Queues are messaging channels that allow asynchronous communication between a sender and receiver. Queues provide a buffer for messages in case the consumer is unavailable or needs to control the number of messages processed at a given time.

Messages persist until the consumer processes them and deletes them from the queue. One consumer can consume each message. If we need that the message is consumed by multiple recievers you need to use another pattern.

If we look at AWS - Amazon SQS and Amazon MQ are used as managed queue services. And Lambda functions can get triggered when a new message is in the queue.

Dead letter queues

Dead letter queues are queues that you configured where messages that cannot be sent in the point to point pattern cannot be sent.

SQS and other queue service or message brokers will retry resending the message as many times as configured. But in some point if there is a problem with the target or with the event the message won’t be able to send.

If you don’t configure a place where the messages are stored, then the message will be discarded. That is why DLQ are important. This are a on-failure destination for all your messages. Later you can reprocess and analyse all the messages in the queue.

Pub/Sub

Pub/sub messaging is a way in which producers send the same message to many consumers. Whereas point-to-point messaging usually sends messages to just one consumer, publish-subscribe messaging allows you to broadcast messages and send a copy to each consumer.

The event broker in these models is frequently an event router. Unlike queues, event routers rarely offer persistence of events.

One type of event router is a topic, a messaging destination that facilitates hub-and-spoke integrations. In this model, producers publish messages to a hub, and consumers subscribe to the topics of their choice.

Another type of event router is an event bus, which provides complex routing logic. While topics push all sent messages to subscribers, event buses can filter the incoming flow of messages and push them to different consumers based on event attributes.

Event streaming

Using streams, or continuous flows of events or data, is another method of abstracting producers and consumers. In contrast to event routers, though comparable to queues, streams typically require consumers to poll for new events. Consumers maintain their unique filtering logic to determine which events they want to consume while tracking their position in the stream. Event streams are continuous flows of events, which may be processed individually or together over time.

Data streams vs event streams?

Data streams differ from event streams in that they always interpret data. In this model, individual data points, or records, aren’t independently useful. Data streaming applications are often used to either persist the data after an optional enrichment or to process the data over a preset time period to derive real-time analytics.

Event bus

The last of the patterns is the event bus. And here our event router has rules that send the events from the consumers to the producers of events.

More information

Everything about Amazon EventBridge: blog.marcia.dev/event-driven-applications

Everything about AWS Step Functions: blog.marcia.dev/orchestrated-apps

In this video you can learn more about integration patterns.

You might also wonder if it’s possible to lift and shift an existing application that runs in a traditional environment to serverless. This blog post shows how to do this for a Mongo, Express, React, and Node.js (MERN) stack web app. However, the discussions presented in this post apply to other stacks too.

Why do a lift and shift migration?

Lift and shift, or sometimes referred to as rehosting the application, is moving the application with as few changes as possible. Lift and shift migrations often allow you to get the new workload in production as fast as possible. When migrating to serverless, lift and shift can bring a workload that is not yet in the cloud or in a serverless environment to use managed and serverless services quickly.

Migrating a non-serverless workload to serverless with lift and shift might not bring all the serverless benefits right away, but it enables the development team to refactor, using the strangler pattern, the parts of the application that might benefit from what serverless technologies offer.

Why migrate a web app to serverless?

Web apps hosted in a serverless environment benefit most from the capability of serverless applications to scale automatically and for paying for what you use.

Imagine that you have a personal web app with little traffic. If you are hosting in a serverless environment, you don’t pay a fixed price to have the servers up and running. Your web app has only a few requests and the rest of the time is idle.

This benefit applies to the opposite case. For an owner of a small ecommerce site running on a server, imagine if a social media influencer with millions of followers recommends one of their products. Suddenly, thousands of requests arrive and make the site unavailable. If the site is hosted on a serverless platform, the application will scale to the traffic that it receives.

Requirements for migration

Before starting a migration, it is important to define the nonfunctional requirements that you need the new application to have. These requirements help when you must make architectural decisions during the migration process.

These are the nonfunctional requirements of this migration:

• Environment that scales to zero and scales up automatically.

• Pay as little as possible for idle time.

• Configure as little infrastructure as possible.

• Automatic high availability of the application.

• Minimal changes to the original code.

Application overview

This blog post guides you on how to migrate a MERN application. The original application is hosted in two different servers: One contains the Mongo database and another contains the Node/js/Express and ReactJS applications.

This demo application simulates a swag ecommerce site. The database layer stores the products, users, and the purchases history. The server layer takes care of the ecommerce business logic, hosting the product images, and user authentication and authorization. The web layer takes care of all the user interaction and communicates with the server layer using REST APIs.

These are the changes that you must make to migrate to a serverless environment:

• Database migration: Migrate the database from on-premises to MongoDB Atlas.

• Backend migration: Migrate the NodeJS/Express application from on-premises to an AWS Lambda function.

• Web app migration: Migrate the React web app from on-premises to AWS Amplify.

• Authentication migration: Migrate the custom-built authentication to use Amazon Cognito.

• Storage migration: Migrate the local storage of images to use Amazon S3 and Amazon CloudFront.

The following image shows the proposed solution for the migrated application:

Database migration

The database is already in a MongoDB vanilla container that has all the data for this application. As MongoDB is the database engine for our stack, their recommended solution to migrate to serverless is to use MongoDB Atlas. Atlas provides a database cluster in the cloud that scales automatically and you pay for what you use.

To get started, create a new Atlas cluster, then migrate the data from the existing database to the serverless one. To migrate the data, you can first dump all the content of the database to a dump folder and then restore it to the cloud:

mongodump --uri="mongodb://<localuser>:<localpassword>@localhost:27017"

mongorestore --uri="mongodb+srv://<user>:<password>@<clustername>.debkm.mongodb.net" .

After doing that, your data is now in the cloud. The next step is to change the configuration string in the server to point to the new database.

Backend migration

Migrating the Node.js/Express backend is the most challenging of the layers to migrate to a serverless environment, as the server layer is a Node.js application that runs in a server.

One option for this migration is to use AWS Fargate. Fargate is a serverless container service that allows you to scale automatically and you pay as you go. Another option is to use AWS AppRunner, a container service that auto scales and you also pay as you go. However, neither of these options align with our migration requirements, as they don’t scale to zero.

Another option for the lift and shift migration of this Node.js application is to use Lambda with the AWS Lambda Web Adapter. The AWS Lambda Web Adapter is an open-source project that allows you to build web applications with familiar frameworks, like Express.js, Flask, SpringBoot, and run it on Lambda. You can learn more about this project in its GitHub repository.

Using this project, you can create a new Lambda function that has the Express/NodeJS application as the function code. You can lift and shift all the code into the function. If you want a step-by-step tutorial on how to do this, check out this video.

const lambdaAdapterFunction = new Function(this,`${props.stage}-LambdaAdapterFunction`,
            {
                runtime: Runtime.NODEJS_16_X,
                code: Code.fromAsset('backend-app'),
                handler: 'run.sh',
                environment: {
                    AWS_LAMBDA_EXEC_WRAPPER: '/opt/bootstrap',
                    REGION: this.region,
                    ASYNC_INIT: 'true',
                },
                memorySize: 1024,
                layers: [layerLambdaAdapter],
                timeout: Duration.seconds(2),
                tracing: Tracing.ACTIVE,
            }
        );

The next step is to create an HTTP endpoint for the server application. There are three options for doing this: API Gateway, Application Load Balancer (ALB) , or to use Lambda Function URLs. All the options are compatible with Lambda Web Adapter and can solve the challenge for you.

For this demo, choose function URLs, as they are simple to configure and one function URL forwards all routes to the Express server. API Gateway and ALB require more configuration and have separate costs, while the cost of function URLs is included in the Lambda function.

Web app migration

The final layer to migrate is the React application. The best way to migrate the web layer and to adhere to the migration requirements is to use AWS Amplify to host it. AWS Amplify is a fully managed service that provides many features like hosting web applications and managing the CICD process for the web app. It provides client libraries to connect to different AWS resources, and many other features.

Migrating the React application is as simple as creating a new Amplify application in your AWS account and uploading the React application to a code repository like GitHub. This AWS Amplify application is connected to a GitHub branch, and when there is a new commit in this branch, AWS Amplify redeploys the code.

The Amplify application receives configuration parameters like the function URL endpoint (the server URL) using environmental variables.

const amplifyApp = new App(this, `${props.stage}-AmplifyReactShopApp`, {
            sourceCodeProvider: new GitHubSourceCodeProvider({
                owner: config.frontend.owner,
                repository: config.frontend.repository_name,
                oauthToken: SecretValue.secretsManager('github-token'),
            }),
            environmentVariables: {
                REGION: this.region,
                SERVER_URL: props.serverURL,
            },
        });

If you want to see a step-by-step guide on how to make your web layer serverless, you can check this video.

Issues with this solution

Now, if you try this migrated app, you will find two issues. The first one is that the user session is not sticky. Every time you log in, you are logged out unexpectedly from the application. The second one is that when you create a new product, you cannot upload new images of that product. Let’s analyze each of the problems in details and find solutions.

Authentication and authorization migration

The original application handled the authentication and authorization by itself. There is a user directory in the database, with the passwords and emails for each of the users. There are APIs and middleware that take care of validating that the user is logged in before showing the application. All the logic for this is developed inside the Node.js/Express application.

However, with the current migrated application every time you log in, you are logged out unexpectedly from the application. This is because the server code is responsible for handling the authentication and the authorization of the users, and now our server is running in an AWS Lambda function and functions are stateless. This means that there will be one function running per request—a request can load all the products in the landing page, get the details for a product, or log in to the site—and if you do something in one of these functions, the state is not shared across.

To solve this, you must remove the authentication and authorization mechanisms from the function and use a service that can preserve the state across multiple invocations of the functions.

There are many ways to solve this challenge. You can add a layer of authentication and session management with a database like Redis, or build a new microservice that is in charge of authentication and authorization that can handle the state, or use an existing managed service for this.

Because of the migration requirements, we want to keep the cost as low as possible, with the fewest changes to the application. The better solution is to use an existing managed service to handle authentication and authorization.

This demo uses Amazon Cognito, which provides user authentication and authorization to AWS resources in a managed, pay as you go way.

One rapid approach is to replace all the server code with calls to Amazon Cognito using the AWS SDK. But this adds complexity that can be replaced completely by just invoking Amazon Cognito APIs from the React application.

For example, when a new user is registered, the application creates the user in the Amazon Cognito user pool directory, as well as in the application database. But when a user logs in to the web app, the application calls Amazon Cognito API directly from the AWS Amplify application. This way minimizes the amount of code needed.

In the original application, all authenticated server APIs are secured with a middleware that validates that the user is authenticated by providing an access token. With the new setup that doesn’t change, but the token is generated by Amazon Cognito and then it can be validated in the backend.

let auth = (req, res, next) => {
    const token = req.headers.authorization;
    const jwtToken = token.replace('Bearer ', '');

    verifyToken(jwtToken)
        .then((valid) => {
            if (valid) {
                getCognitoUser(jwtToken).then((email) => {
                    User.findByEmail(email, (err, user) => {
                        if (err) throw err;
                        if (!user)
                            return res.json({
                                isAuth: false,
                                error: true,
                            });

                        req.user = user;
                        next();
                    });
                });
            } else {
                throw Error('Not valid Token');
            }
        })
        .catch((error) => {
            return res.json({
                isAuth: false,
                error: true,
            });
        });
};

You can see how this is implemented step by step in this video.

Storage migration

In the original application, when a new product is created, a new image is uploaded to the Node.js/Express server. However, now the application resides in a Lambda function. The code (and files) that are part of that function cannot change, unless the function is redeployed. Consequently, you must separate the user storage from the server code.

For doing this, there are a couple of solutions: using Amazon Elastic File System (EFS) or Amazon S3. EFS is a file storage, and you can use that to have a dynamic storage where you upload the new images. Using EFS won’t change much of the code, as the original implementation is using a directory inside the server as EFS provides. However, using EFS adds more complexity to the application, as functions that use EFS must be inside an Amazon Virtual Private Cloud (Amazon VPC).

Using S3 to upload your images to the application is simpler, as it only requires that an S3 bucket exists. For doing this, you must refactor the application, from uploading the image to the application API to use the AWS Amplify library that uploads and gets images from S3.

export function uploadImage(file) {
    const fileName = `uploads/${file.name}`;

    const request = Storage.put(fileName, file).then((result) => {
        return {
            image: fileName,
            success: true,
        };
    });

    return {
        type: IMAGE_UPLOAD,
        payload: request,
    };
}

An important benefit of using S3 is that you can also use Amazon CloudFront to accelerate the retrieval of the images from the cloud.

In this way, you can speed up the loading time of your page. You can see how this is implemented step by step in this video.

Testing this application

One benefit of this approach is that you can develop and test the backend and the front-end locally. The following video explains how you can do it.

How much does this application cost?

If you deploy this application in an empty AWS account, most of the usage of this application is covered by the AWS Free Tier. Serverless services, like Lambda and Amazon Cognito, have a forever free tier that gives you the benefits in pricing for the lifetime of hosting the application.

• AWS Lambda—With 100 requests per hour, an average 10ms invocation and 1GB of memory configured, it costs 0 USD per month.

• Amazon S3—Using S3 standard, hosting 1 GB per month and 10k PUT and GET requests per month costs 0.07 USD per month. This can be optimized using S3 Intelligent-Tiering.

• Amazon Cognito—Provides 50,000 monthly active users for free.

• AWS Amplify—If you build your client application once a week, serve 3 GB and store 1 GB per month, this costs 0.87 USD.

• AWS Secrets Manager—There are two secrets stored using Secrets Manager and this costs 1.16 USD per month. This can be optimized by using AWS System Manager Parameter Store and AWS Key Management Service (AWS KMS).

• MongoDB Atlas – Forever free shared cluster.

The total monthly cost of this application is approximately 2.11 USD.

Performance analysis

After you migrate the application, you can run a page speed insight tool, to measure this application’s performance. This tool provides results mostly about the front end and the experience that the user perceives. The results are displayed in the following image. The performance of this website is good, according to the insight tool performance score - it responds quickly and the user experience is good.

After the application is migrated to a serverless environment, you can do some refactoring to improve further the overall performance. One alternative is whenever a new image is uploaded, it gets resized and formatted into the correct next-gen format automatically using the event driven capabilities that S3 provides. Another alternative is to use Lambda on Edge to serve the right image size for the device, as it is possible to format the images on the fly when serving them from a distribution.

You can run load tests for understanding how your backend and database will perform. For this, you can use Artillery, an open-source library that allows you to run load tests. You can run tests with the expected maximum load your site will get and ensure that your site can handle it.

For example, you can configure a test that sends 30 requests per seconds to see how your application reacts:

config:
  target: 'https://xxx.lambda-url.eu-west-1.on.aws'
  phases:
    - duration: 240
      arrivalRate: 30
      name: Testing
scenarios:
  - name: 'Test main page'
    flow:
      - post:
          url: '/api/product/getProducts/'

Check this video to learn how to run these tests:

This test is performed on the backend APIs, not only testing your backend but also your integration with the MongoDB. After running it, you can see how the Lambda function performs on the Amazon CloudWatch dashboard.

The following video explains how to create this dashboards

Running this load test helps you understand the limitations of your system. For example, if you run a test with too many concurrent users, you might see that the number of throttles in your function increases. This means that you need to lift the limit of invocations of the functions you can have at the same time.

Or when increasing the requests per second, you may find that the MongoDB cluster starts throttling your requests. This is because you are using the free tier and that has a set number of connections. You might need a larger cluster or to migrate your database to another service that provides a large free tier, like Amazon DynamoDB.

Conclusion

In this article, you learn if it is possible to migrate a non-serverless web application to a serverless environment without changing much code. You learn different tools that can help you in this process, like AWS Lambda Web Adaptor and AWS Amplify, and how to solve some of the typical challenges that we have, like storage and authentication.

After the application is hosted in a fully serverless environment, it can scale up and down to meet your needs. This web application is also performant once the backend is hosted in a Lambda function. If you need, from here you can start using the strangler pattern to refactor the application to take advantage of the benefits of event-driven architecture.

To see all the steps of the migration, there is a playlist that contains all the tutorials for you to follow.

Update - Using App Runner

The migration of the server can also be done using AWS App Runner. In this video you can find an introduction to the service.

In this video you can find the steps you need to do in order to migrate the service from on prem to App Runner.

In this post, I want to share with you four different ways to store files when using Lambda and some of the most common use cases. If you have new use cases, please let me know in the comments box. I hope that after reading this you have more information to make better decisions when to choose one solution over the other.

Amazon S3

Amazon S3 and AWS Lambda integration is simple, on the operational side and on how the two services communicate.

On the operational side, Amazon S3 scales and is highly available. S3 scales with your functions. No matter how many functions run in parallel, S3 will scale according. S3 high-availability means that when you store a file in S3, it will be there until you remove it.

On the communication side, S3 and Lambda have a bi-directional communication. This means that you can store and retrieve objects from the Lambda functions in S3, but also you can trigger functions when objects suffer changes - added, changed or deleted.

The integration between these two services is simple to set up as none of the services needs a VPC. Simply give permissions from the Lambda functions to access the bucket and the bucket to trigger the function, and you are good.

In the following example, you can see how you can trigger a Lambda function when a new file is created in an S3 bucket and also how you can write into an S3 bucket from a function.

One other benefit of S3 is that the content is dynamic. You can change the content in the buckets without redeploying the function. And the objects will be available in the function right away. In addition, all data stored in an S3 bucket can be shared across multiple instances of the function, multiple functions, and multiple applications.

S3 and Lambda integration goes one step further with S3 Object Lambda. This feature from S3 allows you to change your data stored in S3 on the fly when it is fetched. This is a great feature when you have multiple applications accessing the same data and you want to reshape, resize or even anonymize the data.

In this video, you can see a demo on how to use S3 Object Lambda to anonymize data stored on S3 when fetching it.

However, S3 is not a file system, it has a flat hierarchical organization. From outside, it might look that you can have folders inside the buckets, but those folders are just a prefix for the object name.

Also, S3 speed for retrieving objects is the slowest of all the storage options available for Lambda. This is because the objects are not inside the function, and they need to be transferred from the S3 service to the Lambda service.

Example of use cases of Amazon S3

• When you are working with data lakes and you have multiple Lambda functions consuming and creating objects.
• When you need to have shared objects between multiple applications or functions. For example, you want to process a video. The first function will resize it, then the second will add the transcribe it and the third one will add the subtitles. These functions are sharing the video object.
• When you need to have shared objects between multiple applications. For example, after one application processes the videos, another application takes the videos and uploads them to the system so they can be played and another application grabs the video metadata and adds it to the administrative portal.
• When you need to work with huge files. However, when working with Lambda, you need to transfer that file to the function and that can be slow and also you might need to do some processing locally.
• When we want to trigger Lambda functions from the lifecycle of the object. When we want to do something when a file is created, modified or deleted. This is a powerful integration for event-driven architectures.

Ephemeral storage

Ephemeral storage refers to the storage capability inside the execution environment of your Lambda function. Until few weeks it was only 512MB and now we can configure it up to 10GB.

When you deploy your function, you set the storage space and you cannot change it without redeploying the function. In addition, this storage is not shared between different functions.

However, different Lambda invocations in the same warm execution share the storage space. This means that there can be something in the /temp directory if you don't clean it before the function ends its execution. But when the function is destroyed, the files inside the ephemeral storage are deleted. That is why when building applications that rely on ephemeral storage, you cannot rely that there will be something in there.

The integration between Lambda and the ephemeral storage is native, and you can work with this storage, as you would use a local hard drive. This is the fastest of all the storage options. As the ephemeral, storage is inside the instance running the function.

In this video, you can see how to configure the ephemeral storage with AWS SAM and a simple demo that showcases how to use it.

Example of use cases for Ephemeral Storage

• When you need cache between invocations. If you need to download big files from S3 or from the internet, you can use the ephemeral storage as a cache. Download all the files before your function handler executes and then whenever it starts the handler, you can check if the files are available in the temporary storage. If that is the case, then you can use the ones in there, if not download them. These files will last until de function gets destroyed.
• When you need to process big files. For example, videos, pdfs, zips or even machine learning models. You can download them to the function and then use them from there.

Amazon EFS

Amazon EFS is a fully managed, elastic, shared file system and it integrates with other AWS services. It offers high availability. Many applications, functions and invocations of the functions can access the EFS filesystem and also change the content dynamically.

There are no size limits for the file system of EFS, but the amount of concurrent connection is limited to 25.000 connections per file system. During initialization, each instance of a function creates a single connection to its file system that persists across invocations. This means that you can reach 25.000 concurrency across one or more functions connected to a file system.

The connection between Lambda and EFS is quick, but not as fast as ephemeral storage.

EFS and Lambda don't integrate natively. To access your file system, you need to put the Lambda function inside a VPC. But after you mount your EFS file system, you can use the normal programing language tools to access the file system.

In the following video, you can learn how to create an EFS and use it from a Lambda function.

Example of use cases with EFS

• When you need dependency management. You can save all your latests dependencies in your EFS and share them between all your Lambda functions. When ever you want to update a dependency you just update it in the EFS and all the functions will access them without the need to redeploy the functions.
• When you need to change files or append files to a file system.
• When you want to share packages with your functions that exceed the limits of your Lambda layers or the temporary storage.

Lambda Layers

I imagine you don't consider Lambda Layers as part of a storage solution for your Lambda function, but it is.

Lambda Layers are a storage solution, where you can package whatever you want to share with your functions. Lambda Layers are part of your deployment package and they cannot be changed without re-deploying the function.

Layers can be used across multiple functions, but functions cannot change them, they are read-only. Layers have a version number, so you can track what is inside a layer at all times. One cool thing about layers is that they can be shared across accounts, so you can use layers from a third-party provider, or deployed in another AWS account within your organization. However, layers cannot be shared across regions.

Accessing the data inside the layers is as fast as with ephemeral storage. Because, when the function is deployed, the layers are extracted inside the running instance.

Layers size is limited to the deployment size of the Lambda package, that is 50MB when zipped. Also, Lambda functions can have a maximum of 5 layers. Therefore, you need to be careful with what you put on the layers and how you create them.

In this video, you will learn how to create layers for your own dependencies as well for third party dependencies.

Example of use cases with Lambda Layers

• When you need dependency management. Layers are mostly used for sharing third party dependencies and company own dependencies between the different functions. Because of the version number, they are great for auditing the code, and making sure that the latest dependencies are enforced in all the organization.
• When you need to share compiled libraries. Sometimes you need to use some compiled library in your function.
• When you need to use Lambda Extensions. Lambda extensions for share their functionality with layers, as they can be easily shared between different accounts and providers.

Conclusion

After reading this post, you learn the four ways that you can store files and objects when using Lambda functions - Amazon S3, ephemeral storage, Amazon EFS and Lambda layers. Each of the solutions has different benefits and tradeoffs, that you need to evaluate when picking what you need in your function.

You can also mix many solutions in one application. For example, the code I share when talking about Amazon S3 uses three of the four storage solutions - Amazon S3, ephemeral storage and Layers, each of them for a different use case inside the application.

First, we are going to look at what is Amazon EventBridge. Then we will jump into the design of event-driven applications. And finally, I will show you a lot of features and best practices from Amazon EventBridge to make your development easier.

Introduction to Amazon EventBridge

Amazon EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications, integrated Software-as-a-Service (SaaS) applications, and AWS services.

EventBridge works with rules. You define rules in the bus and when an event comes into de bus, EventBridge will compare that event against all the rules. If a rule matches, then EventBridge sends the event to the target. In this way you can have a decoupled architecture, as the producer of the event doesn't need to know about the consumer. The producer just creates an event and sends it to the event bus.

In the following video, we look at Amazon EventBridge and how to build a simple application using AWS SAM.

How to design event-driven applications

You can use EventBridge to build an event-driven application, but how you design one? Designing an event-driven application so everything gets documented and you can easily extend it takes some practice. In this video, you will learn how to design step-by-step an event-driven architecture.

More features of EventBridge to help you build your application

EventBridge has lots of really interesting features and you can do quite a lot of things by leveraging them. In this section, I want to show you some of the most useful ones to help you build your applications.

Custom buses and central logging of events

Finding what is going on in an event-driven application can be hard. If you want to know if there is an issue, knowing what triggers what is quite challenging, even if you have a good documentation of your events. You might need to visit many consoles or logs to figure out where it went wrong. With a central place where all your events are located, you can start your investigation there. You can see what was the last event emitted and start your search in that service and see where it went wrong.

In this video, you will learn how to leverage custom buses to get a central logging for all the events in your application, so you can debug and pinpoint problems in your application super easily!

API Destinations

EventBridge API Destinations is a feature that allows you easily to call third party APIs directly from an EventBridge rule. This allows you to remove extra code and complexity in your applications.

Dead Letter Queues

Sometimes EventBridge cannot successfully deliver a event to the target specified in a rule. This can happen when, for example, the target resource is unavailable, when EventBridge lacks permission to the target resource, or due to network conditions.

EventBridge has a retry policy and will keep on trying to send your event, but after all the retry attempts are exhausted, EventBridge drops the event. To avoid losing events after they failed to be delivered, you can configure a dead-letter queue (DLQ) and send the failed events to it for processing later.

In this video, you will learn how to configure a DLQ into an EventBridge rule and how to set a CloudWatch alarm when this happens.

But you like to see the demos with AWS CDK...

In these videos, you will learn how to do what we did before with AWS EventBridge but with AWS CDK.

Amazon EventBridge Pipes

EventBridge Pipes is the ultimate integration tool; it's the missing link between different event producers and consumers. With Pipes, you can filter and enrich events before they reach their target, saving you time and money.

Amazon EventBridge Pipes, a new feature from EventBridge that enables you to connect different event producers and consumers. EventBridge Pipes is a powerful launch from EventBridge, as it allows you to integrate different event producers and consumers together and perform filtering and enrichment of the events that flow in the pipe.

Previously, people had to rely on Lambda to do this. For instance, if you were using DynamoDB streams or Kinesis and you wanted to send those events to EventBridge, you had to put a Lambda in between and then send the events using the AWS SDK with a put event to EventBridge. Now, with Pipes, you can connect Amazon DynamoDB Streams, Kinesis Data Streams, SQS, Managed Kafka, and Amazon MQ to the fifteen different EventBridge targets, including Step functions, Kinesis DS, Lambda, and EventBridge.

Before sending them to the target, you can filter the events that you want to send, based on a filter rule. You are not charged for the events that are filtered out. You can transform and enrich the events using Lambda, Step functions, and APIs.

Check the demos using Pipes

In this video you will see a demo of enrichment and filter of events with AWS SAM

In this video you will see a demo of how to track Application Events with DynamoDB streams and Email Notifications using EventBridge Pipes and AWS CDK

Amazon EventBridge Scheduler

EventBridge Scheduler, is a new capability from Amazon EventBridge that allows you to create, run, and manage scheduled tasks at scale. With EventBridge Scheduler, you can schedule one-time or recurrently tens of millions of tasks across many AWS services without provisioning or managing underlying infrastructure.

Conclusion

Amazon EventBridge is the way to go when you need to build an event-driven application. This service has so many functionalities, so before getting to code I recommend you learn the basics about the service, its integrations and how to create rules.

You can check a similar post about Building orchestrated applications with AWS Step Functions

If you want to learn more about this pattern, you can check this video that explains you the two patterns, the main differences, and when to use each of them.

First, we are going to look at what are Step Functions. Then we will jump into the design of orchestrated applications. And finally, I will show you a lot of features from Step Functions to make your development easier.

Introduction to AWS Step Functions

AWS Step Functions is a managed service that you can use to build state machines in the cloud. State machines allow you to do many things. For example, build distributed applications, automate process, and build data pipelines. State machines manage failures, retries, parallelization, and observability so you can focus on what matters to your organization. Also, state machines integrate directly with over 200 AWS services.

In the following video, we look at more detail what Step Functions are and how to get started with them. This video covers what problems Step Functions solve, why to use them, all the components of Step Functions, the different states, and a demo in the AWS console.

How to design an orchestrated application?

Step Functions are used to build orchestrated applications, but how do you do that? Designing orchestrated applications to be scalable and maintainable takes some practice. For you to learn how to do that, we created a video that explains how to design this applications.

More features of Step Functions to help you build your application

Step Functions have lots of really interesting features. In this section, I want to show you some of the best ones to improve your productivity.

AWS Step Functions 💜 AWS SAM

The first feature I want to show you is the integration with AWS SAM. You can easily build and deploy Step Functions as infrastructure as code (IaC) using AWS SAM. You can build your state machines with Amazon States Language (ASL) directly in your application and then build all the infrastructure needed: IAM permissions, logs, service integrations and more from your SAM template.

In the following video, I will show you how to do all this.

And if you want the code for this video, you can find it with this GitHub repo

AWS Step Functions Workflow Studio

If you are starting with Step Functions and you don't understand how to use ASL or IaC, then you will be interested in this low-code visual editor. The workflow studio allows you to create your state machines from the AWS console. It has a nice visual interface. And the cool thing about the workflow studio, that it outputs ASL. So if you ever want to build the state machines like IaC, then you can do it with no problem.

In this video, I will show you how you can use it and how to build your first state machine with it.

AWS Step Functions integrates with over 200 AWS services

When using Step Functions, you can call any AWS services from the state machine without the need to use a AWS Lambda function. You can code workflows to solve your business problems that connect to the services using an API integration. By using ASL, you can do manipulation of the inputs and outputs provided by the services and build flows that adapt to your needs. When there is less code to manage, you reduce the costs, make the state machine faster, and more maintainable.

In the following video, I show you how to can build a full workflow with IaC using these integrations. I also wrote an article on how to do it if you prefer reading.

Unit testing your state machines

When moving the business logic from your Lambda functions to the state machines, now you might wonder how you can make sure that those state machines are doing what they should do? Running integration tests is crucial for these applications but integration tests are slow and more expensive. That is why unit tests are a great to validate a lot of the processing from your local machine when developing this state machines, or from your build process before deploying the new versions of the state machines.

In the following video, I show you how to test your state machines using a feature from Step Functions called Mocked Service Integrations.

For both of the service integration demos, there is a code demo that you can deploy in your AWS account and see how everything works together.

Sync workflows with AWS Step functions and API Gateway

Step Functions by default are asynchronous processes and you can easily invoke them from API Gateway. However, sometimes we need that the state machine executes in a synchronously, for example, when there is an HTTP request and a response is expected.

Sync workflows for AWS Step Functions is a feature that allows you to return the result from a state machine in a synchronous way.

In the following video, I show you how to implement a sync workflow with API Gateway all with AWS SAM.

You can find the code for the demo in this GitHub repository

Intrinsic functions

The Amazon States Language provides several intrinsic functions, also known as intrinsic, that help you perform basic data processing operations without using a task state. Intrinsic are constructs that look similar to functions in programming languages. They can help payload builders process the data going to and from the Resource field of a task state.

Step Functions distributed map

The new distributed map state allows you to write Step Functions to coordinate large-scale parallel workloads within your serverless applications. You can now iterate over millions of objects such as logs, images, or .csv files stored in Amazon S3. The new distributed map state can launch up to ten thousand parallel workflows to process data.

State machines alias and versions

Step Functions allow you to run specific revisions of the state machine instead of always using the latest. This allows for more reliable deployments that help control risk, and provides visibility into exactly which version is run.

More advanced patterns and tools

In this video, you will learn a lot of advanced patterns and best practices to use Step Functions.

Conclusion

AWS Step Functions are the way to go when you need to create an orchestrated application. There are many functionalities in this service, so before getting to code I recommend you to learn the basics about the service, its integrations and how to use the ASL language.

In a follow up post, I will talk about event-driven applications. So stay tuned for that one.

If you don't know what the Well Architected Framework (WAF) is? WAF is a framework designed by AWS. It collects all the best practices for developing and running cost efficient applications in the cloud.

What is the Operational Excellence pillar about?

This pillar focus on developing and running workloads effectively, gain insights on your operations, and improve your operations over time.

This pillar talks a lot about DevOps practices, infrastructure as code, automatization, and observability.

Some of the design principles for this pillar are:

• perform operations as code
• make frequent, small and reversible changes
• review and refine operations procedures frequently
• anticipate and learn from failure

Best practices

There are four best practices areas for the Operation Excellence in the cloud. And there are questions to address each of the areas. I like to call these areas, steps as you need to address them in a particular order.

• Organize: In this step you share your business goals and priorities with your team. By the end everybody knows their responsibilities.
• Prepare: In this step you design your workload, so it provides the necessary information so you can understand its state. You plan how changes are managed and how they flow from end to end.
• Operate: This step is all about the operations of the operational excellence.
• Evolve: Keep on learning, sharing and continuously improving.

I organized this blog post based in those 4 areas.

Organization

This area is all about understanding the responsibilities of the team and team members, and about having clear priorities.

This area focuses on answering these questions:

• OPS1: How do you determine what your priorities are?
• OPS2: How do you structure your organization to support your business outcomes?
• OPS3: How does your organizational culture support your business outcomes?

Make sure that you identify owners for each application, components or process. Having owners is critical to improve the performance of the component.

Have a clear understanding of the business value for each component and why we own it. Create mechanisms for handling changes in the components, and assign owners to them.

Then evaluate risks and keep them in track for each of your components.

Make sure that people feel empowered to experiment and create mechanisms where experimenting is safe. For example, make it difficult for your developers to take down production, so they can deploy on their own terms and see the results right away.

Keep your teams trained and increase their understanding of how their choices impact the workload.

Prepare

In this area, you will design your workload so it can provide all the information you need to understand it state.

This area focuses on answering these questions:

• OPS4: How do you design your workload so that you can understand its state?
• OPS5: How do you reduce defects, ease remediations and improve flow to production?
• OPS6: How do you mitigate deployment risks?
• OPS7: How do you know that you are ready to support a workload?

This area is about design and planning.

Lot of issues that can be solved by having CI/CD (continuos integration / continuos delivery) in place:

• Adopt approaches that enable fast feedback from change to production and fast recovery.
• Emphasis small, reversible and frequent changes.
• Use a consisten process to go live or preform changes in prod

Other things that are solved with good DevOps processes, like:

• have run books to document routine activities
• Have playbooks to guide issue resolutions
• use infrastructure as code and different stages

Operate

In this area is all about the operations of the Operational Excellence.

This is the area were it gets practical to your AWS environment. I will show you many good practices in action.

Questions that are answer here:

• OPS8: How do you understand the health of your workload?
• OPS9: How do you understand the health of your operations?
• OPS10: How do you manage workload and operations events?

In the Serverless Lens 2 more questions are added.

• How do you understand the health of your serverless application?
• How do you approach application lifecycle management?

In my opinion, answering these 2 last questions will help us to answer part of OPS8 to 10.

How do you understand the health of your serverless application?

This can be done with Metrics, Logs and Tracing: the Observability triad.

You need to implement all these in our serverless applications to be able to understand the health of our application.

• Logs are time stamped record of events with information about that discrete moment in time.
• Metrics gather a numerical data about things we want to track in our application.
• Traces are a single transaction end to end, how this transaction journey your whole application.

So how you implement all these things when using AWS?

For logs we use CloudWatch logs, CloudWatch insights and structure logging libraries.

For Metrics you can use CloudWatch metrics, the CloudWatch dashboard and CloudWatch alarms

For traces you can use AWS X-Ray and CloudWatch service lens.

How do you approach application lifecycle management?

Applications tend to have a similar lifecycle. First you code and build prototypes, new features, experiments. Then you build and deploy into a some kind of safe environment were you can run tests, and then finally you deploy to production. There can be more o less stages and environments in place, and this process can be or not automated.

This question covers many topics related to each other:

1. Infrastructure as code
2. CICD pipelines
3. Deployment environments
4. Application configuration management
5. Testing

For most of the topics in this list, are covered in the the session I recorded for AWS reInvent 2020.

For IaC, I have many videos talking about AWS CloudFormation, AWS SAM, AWS CDK, Amplify and others. You can check this playlist

For CI/CD pipelines and creating different environments, I have many videos on Code Pipelines built with CloudFormation, CDK pipelines, AWS SAM pipelines with Github, Gitlab pipelines and AWS Amplify CICD. And more are coming in the future for sure. Here you can find the playlist

In those videos you can learn how to create multiple environments and how to automate your deployment from your computer to production.

Also I created videos related to deployment strategies for your applications, such as Canary and Linear deployments and how to do it with CodeDeploy.

For Application configuration management, you need to learn about Parameter Store, KMS to encrypt the parameters, the Secret Store, and also how to juggle the application in an automated way in your application. You can achieve all these, using a service like AppConfig or by having environmental variables in your applications. Check the playlist for those videos

And finally testing. There are so many places where we can test in a serverless application. It is important to learn to perform all the different kind of tests in the right level of our application.

For example, when we talk about source we do code reviews and pull requests. For that you can use a service such as Code Guru, if you have Lambda functions running in Java o libraries that perform similar checks in your remote repos.

For the build phase we run all the linting and unit testing of our application. Here is not only the code but the infrastructure that can be tested.

Then you need to focus in integration tests. Integration tests are tests that run in environments in the cloud with real cloud services. You can use Lambda functions for example to run integration tests.

Also you can do load testing of your serverless applications with services like artillery. That allow you to create simulations load in your application and see how the application responds to the high load.

To deploy your application safetely into production, there are many deployment strategies using AWS CodeDeploy. CodeDeploy runs integration tests before and after deploying a new version of your application to a specific environment.

For all the things mentioned here, there is a playlist on how to implement everything in AWS.

Evolve

This phase is about learning and continue improving everything you have built in the past

It answers the question

• OPS11 : How do you evolve operations?

In this step you need to make time to make your operations better. There are always things that can improve.

Also this phase talks about creating feedback mechanisms to learn about services going down or with poor performance. Also mechanisms to share these learnings across the whole organization.

It also talks about how you save this lessons and monitor the data and metrics you use to create them.

I will add here that a great practice to evolve Operational Excellence is running regular Game Days in your organization. Game days allows you to test all the things listed in this post and see all your mechanisms in practice. Game day tests your process and systems in action and finds when process can goes wrong.

Also in this step you can think about exploring Chaos Engineering, and to create automatic tests for your organization.

I also have this post as a video if you prefer to watch instead than to read

🙏🏽 Si conoces a alguien que quiera aprender sobre esto, compartí este articulo

PARTE 1 - Qué es la nube?

Empecemos por lo primero, que es la nube ☁️?

Es un termino que usamos mucho pero que pasamos poco tiempo definiendo.

Hay una serie de pasos que te van a ayudar a convertirte en un desarrollador en la nube.

🚀 Este es un buen video para empezar tu viaje hacia la nube. ☁️

Y ahora te estarás preguntando: "Bueno ta, precioso esto de la nube y AWS. Pero como creo una cuenta de forma segura y con las mejores prácticas en mente, sí recién estoy empezando."

No te preocupes, nosotras te damos todos los pasos!

Ahora sabes cómo crear la cuenta de AWS, pero todavía necesitas ayuda para crear la cuenta.

En este video Javier Ramirez te muestra paso a paso como hacerlo.

Buenísimo, ahora creaste tu cuenta de AWS y lo primero que te pide es que crees un usuario de IAM!

Y te estarás preguntando: "Qué es eso? Cómo gestiono la seguridad de mi cuenta?"

Y también seguro que me vas a decir: "Pero me acabas de pedir que ponga mi tarjeta de crédito para crear una cuenta. Cómo me aseguro que no estoy gastando más de lo que espero!"

Por eso acá te dejo una lista de 7 consejos que te ayudaran a controlar tus gastos en AWS

Y si queres ir un nivel más y aprender a calcular los costes al detalle de tu infra en AWS.

En este video podes aprender cómo usar la calculadora de costos de AWS paso a paso para estimar los costes de tu infraestructura.

Bien ahora sabes cómo crear tu cuenta y cómo asegurarte que no pases con la factura. Pero seguis sin saber por dónde empezar a estudiar AWS.

Las certificaciones son una gran forma de organizar tu estudio para poder aprender los temas en profundidad.

Querés saber más sobre estas esto? Mira mi conversación con Gabriel Ramirez sobre este tema.

PARTE 2 - Cómo empezar a desarrollar aplicaciones en la nube?

Entonces sos desarrolladora y querés una introducción rápida a cómo empezar con AWS.

Querés más detalles de las opciones de computación en la nube?

Te dejo un episodio del podcast donde hablamos en más detalle de los servicios de computación en la nube para que puedas entender cuál usar y cuando.

PARTE 3 - Servicios básicos de AWS

Hay muchos servicios en AWS, pero algunos más que otros nos van a ayudar a empezar a desarrollar nuestras aplicaciones.

El almacenamiento es un concepto importantísimo cuando desarrollamos aplicaciones.

Dónde y cómo guardamos nuestros archivos para poder acceder a ellos de forma fácil y rápida.

En este video hablamos de todas las opciones de almacenamiento en AWS para que sepas cual elegir

Amazon S3 es uno de los servicios más usados, ya que es la base de muchísimos de nuestros desarrollos.

Querés saber cómo empezar con S3? Querés ver cómo solo usando S3 podés crear una página web estática en pocos minutos?

Y las bases de datos? Seguro que escuchaste que en AWS hay más de 16 bases de datos diferentes.

En este video te ayudo a elegir y te explico los servicios más populares.

PARTE 4 - Buenas prácticas y arquitecturas recomendadas

Las buenas prácticas son fundamentales para el desarrollo de software que sea sostenible en el tiempo. También tener arquitecturas correctas nos va a ayudar a que nuestra aplicación pueda escalar.

Y la primer pregunta que me vas a hacer seguro es: "Qué buenas prácticas tengo que tener para poder hacerlo de forma escalable en la nube?"

Aca Memo Doring te cuenta lo que son las aplicaciones modernas y muchísimas buenas prácticas.

Los sistemas de microservicios en la nube son complejos y en general hablan entre ellos usando algún sistema de envio de mensajes.

En este video Vanessa Hernandez nos cuenta diferentes patrones de integración y nos muestra muchos ejemplos.

Cuando hablamos de sistemas distribuidos muchas veces nos preguntamos cómo diseñarlos?, qué arquitecturas usar?arquitecturas orientadas a eventos or orquestradas?

Hablando de arquitecturas orquestradas, seguramente querés saber más sobre AWS Step Functions. Este es el servicio totalmente gestionado por AWS para orquestrar aplicaciones.

Y si querés usar la arquitectura orientada a eventos. AWS EventBridge es el servicio gestionado de AWS que nos ayuda.

En este video te muestro paso a paso como hacerlo y entramos en detalles de las arquitecturas orientadas a eventos.

Otra buena práctica es Infraestructura como código. Pero qué es? Para qué sirve?

En este video habló con Damian Olguin sobre esto y nos cuenta su experiencia.

AWS Cloudformation es la forma de definir infraestructura como código de forma nativa en AWS.

Quéres saber más sobre CloudFormation y cómo utilizarlo?

En este video Memo Doring te cuenta cómo

AWS CDK es una forma de definir infraestructura usando lenguajes de programación populares, como Java, Javascript, .NET.

Esta genial para desarrolladores y en este video te muestro paso a paso como empezar

PARTE 5 - Serverless

Durante varios de estos videos, seguro que escuchaste la palabra SERVERLESS mil veces. Pero qué es serverless? Qué significa que algo es serverless?

En este video en menos de 10 minutos te lo explico!

AWS Lambda es un servicio de computo sin servidor. A veces parece hasta mágico. Pero los desarrolladores lo aman!

Querés saber más sobre Lambda? Y como arrancar con serverless en AWS

Te gustaría hacer aplicaciones serverless usando infraestructura cómo código de forma fácil y rápida

En este tutorial entramos paso a paso para aprender a usar AWS SAM.

PARTE 6 - Contenedores

Si Serverless no es lo tuyo y necesitas tener contenedores, sabias que AWS tiene 18 formas diferentes en las cuales podes desplegar contenedores?

En este video te lo contamos todo con Isabel Huerga

De las 18 formas de desplegar contenedores en #AWS esta en mi opinion es la forma más fácil de hacerlo es usando AWS Lightsail!

Otra forma muy fácil de desplegar contenedores en AWS usando contenedores es con AppRunner.

AppRunner es un servicio nuevo que nos permite de forma fácil desplegar aplicaciones conteneirizadas.

Si vos ya sos un experto en #Kubernetes y te gustaría empezar a usarlos en #AWS, también hay una solución para ti.

En este video Mario Mercado nos introduce a Kubernetes, y a los servicios de AWS que nos ayudan a desplegar apps que usan Kubernetes

PARTE 7 - Otro tipo de aplicaciones

Wordpress

Y qué pasa si uso Wordpress, puedo usar #AWS?

En este video te muestro como hacer todo con AWS de forma super fácil y económica para hostear tu blog.

Aplicaciones web o mobile

Y si soy desarrollador de cliente o full-stack? Cómo empiezo con la nube?

Usando AWS Amplify! En este video les cuento sobre qué es y cómo empezar con el desarrollo full-stack en AWS.

AWS Amplify esta buenísimo, y querés empezar a usarlo. Y te encantaría que tu equipo lo pueda usar sin tener una cuenta de AWS!

Acá te dejo un tutorial de cómo hacerlo.

Aplicaciones de Inteligencia Artificial

AWS ofrece muchísimas APIs para construir aplicaciones super interesantes sin conocimientos de AI/ML.

En este video Nahia Orduña nos introduce a todos los servicios.

Otra forma de desarrollar aplicaciones en Inteligencia Artificial en AWS es creando Alexa Skills.

Si querés saber cómo podes usar todo los conocimientos que aprendiste en este blog para hacer tu app de Alexa, mira este video donde Joaquin Engelmo (Kini) y Javier Ramirez nos cuentan cómo hacerlo.

PARTE 8 - Migraciones

Y por último me podes preguntar: "Y qué pasa si quiero migrar una aplicación que ya existe a la nube y a nuevas arquitecturas serverless y de contenedores?"

En este video Hernan Garcia te muestra como hacerlo

En este video te cuento unas historias de cómo se pueden migrar aplicaciones tradicionales a serverless y qué pasos seguir.

FIN!

Llegamos al final del blog! Si te gusto compartilo!

Dejame un comentario que te parece que falta? Así durante el 2022 hacemos contenido de esos temas.

Todos los videos viven en una playlist así los podes ver de forma ordenada.