DEV Community: Jones Zachariah Noel

The Jitter Strategy for Step Functions Error Retries on the New Workflow Studio

Jones Zachariah Noel — Fri, 06 Oct 2023 17:06:28 +0000

AWS Step Function just announced a new enhanced error handling and retry mechanism in State Machine executions that enables more fine-grain control of error retry rules. And also uses the enchanced Workflow Studio authoring experience to build the workflow.

Read more about how error handling works on Step Functions but in this blog, we will focus more on the new parameters in error handling with catch and retries on Step Functions such as MaxDelaySeconds and JitterStrategy.

Errors in Step Functions

During the execution of a State Machine, there are possibilities of execution would be interrupted by various errors such as States.Timeout when the task execution has taken more than TimeoutSeconds defined as when it failed to get a heartbeat longer than HeartbeatSeconds defined.

Some of the possible errors are listed below.

States.All wildcard is available on Step Functions to work with all the errors encountered during the execution.

Deploying a State Machine

Navigate to AWS Step Functions Create state machine and then select the Orchestrate Lambda Functions template with the new console experience.

Once the template is selected, Workflow Studio will give you more details of the template.

The Orchestrate Lambda Functions template showcases the stock buy/sell recommendation based on the stock price. Choose Run a demo option to deploy the state machine and other resources such as Lambda Functions with SNS and SQS to your AWS Account.

To test out the state machine, you could run a sample execution.

Updating the State Machine with error retries

Enabling retry

Let's update the Check Stock Price state which invokes a Lambda function with an error retry with a few retry options

{
    "Retry": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "BackoffRate": 2,
          "IntervalSeconds": 1,
          "MaxAttempts": 3,
          "Comment": "Check Stock Price Lambda error",
          "MaxDelaySeconds": 2
        }
}

In this error retry snippet, the wildcard States.ALL error listens to all the errors in this state to perform a retry. This retry has a few other options -

IntervalSeconds is an integer that specifies the number of seconds before the first retry.
BackoffRate which is a property that would multiply the IntervalSeconds property to determine the next retry would occur.
MaxAttempts defines the maximum number of retries possible.
MaxDelaySeconds defines the maximum time in seconds that the retry interval can increase.

When the state machine is executed with an error retry in the first state,

Retry	Retry attempt second
1st retry	1s (`IntervalSeconds`)
2nd retry	3s
3rd retry	6s

Enabling retry with JitterStrategy

In the second Generate Buy/Sell recommendation state, enabling retry for all States.ALL wildcard with the below retry options -

{
    "Retry": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "JitterStrategy": "FULL",
          "Comment": "Buy/Sell recommendation error",
          "MaxAttempts": 5
        }
      ]
}

Along with the previously enabled options, the additional property set is - JitterStrategy as FULL. When JitterStrategy is enabled with the value FULL, it randomizes delay intervals so that the retry mechanism doesn't retry excessively, this is very powerful especially when Lambda is invoked concurrently.

When the error occurs in the Generate Buy/Sell recommendation state,

Retry	Retry attempt started after
1st retry	00:00:01.298
2nd retry	00:00:01.479
3rd retry	00:00:01.752
4th retry	00:00:02.986
5th retry	00:00:04.213

Notice the retry attempts are between 1s and 5s (MaxAttempts) which are random when compared to the previous case without JitterStrategy.

Enabling Fail flow

Whenever failing the state machine, it throws an error and the cause that can customize the error states. But for this flow, enabling a custom error message defined in the state machine for the choice state.

{
    "Fail": {
      "Type": "Fail",
      "Error": "Stock prediction failed",
      "Cause": "Unable to proceed as stock prediction to buy or sell stock failed"
    }
}

When the choice state goes through a default state, the state machine fails execution.

When the error occurs, the fail flow captures the error as Stock prediction failed with the cause Unable to proceed as stock prediction to buy or sell stock failed.

Keep a watch on retries

When working with state machines that have multiple states with retries defined in all or many of them, the retry mechanism would retry until MaxAttempts.

Q: It's good to retry multiple times

Well, not if the computing brains or the state would reproduce the same error. However, definitely good when retrying would result in success.

Q: Multiple retries shouldn't cause interruptions in my state machine execution

If the retries result in a success, it won't interrupt the state machine execution. But if the same error occurs, better to fail the execution with passing events to EventBridge or DLQ.

Q: Would this be expensive?

In a Standard workflow, state machine execution is priced based on every state transition and when retry is configured there would be a state transition for each retry attempt this would be expensive.

Also, the retry attempt is invoking another AWS resource, that execution would also be billed. In this workflow, the Lambda function was invoked multiple times which also accounts for the total workflow cost.

Wrap up!

The retry mechanism would help when working with resource-based errors such as Lambda.ServiceException or any other AWS Service error based on the task. With JitterStrategy enabled, addresses the concurrent retries.

Note, this example was to showcase the features with error retry and fail flow.

Buses and queues: Head-on

Jones Zachariah Noel — Thu, 05 Oct 2023 17:53:12 +0000

Choosing between Amazon EventBridge Buses and Amazon SQS queues

Amazon EventBridge is a serverless managed service for event-driven applications to build loosely coupled applications and route events smartly across different services.

You can read more about how Amazon EventBridge is the missing piece to your app.

Also, if you are wondering about Amazon SQS, learn about getting started with SQS and SNS and understand Standard and FIFO queues (in SQS) and topics (in SNS) with the understanding of when to use SQS and SNS in your Serverless architectures.

In this blog, we will look into Amazon EventBridge buses and Amazon SQS queues and how and where they fit right into your Serverless architectures.

Catch the bus!

Building event-driven architectures

When building EDA applications, Amazon EventBridge is best suited, as EventBridge provides you with different capabilities for service-to-service integrations across various sources in the Serverless space. Also ensuring the architecture is loosely coupled.

Event routing and filtering

EventBridge is known for its smart routing feature with event rules and also the support of filtering based on different filters and filter patterns. When building for service-to-service integrations, the routing helps with designated events routed to destined destinations.

Integrations

EventBridge supports different service integrations such as AWS Lambda, AWS Step Functions, SQS, SNS, and many more. While these are natively supported service integrations, EventBridge also supports SaaS Partner integrations and third-party HTTP end-points with API destinations.

Get in the queue!

Building message queues

When building applications, you may have to build messaging queues that need reliable and ordered delivery. SQS ensures this with FIFO queues and also enables load balancing with horizontal scaling.

Fan out patterns

Messages which have to be distributed across multiple consumers would efficiently process each message by each consumer. Fan-out patterns are best suited with Amazon SQS as it enables a balancing queue for the consumer.

Time-bound delivery

Amazon SQS has capabilities where messages could be configured to deliver the message to the consumer using the DelaySeconds parameter. Also, the messages can hold a time-to-live (TTL) attribute beyond which the message is removed from the queue. SQS supports visibility timeouts where the message is invisible and can be reversed for consumption later.

EventBridge v/s Queue

Feature	Amazon EventBridge	Amazon SQS
Complex processing	✅ EventBridge supports transformation and filtering which makes it easy to process complex events.	🚫 SQS can have targets as Lambda to process but cannot process them on its own.
Multiple destinations	✅ EventBridge supports multiple AWS services as the destination and also API destinations for external HTTP endpoints	🚫 Would need a Lambda function or EventBridge pipe to consume the message and programmatically route it to the destination.
Scheduled messages/events	✅ EventBridge scheduler helps to build event scheduling with CRON patterns.	🚫 SQS cannot trigger or push messages at scheduled times.
Ordering	🚫 EventBridge doesn't ensure strict ordering.	✅ FIFO queues could be used to ensure FIFO ordering.
Delay messages	🚫 EventBridge immediately delivers the event as it occurs.	✅ SQS supports delays in messages with `DelaySeconds`
Message retention	✅ Only when archival is enabled, messages are retained for future use.	✅ SQS Supports TTL and DLQs for handling failed messages.
Throughput	10,000,000 events per second in a bus.	10,000 messages per second in a queue.
Payload limits	256 KB max supported.	256 KB max supported.

Co-existence of EventBridge and SQS

While individually EventBridge and SQS can add a lot of value to the Serverless architecture, the combination of the two in certain patterns is possible.

Messaging queues with event-driven patterns where both SQS and EventBridge can be used in combination. EventBridge in this pattern would broadcast events to multiple subscribers and SQS would be enforcing correct message ordering.

Messages in SQS could be consumed by EventBridge pipes for better event enrichment and transformation of events to the needed destination without having Lambda functions to be performing a transformational workload on messages.

Ultimately, it is about what the workload is and how each of the services - EventBridge or SQS either individually or in combination can elevate your Serverless architecture.

Maintaining Lambda Function Performance During Peak Traffic

Jones Zachariah Noel — Wed, 04 Oct 2023 16:46:22 +0000

AWS Lambda functions are the popular computing option for modern applications, specifically if you use Serverless or event-driven architectures on AWS. And these Lambda functions are invoked billions of times in a production environment.

AI-generated image by Adobe Firefly - "Heavy traffic in Serverless cloud"

In this blog, we will understand what are the different sources for Lambda triggers and also understand the factors to ensure performance during peak traffic.

Lambda trigger sources

AWS Lambda function is well-knit with different sources triggering them either on demand or event-based. Understanding the source of Lambda function triggers would help in addressing performance during high traffic.

Invoked via HTTP API

Lambda functions would be the core compute of the backend systems which are served over API endpoints generated from Amazon API Gateway or AWS AppSync or Lambda Function URLs. These are often triggered by applications programmatically either from a front-end application or backend systems.

AWS Services invoking Lambda

In event-driven architectures, another AWS Service usually triggers the Lambda function whenever certain events occur.

A typical scenario would be, whenever there is a new object uploaded into a S3 bucket, a Lambda function could be triggered with the details of the event payload so that Lambda can further process it.

Performance with heavy traffic

When using Lambda functions, being mindful of what it offers and how best it fits into your solutions is essential.

AI-generated image by Adobe Firefly - "busy day in a traffic cop life managing traffic".

Load balancers

Load balancers, even from the traditional systems are that piece of architecture that enable smooth traffic distribution. In a serverless system also, load balances help with distributing traffic and also ensuring there isn't a burst of invocations of Lambda functions.

Enable caching

For frequently accessed data, enabling caching in your architecture at different levels would improve performance which on a high-traffic day pays off!

Allen and me (Jones) authored a blog with Momento about how caching at every layer improves app performance.

Provision and reserved concurrency

With Lambda's provision and reserved concurrency, you can allocate the resources which would be needed when you anticipate a high traffic flow. This ensures the architecture would be able to perform better on a peak traffic day.

Weighted routing

Each lambda function is assigned weights and the weighted routing would use these weights as the measure to distribute traffic amongst different Lambda functions and in the case of Lambda aliases, it helps with distributing traffic amongst different versions of the Lambda function.

Triggers with batch

When defining the event triggers for Lambda functions, different services like DynamoDB, SQS, and other messaging services support batch triggers where the service would collectively trigger the Lambda function once as per the BatchSize defined.

Options for Serverless Architecture

Application Load Balancers (ALBs)

ALBs support targets as Lambda functions which help in distributing traffic with weights, geographical and round robin way.
Provides endpoints available over the public internet which helps in building APIs that can be backed with ALBs and Lambda functions.
ALBs are complex to configure when compared with other options available.
With the management and configurations, this is not truly a serverless way!

Amazon API Gateway

Available by design to configure API Gateway integration with Lambda functions. And also seamless to work with API Gateway when compared with ALBs.
API Gateway enables the usage of API key based usage quotas and throttling controls.
Supports multiple authentication and authorization options.
Supports payload validation with models where in a peak traffic scenario, API Gateway will ensure the validated payloads are invoking the Lambda function thus eliminating junk requests.
Supports WAF and CloudFront-based endpoints which has added security for DDoS attacks.

Lambda aliases

Traffic distribution at the Lambda level when using it with different AWS Services as triggers.
Configuration involves creating multiple versions of the same Lambda function and assigning an alias to one or max two versions.
Supports weighted routing to each alias in a Lambda function.
Not the best fit for Lambda functions which need to be invoked via the public internet as it lacks authentication and throttling.

Wrap up!

Lambda functions have proven scalability and perform well even during peak traffic. Keeping in mind different aspects of Lambda functions or other AWS Services that enrich your traffic management is the key when architecting solutions that are prone to high traffic.

With the different options of ALBs, API Gateway, or even Lambda aliases, each of them has an upside and downside depending on the use case and how they are placed in the serverless architecture.

Re-think and Re-architect Your Application

Jones Zachariah Noel — Tue, 03 Oct 2023 17:43:41 +0000

Recently, Amazon Prime Video revealed about moving their architecture from serverless to monolithic container-based architecture. Read more about Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% by the Amazon Prime Video tech team.

Initial architecture of Prime Video

Few pointers from the tech blog about the initial architecture,

Distributed and microservices approach in their initial architecture.
A serverless architecture primarily built on AWS Lambda functions and AWS Step Functions.
Designed with the intent of Serverless being cost-effective and scalable because it was on-demand scaling up or scaling down of Lambda functions which resulted in keeping cost intact.

Image courtesy: Prime Video blog post - https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Reasons why Serverless was a challenge

Prime Video is one of the popular OTT platforms, and the assumption here is that they would have peak traffic and the workload in this traffic times is what the architecture to hard test in terms of -

Scalability

Yes, Serverless applications can scale well. But the main concern of scalability came in with orchestrating the Serverless workload with AWS Step Functions.

The main scaling bottleneck in the architecture was the orchestration management that was implemented using AWS Step Functions. Our service performed multiple state transitions for every second of the stream, so we quickly reached account limits.

As quoted in the blog post. Often when building Serverless applications when they hit a peak moment, there are challenges -

Managing the distributed architecture because you have too many microservices doing various dedicated tasks even though it's a State Machine defined.
AWS Step Functions bring in limits in payload passed across states, the number of state machine executions where there should be workarounds in place to ensure the system doesn't breach the limits.

Cost-effectiveness

Serverless applications are cost-effective because they run on demand and when certain events/requests are made.

Besides that, AWS Step Functions charges users per state transition.

AWS Step Functions have a per-state transition pricing model, for instance, in us-east-1 region that has $0.025 per 1000 state transitions, Prime Video would have a large number of state transitions happening as this state machine itself is used to detect if any defect is there in the video frames.

The second cost problem we discovered was about the way we were passing video frames (images) around different components. To reduce computationally expensive video conversion jobs, we built a microservice that splits videos into frames and temporarily uploads images to an Amazon Simple Storage Service (Amazon S3) bucket. Defect detectors (where each of them also runs as a separate microservice) then download images and processed it concurrently using AWS Lambda. However, the high number of Tier-1 calls to the S3 bucket was expensive.

The microservice which is used to split videos in frames uploads images to an S3 bucket and these images are processed to detect defects where there would be 1000s of frames in a single video which itself would have S3 bucket costs high with respect to storage, data transfer and the cost of high-performance Lambda functions which run in parallel.

Reaction to the challenges

The reasons mentioned are very valid and the Prime Video team has taken some steps to address this -

Re-think

It is important when you have scalability and cost-related concerns with your architectures that you start to take a step back and think - "what could have been the possible best solution?" or "what kind of components suit this use-case". Sometimes, it begins with the basic question of "why do we need XYZ service" when the challenges stand out.

The first approach to adapting Serverless is good but when the architecture is not meeting the need in this use-case, the approach taken to re-think says how flexible we have to be in our architecture.

Re-architect

When we re-think, it is obvious that we get more clarity with what is the use case and what architectural approach and components would be the best fit. Once we identify the best fit architectural approach or components, re-architecting the complete workload would be the way to go.

In Prime Video's case, there was a shift from Serverless to a monolith because the system would always be processing images, and data transfer between different Services would make it an expensive workload but with the new architecture, the ECS task performs the orchestration of detecting deflects using the video buffer directly from Media Converter.

Resonating my thoughts

When the internet broke out with Prime Video moving away from Serverless, me being a Serverless advocate was shocked "why"!

But reading and understanding the blog post, appreciate the architectural shift even when it means that Serverless architecture is revamped into a monolith.

Serverless first, Serverless not always

It's good to approach with the Serverless mindset and building with Serverless but if that doesn't work for your workload then "revert! revert! revert!". Sometimes, Serverless may never be the right approach, and investing in that would mean that it would turn out to be expensive in the longer run.

One size doesn't fit all

We assume that if any approach works for someone out there, it would work for me as well. As it's repeatedly mentioned, "Serverless scales and is cost-effective" it is true but also we need to understand if the Serverless approach or any other approach in general would be the best fit for the use case.

Iterative building

Oftentimes, the use-case evolves or the usage evolves which translates to the architecture should be adaptive and get there it's always with different iterations. Take software development as the instance where we go through different revisions and iterations to get to production and if we see the architecture of the software being developed, that too would have gone through revisions. These revisions are where the learning happens, to identify if the architecture is well-architected or not.

Workarounds for AppSync Subscriptions triggers via Lambda functions

Jones Zachariah Noel — Mon, 02 Oct 2023 16:56:13 +0000

AWS AppSync is a serverless GraphQL offering by AWS, previously I authored a blog about AWS AppSync 101 which gets you up to speed with the capabilities of AppSync and how you can leverage them in your serverless applications.

One query that stands out is that -

AppSync subscriptions work amazing when client makes mutations but I have some downstreaming patterns in my application where the backend uses subscriptions to send data from back-end to front-end, how do I achieve this with AppSync?

Ask ChatGPT

Well, this does look simple so why not ask ChatGPT?

What would be the better way to handle AppSync Subscriptions which are triggered with Lambda functions?

ChatGPT's solution

Use the appropriate trigger:

To use the appropriate trigger, you can create a trigger on the event that is relevant to your use case. For example, if you want to trigger a subscription when a record is added to a database, you can use a database trigger to invoke your Lambda function.

Here's an example using AWS Lambda and Amazon DynamoDB:

Create a DynamoDB table with a stream enabled.

Create a Lambda function that is triggered by the DynamoDB stream.

In the Lambda function, write code that parses the stream event and invokes the AppSync subscription.

And also, ChatGPT generated the code snippet for this.

// Sample code for a Lambda function that is triggered by a DynamoDB stream

exports.handler = async (event) => {
  // Parse the DynamoDB stream event
  const records = event.Records.map((record) => {
    return {
      eventName: record.eventName,
      record: record.dynamodb.NewImage,
    };
  });

  // Invoke the AppSync subscription
  const appSyncClient = new AWSAppSyncClient({
    url: 'https://my-appsync-endpoint.aws.com/graphql',
    region: 'us-east-1',
    auth: {
      type: 'AWS_IAM',
      credentials: AWS.config.credentials,
    },
  });

  const mutation = gql`
    subscription OnRecordAdded {
      onRecordAdded {
        id
        name
      }
    }
  `;

  const observable = appSyncClient.subscribe({ query: mutation });
  observable.subscribe((data) => console.log('Subscription data', data));
};

And the GraphQL schema for this was also generated by AppSync.

type Record {
  id: ID!
  name: String!
}

type Subscription {
  onRecordAdded: Record!
}

type Mutation {
  addRecord(name: String!): Record!
}

type Query {
  getRecord(id: ID!): Record
}

Let's validate ChatGPT 's response

Do you notice something from ChatGPT's response? Now let's put on the Serverless architect lens and see how this would be implemented.

GraphQL schema

The schema generated by ChatGPT is a generic one that looks good at first look but when from the application's perspective, all the operations - query, mutation and subscription are accessible based on the default authorization set on AppSync.

Ensure the subscription is defined for a specific mutation, this is to be noted when you have multiple mutations. Although this looks good in this single mutation schema however it's good to define them with @aws_subscribe directive.

type Subscription {
  onRecordAdded: Record
  @aws_subscribe(mutations: ["addRecord"])
}

Irrespective of what authorization is used in your application for the client (be it Cognito User Pool, API Key, Lambda authorizers or AWS IAM role), define the mutation which would be invoked from the Lambda function as AWS IAM role.

type Mutation {
  addRecord(name: String!): Record!
  @aws_iam
}

GraphQL resolvers

The conversation with ChatGPT didn't initially give me a resolver for the mutation addRecord, but a follow-up query did generate a VTL resolver (understand JS resolver is a very new, and fair guess that model doesn't know what JS resolver is at this point).

This VTL resolver defines the PutItem operation for the Mutation type in the AppSync schema. It uses the $ctx.args variable to extract the name argument from the mutation, and then generates a new id for the item using the $util.autoId() function. The resolver constructs a DynamoDB PutItem request using these values, and then returns the request in JSON format.

#set($name = $ctx.args.name)
#set($id = $util.autoId())
{
    "version": "2018-05-29",
    "operation": "PutItem",
    "tableName": "my-table",
    "item": {
        "id": { "S": "$id" },
        "name": { "S": "$name" }
    }
}

You may notice that the VTL resolver generated is doing a DynamoDB PutItem action even though the response ChatGPT gave didn't have the schema treating the Record type as a model or even give the steps to create a DynamoDB data source.

For the simplicity of things, let's create a simple VTL resolver that generates an ID and returns the name with the data source being a None type.

Request mapping template

{
    "version": "2017-02-28",
    "payload": {
        "name": "$context.arguments.name",
        "id": "$util.autoId()"
    }
}

Response mapping template

$util.toJson($context.result)

And the mutation addRecord is ready to be tested!

Lambda function to trigger subscriptions on client-end

The solution that a Serverless architect would have come up with is the one above, where any Lambda trigger could invoke the Lambda function, and the Lambda function in turn uses an AppSync mutation and on the successful execution of the mutation, the subscription is internally invoked by AppSync.

The Lambda function generated by ChatGPT uses AppSync Client SDK. And it subscribes to an AppSync subscription rather than a mutation. 🤔 Why! 😵‍💫

const observable = appSyncClient.subscribe({ query: mutation });
observable.subscribe((data) => console.log('Subscription data', data));

Firstly, create a Lambda layer with the npm dependencies -

npm install aws-sdk aws-appsync graphql-tag isomorphic-fetch axios

Create your Lambda function with the environment variable set with the AppSync API endpoint.

require('isomorphic-fetch');
const AWS = require('aws-sdk/global');
const AUTH_TYPE = require('aws-appsync').AUTH_TYPE;
const AWSAppSyncClient = require('aws-appsync').default;
const gql = require('graphql-tag');

const config = {
    url: process.env.APPSYNC_ENDPOINT,
    region: process.env.AWS_REGION,
    auth: {
        type: AUTH_TYPE.AWS_IAM,
        credentials: AWS.config.credentials,
    },
    disableOffline: true
};

const createTodo = gql`
    mutation MyMutation($name: String!) {
      addRecord(name: $name) {
        id
        name
      }
    }
`;

const client = new AWSAppSyncClient(config);

exports.handler = async function (event) {
    console.log("event ", event);
    try {
        const result = await client.mutate({
            mutation: createTodo,
            variables: {
                "name":event.name
            }
        });
        console.log("result ", result);
        return result
    } catch (error) {
        console.log("error ", error);
        return error
    }
};

credentials: AWS.config.credentials uses the IAM credentials from Lambda's runtime and for this to work, you would have to define

Update your Lambda's execution role with the policy -

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "appsync:GraphQL",
            "Resource": "<Your AppSync ARN>"
        }
    ]
}

Back to your Lambda console, create an Event JSON.

{
  "name": "This is a record from Lambda fn"
}

When testing the subscription from the AppSync console. The API by default uses API Key as authorization.

Behind the scene, the event was tested from the Lambda function console and here the mutation is authorized by AWS IAM.

Wrap up

ChatGPT gave us a high-level solution in terms of what needs to be done but the how to execute and the minor details were missed out, this is exactly where Serverless architects would come into the picture to start building on top of what AI suggests.

The TL;DR of this is that you can start to get solutions from ChatGPT but the accuracy of how well it solves is something humans would have to intervene on. And building Lambda functions that invokes an AppSync mutation to trigger subscriptions would be helpful when you are relying on real-time sync from external sources other than the support data sources from AppSync.

Serverless development with Amplify Studio

Jones Zachariah Noel — Sun, 01 Oct 2023 15:32:00 +0000

As full-stack developers, we often love to develop applications out of the box with tools that can visually design your application's UI and define your data and API layers that can seamlessly integrate with the application's UI.

AWS Amplify Studio amplifies your development with front-end and back-end by provisioning the right AWS resources under the hood for the right purposes and also the ability to easily integrate into the design.

Working with data

Amplify Studio makes it really easy to define and manage your data irrespective of the environment it's used in.

Defining your data

Amplify Studio's Data allows you to define Amazon DynamoDB keeping in mind the properties with the right type and also powered with AWS AppSync where which generates a GraphQL schema under the hood.

enum TopicLevelEnum {
  INTRODUCTORY
  INTERMEDIATE
  ADVANCE
}

type InfoCard @model @auth(rules: [{allow: public}]) {
  id: ID!
  title: String!
  short_description: String!
  long_description: String!
  thumbnail_url: AWSURL!
  categories: [String!]
  services: [String!]
  topic_level: TopicLevelEnum
  aws_docs_url: String!
  aws_workshow_url: String
  community_url: String
  aws_samples_url: String
  dislikes: Int
  url: String
  s3_thumbnail: String
  likes: Int
}

type Service @model @auth(rules: [{allow: public}]) {
  id: ID!
  service_name: String!
  category_name: String!
  logo_url: AWSURL!
  url: String
  s3_logo: String
}

Now that data is defined and the AWS resources - AppSync API and DynamoDB tables for the same are created with @model directives by AppSync. Since the API is using public read, @auth(rules: [{allow: public}]) is part InfoCard and Service this will ensure that the auto-generated CRUD APIs for them will allow public access.

Generating data

The content management feature of Amplify Studio is elegant for ensuring an admin/content creator role to create or update content that the front-end application would be consuming. This uses the data definition based on your GraphQL schema and DynamoDB schema with a form-based input.

Amplify Studio also has an underrated feature that developers would love when using this during the course of development, Amplify Studio has auto-generate data which is handy for the development phase where developers need not worry about "there isn't enough data to display on the front-end" instead generate up to 100 records with the feasibility of setting some constraints so that you get valid data.

Test your data

With the data populated, you would need to ensure the GraphQL APIs with AppSync are working as expected. Amplify Studio also features a GraphQL editor to simulate and test the APIs.

The simulator provides the API docs - where you can navigate the different queries, mutations or subscription.

Amplify Storage

Amplify Storage let's you manage the media files and assets which are stored on Amazon S3. Amplify Storage will first create the Amazon S3 bucket where you can set the authorization rules for user to upload, view or delete the objects (files in this case) on S3 bucket.

Managing files on Storage

From Amplify Storage, you can navigate across different levels of folders and files and upload the files or create folders. Amplify Studio also provides your with a snippet of code that uses Storage APIs to get the file.

const file = await Storage.get("aws-amplify/auth/aws-amplify-auth.md", {
    level: "public"
});

Figma design to code

Using the getting started Figma design from the community and the components available in this design uses the design guidelines which is a subset of AWS Amplify UI Kit that has a collection of UI components for different UI frameworks both web and mobile.

With my limited knowledge of Figma designing and using the pre-defined components and modifying the components as per my requirement, I've successfully created three components - ServiceCard, FeatureCard and InfoCardDetails .

On successfully authorizing AWS Amplify Studio to access Figma designs from my Figma account, the UI Library on Amplify Studio lists all the components ready to be configured and imported into your Amplify project.

Component configuration

FeatureCard is now ready to be configured with the data that is defined. Amplify Studio provides a tree for all the elements created in this component and configuring different component properties.

Firstly, map the component to the data model that is used in the component.

Set each of the child properties with the data from the defined data model. In the above screenshot, you can see the title of the card is set with infoCard.Title to the label property of the child component.

In case of InfoCardDetails component, the data model defines URLs for documentation, samples and workshop. For those to be functional as a button onClick event, Amplify Studio allows those configurations where you can specify the target by selecting Open URL in new tab and also mapping the equivalent data from InfoCard data model.

Collection components

In the component configuration page, click on Create collection button.

The collections can be configured with properties that can make the collections UI really customizable in terms of how they would appear as a - List or Grid, ordering, spacing, alignment, enabling search functionality in the collection and also pagination with the page size.

The collections could also be configured with filters which are applied to the collections and also define the sort conditions.

Sync Amplify Studio with local IDE

With the data and UI configurations done on Amplify Studio, these changes can be synced to your local IDE with Amplify CLI.

amplify pull --appId your-amplify-project-id --envName your-env

This will create all the amplify related files in your local project folder with amplify backed and resources configurations under /amplify folder. In your src folder, the UI components and data model related files are generated in /ui-components folder and /models folder respectively.

Importing and using components

Installing the needed npm dependencies.

npm install -g @aws-amplify/cli
npm install aws-amplify @aws-amplify/ui-react

In index.js file, configure Amplify.

import { ThemeProvider } from "@aws-amplify/ui-react";
import { Amplify } from 'aws-amplify';

import awsconfig from './aws-exports';

import "@aws-amplify/ui-react/styles.css";
import { studioTheme } from "./ui-components";

Amplify.configure(awsconfig);

Using a theme from Amplify with ThemeProvider.

<ThemeProvider theme={studioTheme}>
  <App />
</ThemeProvider>

Import the UI component created and configured from Amplify Studio.

import {
 FeatureCardCollection 
} from './ui-components';

Modifying the components locally

From the above screenshots, you may have noticed the images being broken while previewing on Amplify Studio. Let's modify the InfoCardDetails component to retrieve data from Amplify Storage.

import React, { useEffect, useState } from "react";
import {
  getOverrideProps,
  useNavigateAction,
} from "@aws-amplify/ui-react/internal";
import { Button, Divider, Flex, Image, Text } from "@aws-amplify/ui-react";
import { Storage } from "aws-amplify"
import { useHistory } from "react-router-dom";

export default function InfoCardDetails(props) {
  const { infoCard, overrides, ...rest } = props;
//Set the states
  const [imageThumbnail, setImageThumbnail] = useState('')
  const [mdDoc, setMDDoc] = useState('')
  useEffect(() => {
    fetchImage()
    fetchMD()
  }, [])

//Using Amplify Storage to download images 
  async function fetchImage() {
    try {
      const image = await Storage.get(infoCard.s3_thumbnail, {
        level: "public"
      })
      setImageThumbnail(image)
    } catch (err) { console.log('error fetching images') }
  }
....
//Setting image to Image component
            <Image
              width="unset"
              height="408px"
              display="block"
              gap="unset"
              alignItems="unset"
              justifyContent="unset"
              shrink="0"
              alignSelf="stretch"
              position="relative"
              padding="0px 0px 0px 0px"
              objectFit="cover"
              src={imageThumbnail}
              {...getOverrideProps(overrides, "image")}
            ></Image>
....
}

After modifying the same in FeatureCard and ServiceCard, locally run the app with npm start.

The app renders all the images after they are downloaded from Amplify Storage.

Wrap-up

Building applications with Amplify Studio has certainly amplified developer experience with defining, provisioning, and also managing different AWS services.

Having to do it manually for a full-stack developer during development would mean that they would need in-depth knowledge of all those underlying AWS services.

Amazon EventBridge: The missing piece to your app

Jones Zachariah Noel — Sun, 05 Mar 2023 14:25:10 +0000

Amazon EventBridge is a Serverless AWS Service that enables building event-driven applications with seamless integrations with multiple AWS Services and AWS Partner SaaS applications.

Launched in 2019, it was focused on building pathways for SaaS Product events to be consumed and routing the events to the AWS Lambda function. It initially supported buses and CloudWatch Events which was previously part of AWS CloudWatch. Since then, a lot of powerful features have been added to EventBridge to build an event-driven Serverless app.

EventBridge Buses

Event Buses are the communication channel that receives events from different event sources which could be AWS Services such as Amazon S3 which is posting in events whenever there is any action happening in an S3 bucket, programmatically using EventBridge APIs to send events to a default or custom bus or events from a partner SaaS product posting events to a defined SaaS event bus. Once the events are available on the bus, event rules are used to route the event to the right designation these rules have powerful filtering capabilities which can be applied to event payloads.

Some scenarios, where you would be using it in your application -

An S3 event that is putObject event would be routed to AWS Lambda functions for further computation or AWS Step Functions to kick-start a state machine execution.
An S3 event that is deleteObject would result in invoking an API destination that would use the Input Transformer to restructure the event as per API's specifications.

Note: these rules are specific to event buses, and there can be multiple rules in a bus.

EventBridge Pipes

EventBridge Pipes enable direct point-to-point integrations from defined event sources like Amazon DynamoDB streams, Amazon Kinesis, Amazon SQS, and more which can be filtered with advanced EventBridge filtering on the event payloads.

{
  "eventName": [{
    "prefix": "INSERT"
  }]
}

The filtered events could be enriched to uplift the data before it is delivered to the target AWS Service. Input Transformer is available for the enrichment and target states which can transform to the expected payload structure by the AWS Service and also define the output path.

EventBridge Pipes, opening up the direct service integration with advanced filtering and enrichment

EventBridge Pipe uses events from DynamoDB streams on any action on a DynamoDB table and would use filtering to process only eventName: INSERT for newly created items on DynamoDB and invoke a state machine execution.
New messages from Amazon MQ could be used to start a state machine execution.

EventBridge Scheduler

EventBridge Scheduler is a way to schedule your tasks that happen from time to time and need recurring events with corn expressions, time windows, and one time with a specific date and time. These events from the scheduler could be targeted to a specific AWS Service where the event payload set in the scheduler will be delivered.

Tasks that have to be performed every day at a specific time (like 1 am).
Workloads that generate billing every month where the scheduler can invoke a Lambda function to generate bills.

In a nutshell

Amazon EventBridge can be a crucial component of your Serverless applications which could be solution-ed to deliver the right events effectively to the destinations. For Event-driven architectures that consume a multitude of events, EventBridge can easily scale, and events can be filtered with advanced filtering capabilities. EventBridge eliminates the glue-coded Lambda functions which might contain additional logic to validate the events against certain patterns which are necessary to the application for further processing. EventBridge Pipes enhances your Serverless workload with direct service integration that positively affects the application's performance and scalability.

In any application, the design might contain multiple features by Amazon EventBridge where specific tasks could be scheduled with an EventBridge Scheduler, all events could be sent to an Event Bus which would use Event Rules to route the events to the designated targets or have point-to-point integrations with AWS services as producer and consumer for smooth orchestration.

Building Serverless apps with more configurations

Jones Zachariah Noel — Mon, 13 Feb 2023 09:24:01 +0000

Applications built on the Serverless stack have existed for nearly a decade with AWS Lambda functions being launched in 2014. And ever since, the association of a Serverless application is always with a Lambda function.

In this blog post, we will look into how Serverless apps can be built with just configurations and leveraging the features of AWS Services which can integrate with different services.

Why do we need direct integrations?

The AWS Services with direct integrations capabilities improve the architectures by removing the glue code needed.

Just let us think about building REST APIs with AWS API Gateway which returns a particular set of data. For this, we would have to have an API Gateway stage in which GET method invoking a Lambda function which is either using query or scan to search the items on DynamoDB. The response from DyanmoDB SDK would then be returned to API Gateway from the Lambda function.

Now, let's understand how direct integrations with this would help.

Cold Starts

Now that we are familiar with the downside of having a Lambda would be the Cold Starts that we would have to be mindful of and also have a workaround to overcome them. But when doing a direct integration with different AWS Services, since we would not have a Lambda function as the middle-man or the glue code, we would not have to worry about the problem of Cold Starts.

Latency

With the removal of an additional component from the architecture, we are reducing the latency with the requests routed with a Lambda function and returning the results back. Although this would be in milliseconds, it is very accountable in a production environment where there would be 100s and 1000s of requests at a given time.

Scalability

"Would it be highly scalable when we have concurrent requests that are coming in?" With Lambda the other question of concern is, "how can we handle concurrency and ensure the application is scalable proof?" When we do a direct integration this responsibility would be on the cloud provider and the AWS Service would ensure your application could scale better.

Direct integrations with AWS Services

AWS Step Functions

Serverless applications which would need orchestration and a dedicated workflow that would integrate with multiple AWS Services are a huge win! Starting from AWS re:Invent 2021, where Step Functions announced supporting AWS SDK-based integrations there have been over 300+ API actions that are currently been supported.

There are a lot of possibilities that would open up with SDK-based integrations with AWS Step Functions, there is a blog post series about the same.

Amazon EventBridge

Amazon EventBridge plays a vital role in event-driven, choreography-based Serverless architectures. While EventBridge supports different integrations with different event sources or destinations and also configuring HTTP endpoints as API destinations.

Not only does it support AWS Services which can post events to the event bus but also with the new EventBridge Pipes, it is possible to have configurations that can integrate service to service.

For instance, before DynamoDB Streams could only trigger a Lambda function but now with EventBridge Pipes, you can build integrations where the source of the event originating from DynamoDB Streams and then it could be targeted to invoke a Step Functions state machine execution.

Amazon API Gateway

API Gateway can integrate with Velocity Template Langauge (VTL) which could be used for request and response resolver mapping and integrate with services like DynamoDB, Step Functions, Kinesis, and more.

Like the above mentioned example, API Gateway can directly integrate with DynamoDB. Take a look at the pattern from ServerlessLand. And the snippet of the same of how you can integrate an API Gateway to query DynamoDB.

  MusicArtistMethodGet:
    Type: 'AWS::ApiGateway::Method'
    Properties:
      RestApiId: !Ref Api
      ResourceId: !Ref MusicArtistResource
      HttpMethod: GET
      ApiKeyRequired: true
      AuthorizationType: NONE
      RequestParameters:
        method.request.path.artist: true
      Integration:
        Type: AWS
        Credentials: !GetAtt APIGatewayRole.Arn
        IntegrationHttpMethod: POST
        Uri: !Sub 'arn:aws:apigateway:${AWS::Region}:dynamodb:action/Query'
        PassthroughBehavior: WHEN_NO_TEMPLATES
        RequestParameters:
          integration.request.path.artist: method.request.path.artist
        RequestTemplates:
          application/json: "{\"TableName\":\"Music\",\"IndexName\":\"Artist-Index\",\"KeyConditionExpression\":\"artist=:v1\",\"ExpressionAttributeValues\":{\":v1\":{\"S\":\"$util.urlDecode($input.params('artist'))\"}}}"
        IntegrationResponses:
          - StatusCode: '200'
            ResponseTemplates:
              application/json: "#set($inputRoot = $input.path('$'))\n{\n\t\"music\": [\n\t\t#foreach($field in $inputRoot.Items) {\n\t\t\t\"id\": \"$field.id.S\",\n\t\t\t\"artist\": \"$field.artist.S\",\n\t\t\t\"album\": \"$field.album.S\"\n\t\t}#if($foreach.hasNext),#end\n\t\t#end\n\t]\n}"
      MethodResponses:
        - StatusCode: '200'

AWS AppSync

AppSync being a Serverless GraphQL offering, the queries, mutations and subscriptions can use data sources which are DynamoDB, Aroura, Open Search, or HTTP endpoints other than the expected AWS Lambda Functions.

These direct service integrations can leverage Velocity Template Langauge (VTL) or JavaScript resolvers. Additional to the function based resolvers, you can create pipeline resolvers that can not only integrate one but multiple AWS Services.

Where to configure

These direct service configurations would make more sense when you are working with these Services from Infrastructure as Code (IaC) or Infrastructure from Code (IfC) approaches. Like the API Gateway example showcasing a YAML template, you can use AWS SAM where you can define the resources and then the integrations with resolver info.

Another simpler way to integrate services from AWS Step Functions is from the Workflow Studio on AWS Console, where you can define the task along with SDK integration by defining the parameters and results.

This generates a JSON structure for the State Machine which could be imported to your IaC project.

Similar to Workflow Studio, you can design Serverless apps that can generate SAM Template from AWS Application Composer. This currently supports EventBridge integrations with different Services.

Sometimes you may need more than a configuration

Before wrapping up, yes! Sometimes you may need more than a configuration where you need to define your Lambda function or glue codes that process the data from these Services in an efficient way. The above AWS Services support direct integration with different AWS Services, there are some of which like Amazon SNS and Amazon SQS which could use configurations to trigger a Lambda function.

It's time to re:Wind 2022

Jones Zachariah Noel — Fri, 30 Dec 2022 18:35:12 +0000

2️⃣0️⃣2️⃣2️⃣ has been quite an interesting year and a year of learnings for me.

Some of the highlights is what I tweeted about
// Detect dark theme var iframe = document.getElementById('tweet-1607813236266762240-212'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1607813236266762240&theme=dark" }

📜 Authoring blog-posts

This year has been content-ful with this being my 25th blog-post this year. And also have been contributing to -

Most of the blog-posts were focused on AWS Step Functions and some of the sessions that I've delivered over this year.

Numbers from December

This year my blog-post (https://dev.to/zachjonesnoel) crossed
500+ reactions and 100k+ views, cheers to all my readers who have been benefitted from my writings.
// Detect dark theme var iframe = document.getElementById('tweet-1605483967385178112-463'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1605483967385178112&theme=dark" }
One of my blog-post - When to : SNS or SQS contributed to AWS Community Builder org was recognised as one of the top viewed blog-posts.

The growing trend of AI and how ChatGPT constructs the responses for my blog-post, Walter Lee compares one of my blog-post verses ChatGPT and shares about how human authored content would be more relatable and good for skilling up.

Check out the LinkedIn post by Walter Lee.

🎤 Speaking engagements

Breaking back from the practices of the pandemic, going back to in-person events has elevated my learnings in a special way.

Skilling up with latest happenings.
Networking with peers.
Understanding how tech is in action.
Looking into the cool things folks have developed.
Sharing my knowledge

In every in-person event, I've made it a practice to get feedbacks which has helped me to level-up and improvise my content, how I deliver, my pace and more things.

Have delivered sessions at AWS APJ Community Summit, Bangkok (first-ever international in-person session), Freshworks Developer Summit, Bengaluru, AWS Community Day Kochi, AWS Dev Day, Bengaluru, AWS Community Day Pune with a total of 6 in-person sessions.

We all have our first-times and this year it was my first time being part of the Serverless Panel Discussion at AWS APJ Community Day, Bangkok sharing the stage with Farrah Campbell with an amazing moderator Donnie Prakoso along with Raphael Justin Jambalos, Takahiro Horike on the panel where conversation and views was about different development practices, things we love about AWS Serverless, what we love to see in AWS Serverless.

Virtual is the new norm, have been contributing to several AWS User Groups globally (until last year it was in APJ region). A huge shout-out to all the AWS UG Leaders to accommodate and also hosting me virtually - battling the hassles of timezone, streaming setups, internet hiccups and what not! In total sharing my knowledge about Serverless in 10 virtual sessions which also includes Freshworks Community Hours where I had the opportunity to evangelise about some of Freshworks Platform features, AWS Summit India 2022. Guest at the AWS GameDay.

Great to be part of AWS Community Panel at AWS Innovate Modern Apps Edition with the host Derek Bingham on virtual stage along with Ali Haydar, Dipali Kulshrestha, Faizal Khan and Wendy Wong.

🥑 Developer Advocate transition

Being part of the AWS Community and working with Developer Relations team got me to aspire for the responsibilities of the Developer Advocate role. While I interviewed and cracked a couple, I decided to make a move to Freshworks Inc as a Senior Developer Advocate starting from end of May 2022.
Coming from a background of a start-up borne Full-Stack Developer transformed to a Cloud Architect - Serverless, Developer Advocate role was a transformation which I embrace a lot.
Cheers to my fellow DevRels and teammates - Satwik Hebbar, Kaustav Das Modak, Raviraj Subramanian, Saif Ali Shaik who supported me to transform from a solution and architecture focused person to empathised, community focused, helping developers solution on Freshworks Developer Platform and focusing on Developer Experience (DX) for the new features.

🗞️ Sharing via Serverless newsletter

I started the newsletter Everything AWS, Serverless and Architectures ☁️🚀👨‍💻 which is currently powered with Revue. The newsletter is semimonthly where the issues are published on 15th and 30th of every month. The newsletter features some of the commendable content from AWS Community, AWS Serverless announcements, some of the events happening in AWS Serverless community.
// Detect dark theme var iframe = document.getElementById('tweet-1553454520742690816-900'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1553454520742690816&theme=dark" }

With Ruvue shutting down, the newsletter is successfully migrated to Substack and the new link is - https://everythingawsserverless.substack.com/

If you had already subscribed, nothing to worry! But if you hadn't and want to stay on top of Serverless happenings, I would recommend you to subscribe right away!

⭐ AWS Community Builder - Serverless

AWS Community Builder journey began in Q4 of 2021 where I had the opportunity to spread the word of Serverless to folks globally via blog-posts, virtual and in-person sessions at various AWS UG meet-ups and AWS Community Day and also contributed via building samples for different AWS Services.

Honoured with a two quarter Top Contributor in APJ region and once globally!

AWS Community Builder program has not only facilitated me with opportunities but also has helped me learn from peers about things into Serverless to how to improvise on the personal level.

This year had the opportunity to meet folks in the APJ region during AWS APJ Community Summit, Bangkok. And I was nominated for the AWS Community Builder of the year! Which is huge for me, being close to 1 year into the AWS Community Builder program.

// Detect dark theme var iframe = document.getElementById('tweet-1570092172099325954-21'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1570092172099325954&theme=dark" }

🎙️ Kickstarted a podcast - The Zacs' Show - Talking AWS

Through the AWS Community Builder program, I even met Arshad Zackeriya at AWS Community Day ASEAN and we decided to spread the word of DevOps and Serverless with our podcast The Zacs' Show - Talking AWS.

Here is the latest episode where Zack and me re:Capped about re:Invent 2022.
// Detect dark theme var iframe = document.getElementById('tweet-1604363947230265344-648'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1604363947230265344&theme=dark" }

A lot is in plan for the coming year so stay tuned! 🤩

👥 Co-organizing AWS User Group Bengaluru

From May 2022, cheers to the opportunity by Jeevan Dongre to be part of the AWS User Group Bengaluru as a co-organizer. While we started getting back to post-pandemic normal, in-person meet-ups have been a challenge and it's with Jeevan and Chethan Ramegowda, we were able to kick start in-person meet-ups in Bengaluru, India with a successful 4 meet-ups! 🎉

We had a collaborative meet-up with cloud - AWS, Azure and GCP along with Kubernetes and Docker communities which has got amazing response.

We will gear up and have more meet-ups in 2023. 🚀

Tech enthusiasts from Bengaluru have always been receptive and an amazing when it comes to tech meetups. Cheers to everyone actively participating. 🙌

🦸‍♂️ AWS Serverless Hero

In Nov 2022, honoured to be recognized as the AWS Serverless Hero along with AWSome community members!
// Detect dark theme var iframe = document.getElementById('tweet-1592650265739812865-530'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1592650265739812865&theme=dark" }
Being an AWS Community Builder and graduating into AWS Serverless Hero is one of my most pride takes from this year. It's been over a month of being a AWS Serverless Hero, I'm on a journey continuing Serverless Advocacy.

More details in Heroes profile.

That's my 2️⃣0️⃣2️⃣2️⃣! Thanks to everyone who have been part of it making it more memorable and wonderful for me. 🎉🤘 Have met some super AWSome folks this year. Hope to meet y'all again in 2023 and also the folks whom I've missed to meet.

Have a great time! Happy New year 2️⃣0️⃣2️⃣3️⃣ 🎉🎉🎉

Some tips for a cheerful 2️⃣0️⃣2️⃣3️⃣
⚡ Be kind to each other.
⚡ Encourage folks to be a better version of themselves.
⚡ Share your knowledge.
⚡ Focus on mental and physical health.
⚡ Skill-up.

Amazon Inspector can now scan AWS Lambda Functions

Jones Zachariah Noel — Wed, 30 Nov 2022 12:21:10 +0000

Amazon Inspector, a service focused on automated vulnerability scanner that continuously scans AWS workloads for vulnerabilities is now supporting scanning for AWS Lambda functions.

Amazon Inspector supports scanning of AWS Lambda functions and Lambda layers with Java, NodeJS and Python runtimes.

Need for vulnerability checks

Often times, we have code which depends on many packages from installed via different package managers which are prone to security leaks. Although, updating to new version could resolve it, you might have dependencies which are still prone to vulnerabilities. The best way to address is a regular scanning of your codebase to ensure there aren't serious issues.

Serverless specific, until now we had to depend on a third party tool to scan but now it's possible with Amazon Inspector

Enabling Inspector

First off, you would have to enable Inspector for your AWS Account.

Your first scan

Once enabled, you will need a few minutes for Amazon Inspector to scan across your resources across Amazon EC2 instances, Amazon ECR images and now AWS Lambda functions and Lambda layers.

After Amazon Inspector has scanned you can view the report on Inspector dashboard.

[Fun Fact] As you can see, I don't have a single EC2 instance running on this AWS Account.

Scanned findings

Inspector found that 9 of my Lambda functions had a vulnerabilities with critical, high and medium levels.

If you click on one of the functions, you can find the summary for vulnerabilities in that specific AWS Lambda function or the vulnerability because of using an AWS Lambda layer.

Let's dive into the finding

One of the vulnerability is with Axios NPM package.

This also gives details about axios package and the affected with fixed version.

Inspector provides you the complete details of the vulnerability along with the link to National Vulnerability Database (NVD) report.

Along the details, you can also find how to fix it with the available remedy.

In this case, it's updating axios version.

Another way to understand the severity of the vulnerability, the score from National Vulnerability Database (NVD) and Inspector is available.

Pricing

Amazon Inspector is available as part of free trial for 15 days.
For Lambda scans alone, there is monthly based on average number of Lambda functions scanned per month and price is prorated based on total Inspector coverage hours for the month.

More details on Amazon Inspector Pricing.

Action time!

Now it's time to scan your Lambda functions and layers with Amazon Inspector.

Why AWS Step Functions and SDK integrations

Jones Zachariah Noel — Sun, 23 Oct 2022 17:49:06 +0000

AWS Step Functions helps you orchestrate your Serverless workflows and AWS Step Functions is expanding the way you integrate with multiple AWS Services with SDK integrations.

In this blog, we will look at how AWS Step functions and SDK integrations can help you architect better your Serverless applications.

Why AWS Step Functions?

This is the most common question I hear!

Support of flow components

AWS Step Functions allows you to define your workflows with different components -

Task - Single unit of work which can integrate with different AWS Services
Choice - Conditional branching of flows
Parallel - When you have to simultaneously have to execute different tasks
Wait - Wait until x seconds
Fail - Stop the execution with a failure
Succeed - Stop the execution successfully
Pass - For pass through to the next state
Map - When working with loops

Integrates with different AWS Services

AWS Step Functions integrates with over 200+ AWS Services API Actions enabling you to build workflows which can in reality communicate with multiple combination of AWS Services either with SDK integration or with other Serverless services with HTTP optimised integration.

Workflow definitions

The workflows (state machines) are well defined in a JSON format called Amazon States Language (ASL). ASL define the workflow using different components and the possible intrinsic functions.

{
    "Comment": "State machine to recognize celebrities and write into DynamoDB",
    "StartAt": "RecognizeCelebrities",
    "States": {
      "RecognizeCelebrities": {
        "Type": "Task",
        "Parameters": {
          "Image": {
            "S3Object": {
              "Bucket.$": "$.detail.bucket.name",
              "Name.$": "$.detail.object.key"
            }
          }
        },
        "Resource": "arn:aws:states:::aws-sdk:rekognition:recognizeCelebrities",
        "Next": "ProcessEachCeleb",
        "ResultPath": "$.response.celebrities"
      },
      "ProcessEachCeleb": {
        "Type": "Map",
        "Iterator": {
          "StartAt": "DynamoDB PutItem",
          "States": {
            "DynamoDB PutItem": {
              "Type": "Task",
              "Resource": "arn:aws:states:::aws-sdk:dynamodb:putItem",
              "Parameters": {
                "TableName": "${DDBTable}",
                "Item": {
                  "pk": {
                    "S.$": "States.UUID()"
                  },
                  "sk": {
                    "S.$": "$.DocumentName"
                  },
                  "CelebrityName": {
                    "S.$": "$.CelebJSON.Name"
                  },
                  "MatchConfidence": {
                    "N.$": "States.Format('{}',$.CelebJSON.MatchConfidence)"
                  },
                  "Urls": {
                    "S.$": "States.ArrayGetItem($.CelebJSON.Urls,0)"
                  }
                }
              },
              "End": true
            }
          }
        },
        "ItemsPath": "$.response.celebrities.CelebrityFaces",
        "Parameters": {
          "CelebIndex.$": "$$.Map.Item.Index",
          "CelebJSON.$": "$$.Map.Item.Value",
          "DocumentName.$": "$.detail.object.key"
        },
        "ResultPath": "$.response.items",
        "End": true
      }
    }
  }

Serverless orchestration of workflows

When you want to build a workflow which has series of tasks that uses different components with the Amazon States Language (ASL) defining the state machine with different integrations to several AWS services.

Workflow Studio

AWS Step Functions provides Workflow Studio which is a low-code visual workflow designer. This is available in your AWS Console where you can create Standard or Express workflows with different combinations of tasks. With Workflow Studio, you can auto-generate the ASL as a JSON file which can be exported for your developing with different IaC practices.

API actions with sync and async

When integrating with different AWS Services, some of the services' API actions expects you to just start the execution or await for response to be returned, in such scenarios, AWS Step Functions supports both the ways of invocations as part of the API actions integrations.

Intrinsic functions

Intrinsic functions are functions available in Amazon States Language (ASL) which are focused on making integrations with different Tasks easier with pre-processing and post-processing the data.

Here is another blog-post which talks about how Intrinsic functions are helpful.

Intrinsic functions to level-up your Step Functions

Jones Zachariah Noel for AWS Community ASEAN ・ Sep 4 '22

#aws #serverless #stepfunctions #functions

Pricing model for Step Functions

The pricing model for AWS Step Functions is based on each state machine execution which includes state transitions for Standard or Express workflows.

To summarise

Service integration patterns

When integrating with different AWS Services, we would have to integrate with one of the patterns -

Request / Response
Run a job (sync)
Callback

Request / Response

AWS Services API action which process the request and waits to return the response from the HTTP request.

In the above example, we are using DynamoDB's Query API action with SDK integration, the state machine will expect the response from Query API action.

Run a job (sync)

When working with batch tasks or synchronous tasks you would have to wait for a longer period of time until this is completed. In such scenarios, you could choose to wait for the task to complete which will pause the state machine execution until the task is completed. Once it is complete, the state machine execution resumes.

The resource for sync based integrations are suffixed with .sync, for example when running an ECS task -

"Resource": "arn:aws:states:::aws-sdk:ecs:runTask.sync",

Callback

Callbacks work with a task token that has to be returned, until that task token is returned, state machine execution is paused. Whenever working with callbacks, the resource is suffixed with .waitForTaskToken.

In the above example, the state machine defines that AWS Lambda functions is invoked with a callback integration pattern and it expects a task token returned from Lambda function to continue with the state machine execution.

SDK Integrations

AWS Step Functions announced the support of SDK integrations with AWS Services' API actions last year with over 200+ services and it's been growing the list of service API actions supported.

Single source of workflow

With Serverless architecture, you would be working with multiple Serverless services these would traditionally distributed over multiple Lambda functions. With AWS Step Functions, you can have the complete workflow in a single Amazon States Language (ASL).

Direct service integrations

SDK integrations enable you to directly integrate with different AWS Services with the supported API actions. This helps developers to work with direct service integration with the API action's payload of both request and response.

Error handling

AWS Step Functions provides a good way to handle errors with retry-catch definitions on your tast state where you can anticipate the errors would come in.

"Lambda Invoke": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:lambda:invoke.waitForTaskToken",
      "OutputPath": "$.Payload",
      "Parameters": {
        "Payload.$": "$"
      },
      "Retry": [
        {
          "ErrorEquals": [
            "Lambda.ServiceException",
            "Lambda.AWSLambdaException",
            "Lambda.SdkClientException"
          ],
          "IntervalSeconds": 2,
          "MaxAttempts": 6,
          "BackoffRate": 2
        }
      ],
      "Next": "ECS RunTask",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ResultPathMatchFailure",
            "States.Timeout",
            "States.BranchFailed"
          ],
          "Next": "Lambda Invoke"
        }
      ]
    },

Lambda-less

AWS Step functions being a low-code Serverless workflow orchestrator, you can define multiple AWS Services direct integrations which can reduce the usage of Lambda functions for working with several AWS Services.

Cost effective

With the reduction of Lambda functions in your architecture as Step Function tasks are directly integrated with the AWS Service using SDK based API actions, the cost of running your Serverless workflow would reduce. Given that based on the use-case you could even choose between Standard or Express workflows which helps in cost optimisation.

AWS Step Functions and SDK integrations in action

When you have a workflow which needs integration with AWS Rekognition, Amazon DynamoDB and the additional business logic on AWS Lambda functions, the architecture of using them in your Serverless application would be with AWS Lambda functions as seen in the below diagram.

When converting to an architecture using AWS Step Functions would mean that you can leverage the workflow based sequential flow. Again you would be using Lambda functions with the Lambda functions would in-turn invoke the respect AWS Service API action with SDKs.

To step-up with the usage of SDK integrations on Step Functions and intrinsic functions, you can eliminate Lambda functions from your architecture and maintain your Serverless workflow completely on Step Functions.

When the workflow is executed, you can view the complete results on AWS Console which is available for both Standard and now available for Express workflows also.

This is based on the session presented at AWS APAC Community Summit 2022, you can also view the slide deck.

The GitHub repository with SAM template is available for the above example.

zachjonesnoel / celebgram

A fun application to recognize celebrities in an image using AWS Step Functions, Amazon EventBridge combining the patterns of orchestration and choreography.

Celebgram

This is for demonstrating AWS Step Functions with SDK integrations!

In this demo, the SAM Template shows how the State Machines could use SDK integrations with Amazon Rekognition and Amazon DynamoDB to create Serverless orchestration of Recognizing a celebrity from an image uploaded to S3.

You can read more about it in my blog-post - https://dev.to/aws-builders/why-aws-step-functions-and-sdk-integrations-4eeh

This was presented at AWS APAC Community Summit '22, Bangkok. You can view the slide-deck.

How to try it?

Clone the project

With AWS SAM CLI pre-installed, build the SAM app with

sam build

Deploy to your AWS Account with

sam deploy --guided

Once you have tried it out, don't forget to delete with

sam delete

View on GitHub

This series holds a lot of other Serverless workflows powered with Step Functions and SDK Integrations - https://dev.to/zachjonesnoel/series/16484

Intrinsic functions to level-up your Step Functions

Jones Zachariah Noel — Sun, 04 Sep 2022 10:20:41 +0000

AWS Step Functions enables you to orchestrate serverless workflows by integrating with different AWS services. Those AWS services would need inputs in a specific format and also produces output in a specific format and to do that we have mapping templates / resolvers.

Intrinsic functions

When working with different resolvers on Amazon States Language (ASL), you can have in-built methods called intrinsic functions. These intrinsic functions help with several operations in your mapping templates where you can process and manipulate with arrays, JSON objects, strings, math operations and more.

Previously, there were 4 intrinsic functions -

States.Array
States.Format
States.JsonToString
States.stringToJson

Just a couple of days back, AWS Step Functions added 14 new intrinsic functions, you can read the announcement here.

Type	Intrinsic function
Array	`States.ArrayPartition`, `States.ArrayContains`, `States.ArrayRange`, `States.ArrayGetItem`, `States.ArrayUnique`
Data encoding and decoding	`States.Base64Encode`, `States.Base64Decode`
Hash calculation	`States.Hash`
JSON	`States.JsonMerge`
Math	`States.MathRandom`, `States.MathAdd`
String	`States.StringSplit`
UID generator	`States.UUID`

Now we have 18 intrinsic functions.

What it looked like without intrinsic functions

Without the intrinsic functions, the need for any such data processing or manipulation required you to write code in your AWS Lambda functions which involved having a dedicated Task in the State Machine where it would invoke your Lambda function.
And your architectures would have excessive resources, your workflows mostly included AWS Step Functions which is invoking AWS Lambda functions for all data manipulations.

When SDK integrations was announced, we started thinking about workflows that could easily integrate with other AWS services. Many of us thought of migrating our workflows in AWS Lambda to AWS Step Functions but there were a few challenges -

We could use it only for direct SDK integrations without data processing and we could not eliminate Lambda functions completely.
From the sustainability angle, we still had our Lambda code which was executing whenever our State Machine executes.
The State Machines had additional Tasks, which affected the pricing as it's with every transition of state.

First set of intrinsic functions

Intrinsic functions helped us reduce some of the basic parsing use-cases executed in Lambda functions and were limited to -

Format the message with variables.
Parsing String to JSON and vice versa.
Working with arrays either creating or retrieving the array.

What's possible now with intrinsic functions

With the 14 new intrinsic functions introduced, we have use-cases which are now possible within Step Functions without having additional Tasks. Some of the use-cases possible -

Generating UUIDs when you are creating new records in your DynamoDB or messages which are posted to SQS queues or SNS topics.
Able to hash string with different hashing algorithms - MD5, SHA-256 and more. Or even encoding and decoding string to Base64
Working with different array based manipulations, where you may have to get a specific item or a unique item in the array or partitioning your arrays.
Easier way to split string into an array.
Generating random numbers.

But when using intrinsic functions, you would have to consider the reserved characters which requires you to escape the characters with a backslash (\). And the fields which support them which gives you a better understanding of which state what can be performed.