Come costruire un'architettura Serverless nel Cloud AWS

Come costruire un’architettura
serverless nel cloud AWS

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark
Agenda Speakers
Luca Biachi
CTO at Neosperience & AWS Serverless Hero
Alex Casalboni
Developer Advocate (acasal@amazon.com)
Marek Kuczynski
Serverless Specialist Solutions Architect (marekku@amazon.com)
Diego Natali - Solutions Architect (dnnatali@amazon.com)
Chiara Brandle - Solutions Architect (cbrandl@amazon.com)
Alfredo Velasco - GTMS Serverless (alfrevel@amazon.com)
Luca Spagnoli - Solutions Architect (lucspa@amazon.com)
Margherita Bonetto - Solutions Architect (bonetto@amazon.com)
Fabio Chiodini - Solutions Architect (chiodf@amazon.com)
Time Topic
09h00 - 9h30 Introduction – Serverless on AWS
09h30 - 10h15
Serverless Services: Amazon API Gateway, AWS
Lambda, Step Functions
10h15 - 10h30 Break
10h30 - 11h30 Lab I: Serverless Web Application
11h30 - 12h15 Serverless Services: AWS SAM, CI/CD
12h15 - 12h25 Break
12h25 - 13h00 Lab II : CI/CD for Serverless Applications
13h00 Q&A, Wrap-up
Chatters

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential
AWS Europe (Milan) Region
Dal 28 Aprile AWS ha esteso la propria presenza globale con l’apertura della nuova Regione AWS in Italia.
La nuova Regione AWS Europe (Milano) offre tecnologie cloud avanzate che abilitano opportunità di innovazione,
imprenditorialità e trasformazione digitale. Per ulteriori informazioni sulle componenti e sulle caratteristiche di una
Regione AWS, potete visitare il sito aws.amazon.com/local/italy/milan/

1
Intro to Serverless

www.neosperience.com | blog.neosperience.com | info@neosperience.com
Neosperience
Empathy in Technology
Building a SaaS Serverless Cloud on AWS
September, 18th 2020

Luca Bianchi
Who am I?
github.com/aletheia
https://it.linkedin.com/in/lucabianchipavia
https://speakerdeck.com/aletheia
Chief Technology Ofﬁcer @ Neosperience
Chief Technology Ofﬁcer @ WizKey
Serverless Meetup and ServerlessDays Italy co-organizer
www.bianchiluca.com
@bianchiluca

Best in class customers
Consumer Products, Retail & Distribution, Communications & Media
Financial Services, Travel & Transportation, GovernmentAutomotive, Health, Industry & Services
Fashion, Luxury & Beauty

Neosperience IPO (Feb 20th, 2019)

what makes every customer unique,

them in 1:1 experiences

and your customer base.
Neosperience Cloud
Understand
Engage
Grow

How delivers digital experience innovation
Increase customer engagement

• Tailor storytelling and call-to-action

• Grow the value of the customer

• Suggest the most suitable products
and services

• Accelerate on-boarding and increase
conversions

• Generate recurring revenues, evolving
loyalty into membership

• Send personalized notifications

• Delight the customer with gamification

• Make digital experiences come alive in
extended reality

• Nudge advocacy
01

Listen to customers 
across channels
02

Deliver relevant 
experiences at scale
03

Transform prospects 
into customers for life
Neosperience Cloud allows to create personalized, relevant experiences that strengthen  
the relationship with the customer across touchpoints: web, app, platforms, point of sale
The first digital experience
platform to establish empathic
relationships with customers
that takes into account their
uniqueness.
A set of application modules
condensing multi-disciplinary
skills: data scientists,
designers, software architects,
cognitive, behavioral and social
psychologists, to unleash your
brand’s potential.
Understand
Engage
Grow
Neosperience Cloud

Neosperience Cloud
Cloud
Understand
Engage
Grow

Any complex platform implements a set of different requirements
Different requirements
• Deep Learning models
• Integrating with 3rd party products
• Different data types to persist
• Need for speed and scalability
• Team communication has a lot of friction: IT operation and dev teams

Neosperience Cloud
Cloud
Understand
Engage
Grow
Neosperience Cloud Services
• Deﬁne Cloud Requirements

• One endpoint serves multiple
requests

• It’s called the monolith

Neosperience ( 2008 — 2012 )
The age of the monolith
• Multi-region deploy of SpringMVC / Java on Apache
Tomcat / JBoss

• Shared RDS database managed by Hibernate

• Autoscaling group for EC2 instances, Elastic IP

Pros
✓ Everything within a single package

✓ Simple CI workﬂow

✓ Easy services coordination

Cons
- Lifecycle: one change in code requires a full release of
Neosperience

- Scalability / Costs: planning autoscale for diﬀerent
usages is not easy

- Everything is a REST endpoint

Neosperience Cloud
Cloud
Understand
Engage
Grow
image video conversation relation interaction behavior
Personalised
Content
Proximity
Marketing
Nudging &
Gamiﬁcation
Image
Personalised
Commerce
Personalised
Advertising
Customer Base Channels
• Start separating concerns

• Every component has the
same technological stack

• Deﬁne interfaces between
components

• It’s called microservices

image
video
conversation
relation
interaction
behavior
Personalised Content
Proximity Marketing
Nudging & Gamiﬁcation
Image
Personalised
Commerce
Personalised
Advertising
CustomerBaseChannels
Customer  
Generations
Search
Customer
CI / CD

Neosperience ( 2012 — 2015 )
Separation of concerns
• Spring Boot/Cloud on Java Stack

• Docker image for each service within NGINX

• DynamoDB used as façade towards clients

• RDS managed through Spring Data

• Coordination service (Module Manager)

Pros
✓ Smaller services, same technology for everything

✓ Immutable deployments: from CI to Docker registry

✓ Easy services coordination

Cons
- Still paying for idle (database, instances)

- Manual provisioning of resources (through Beanstalk)

- Everything is a REST endpoint

Serverless means no servers.
No hardware to provision or manage
No IT service team installing hardware
But still it’s someone else server
Server
VM
OS
frameworks
code
your duty

Serverless means no VMs.
No under or over provisioning
Never pay for idle
No VM disaster recovery
VM
OS
frameworks
code
your duty

no patch to install.no OS to conﬁg.Serverless means

Serverless means no OS to conﬁg.
OS is provisioned automatically
Patches are installed by vendor
Built-in best practices OS
frameworks
code
your duty

Serverless means no schedulers.

Serverless means no schedulers.
Code is invoked by platform
Language support is packed within runtime
Analytics are provided out of the box
frameworks
code
your duty

Serverless means Servicefull.
Patrick Debois - 2016
Server
VM
OS
frameworks
code
your duty

Serverless means Servicefull.
Patrick Debois - 2016
Server
VM
OS
frameworks
code
your duty
some one else duty

image
video
conversation
relation
interaction
behavior
Personalised Content
Proximity Marketing
Nudging & Gamiﬁcation
Image
Personalised
Commerce
Personalised
Advertising
CustomerBaseChannels
Customer  
Generations
Search
Customer
CI / CD
• Move to cloud native adoption

• Script cloud resources

• Each service has its own persistence

• Migrate data models
Neosperience
Cloud

Neosperience ( 2015 — now )
Here comes Serverless
• Triggers to Lambda functions

• Each service defines its own persistence

• Communication is handled through Kinesis

• Immutable deployments

Pros
✓ Many small packages

✓ Extremely fast release cycles (smaller changes)

✓ No servers to manage (woot-woot)

✓ Scalability at its best / Cost reduction

✓ There is no difference between dev/stage/
production

Cons
- Required a shift in team perspective towards
software development (there is no one size fits
all architecture)

- Expensive when utilization close to 100%

- No support for dedicated hardware

Some key points we had to address while moving to Serverless and microservices.
The questions we faced
How micro is a microservice?
Decompose your system into domain speciﬁc computing units using Domain Driven Development (DDD)
Do we want to reinvent the wheel?
AWS provides a variety of managed services that can ease out software development, reducing time to market of orders of
magnitude. Every time we had to implement a new functionality we asked ourselves whether there was an AWS service for
that.
How to deal with the outside world?
Neosperience is a B2B2C ISV vendor. Our product can be used SaaS by companies or integrated through API. We need to
rely on web standards REST and OAuth2
How about vendor lock-in?
Serverless does not lock you in. Data does. But it’s the same with languages, tools or frameworks.

Business Domain Support
✓17 diﬀerent business domains

✓5-10 microservices each domain

✓a dozen of support services (monitoring, maintenance,
OAuth2, Organization, multi-tenancy, etc.)

Serverless
✓100% Serverless except for ML model training

Lambda Functions
✓200+ functions

AWS Resources
✓400+ AWS resources

✓managed through a 15+ CloudFormation stacks
Adopting microservices can really make our life as ISV better, with a number of beneﬁts
Neosperience is a 100% Serverless cloud solution
Time to market
✓improved from months to weeks

✓business features released every sprint

✓technical features released multiple times a week

Costs
✓reduced by an order of magnitude

Team
✓developers provision cloud resources

✓innovation in encouraged, failure impact is bounded

✓shifted from running after business requirements to
waiting for business requirements

Happiness
! Dev Team has full control on delivery

! Business Team has feature delivery

“in the past were bigger companies that
outcompeted smaller companies
now are faster companies
to outcompete slower companies”
— Marc Benioff

http://bit.ly/nsp-serverless-2020
github.com/aletheia
@bianchiluca
https://it.linkedin.com/in/lucabianchipavia
https://speakerdeck.com/aletheia

www.neosperience.com | blog.neosperience.com | info@neosperience.com

AWS Step
Functions
AWS
Lambda
Amazon
EventBridge
Amazon
API Gateway
Amazon
SNS
Main Serverless Services
Amazon
SQS

2
Amazon API
Gateway

Building and managing APIs can be challenging
Managing multiple versions and stages of
an API is difficult
Building monitoring solutions that give you
visibility into the health of your APIs is
resource intensive
Access authorization is a challenge
Traffic spikes pose an operational burden
Many people ask: What if I don’t want
servers at all?

Amazon API Gateway
API Gateway is a fully managed service that makes it easy for developers to
create, publish, maintain, monitor, and secure APIs at any scale. It frees you
from the operational burden of implementation, offers reliable network
protection, and centralizes authorization decisions within policies so bugs
and code concerns are minimized.
It also enables you to:
• Host multiple versions and stages of your APIs
• Create and distribute API Keys to developers
• Throttle and monitor requests to protect your backend
• Leverage signature version 4 to authorize access to APIs
• Perform Request / Response data transformation and API mocking
• Reduce latency and DDoS protection through CloudFront
• Store API responses through managed caches
• Generate SDKs for Java, JavaScript, Java for Android, Objective-C or
Swift for iOS, and Ruby

Amazon API Gateway Benefits
1
54
2 3
6
Fully managed,
automatic scaling,
pay for value
Supports multiple
protocols, including
RESTful and WebSocket
APIs
Native connectivity to
HTTP endpoints and
other AWS services like
Lambda
Offers industry standard
security solutions and
customizable options for
security needs
Privacy enabled: Create
APIs that are only
accessible from your
VPC
Swagger support and
support for canary
deployments

Types of APIs: Supported Protocol Details
RESTful: HTTP APIs & REST APIs WebSocket APIs
Client Client
• Request / Response
• HTTP Methods like GET, POST, etc
• Short-lived communication
• Stateless
• Serverless WebSocket
• 2 way communication channel
• Long-lived communication
• Stateful

Types of APIs
Edge-Optimized (Available with REST APIs)
• Uses CloudFront to reduce TLS
connection overhead (reduces roundtrip
time)
• Designed for a globally distributed
clients
Regional (Available with all types)
• Recommended API type for
general use cases
• Designed for building APIs for
clients in the same region
Private (Available with REST APIs)
• Only accessible from within VPC
(and networks connected to VPC)
• Designed for building APIs used
internally or by private
microservices
RESTful APIs
HTTP APIs are the cheapest, fastest, best choice for
building APIs that only require API proxy functionality.
For APIs that require API proxy functionality and
management features in a single solution, API Gateway
also offers REST APIs.
WebSocket APIs
WebSocket APIs allow you to build real-time two-way
communication applications, such as chat apps and
streaming dashboards. API Gateway maintains a
persistent connection to handle message transfer
between a backend service and its clients.

RESTful API options: HTTP APIs vs REST APIs
HTTP APIs are the best choice for building APIs for a majority of workloads—they offer up to 71% cost savings and
60% latency reduction compared to REST APIs. HTTP APIs are optimized for serverless workloads and HTTP backends,
and should be considered first for APIs that only require API proxy functionality. If your APIs require API proxy
functionality and API management features in a single solution, API Gateway also offers REST APIs. For a complete
side-by-side comparison, visit our documentation.

API Architecture
Websites
Services
Amazon API Gateway
API Gateway Cache
(REST only)
Public
Endpoints on
Amazon EC2
Amazon
CloudWatch
Monitoring
All publicly accessible
endpoints
Lambda
Functions
Endpoints
in VPC
Applications
& Services
in VPC
Any other AWS
service
Fully-managed
CloudFront
Distribution
Edge-OptimizedRegionalPrivate
Applications
& Services
in the same
AWS Region AWS Direct
Connect
On-premises
HTTPS
Mobile client
Customer-managed
CloudFront Distribution

API Gateway Features
Getting the most out of your APIs

Request & Response in API Gateway
• Customize various error responses
Change HTTP status code
Modify body content
Add headers
• Customize specific responses
• Modify default 4XX/5XX
API Gateway enables elegant
error handling.
You can customize what your
backend returns to create
branded 404 responses.

Request & Response
Websites
Method Request
• Modeling
• Validation
• Transformation
Integration Request
Amazon
DynamoDB
AWS
Lambda
Amazon
S3
Integration Response
Amazon
DynamoDB
AWS
Lambda
Amazon
S3
Method Response
• Transformation
• Custom Errors
Request
Response
Other AWS & On
Premise Services
Other AWS & On
Premise Services

Throttling in API Gateway
• API Key level throttling
Configurable in usage plan
• Method level throttling
Configurable in stage settings
• Account level throttling
Limits can be increased
API Gateway offers three
levels of throttling for APIs.

Throttling
Websites
Service
Public
Endpoints on
Amazon EC2
Authorized Mobile
client
Lambda
Functions
Any other AWS
service
All publicly accessible
endpoints
Mobile client
Partner
Websites
User’s Usage Plan
Services Usage Plan
Partner Usage Plan
Per
client
Per client
&
per method
Per
method
Per
account
(REST only) (REST only)

Private Integrations in API Gateway
• Run inside your VPC
Change HTTP status code
Modify body content
Add headers
• HTTP APIs offer private integrations for
AWS ALB, AWS NLB, and AWS Cloud
Map
Easily integrate with AWS ALB & NLB
Easily integrate with AWS Cloud Map
• REST APIs & WebSocket APIs offer
private integrations with AWS NLB
Private integrations allow
you to route traffic to your
VPC.

VPC Links (Private Integrations)
Endpoints
in VPC
AWS Direct
Connect
On-premises
Network Load
Balancer (NLB)
API Gateway
VPC
Link
Client
Service
Authorized Mobile
client
Application Load
Balancer (ALB)
AWS Cloud Map

Staging in API Gateway
• APIs are deployed to staging
environments.
You choose what to name them.
• For example, these environments:
Dev (e.g., example.com/dev)
Beta (e.g., example.com/beta)
Prod (e.g., example.com/prod)
API Gateway enables you to
set stage variables, allowing
the same API to point to
different backends.
Your APIs are versioned and
can be rolled back.

Staging
v0.0.1
v0.0.2
v0.0.3
v0.0.4
v0.0.5
v0.0.6
v0.0.7
v0.0.8
v0.0.9
prod
beta
dev
aliases
Prod stage
lambdaAlias = prod
Dev stage
lambdaAlias = dev
Beta stage
lambdaAlias = beta
Stages
Stage variable = lambdaAlias
API Gateway Lambda function

Custom Domains in API Gateway
• Run your APIs within your own DNS
zone
• Recommended for supporting multiple
versions
api.tampr.com/v1 -> restapi1
api.tampr.com/v2 -> restapi2
• Support for cross-region redundancy
with regional API endpoints
API Gateway enables you to
create custom domains for
your APIs. It also enables you
to point to custom domains
from multiple API types.

Custom Domains
https://12345.execute-api.us-east-1.amazonaws.com/prod
https://mydomain.com/api-one
• Supports HTTP, REST,
and WebSocket APIs
• SSL Certs managed
through ACM
• Supports multiple
domains through base
path mapping

3
AWS Lambda

AWS Lambda
• Run code without provisioning or managing
servers
• Pay only for the compute time you consume
• Virtually any type of application or backend service
• Zero administration
• Trigger from other AWS services or call it directly
from any web or mobile app

Serverless applications
Event source Services
Changes in
data state
Requests to
endpoints
Changes in
resource state
Function
Node.js
Python
Java
C#
Go
Ruby
Runtime API

Anatomy of a Lambda function
Handler() function
Function to be executed
upon invocation
Event object
Data sent during Lambda
function Invocation
Context object
Methods available to
interact with runtime
information (request ID,
log group, more)
import json
def lambda_handler(event, context):
# TODO implement
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}

Lambda execution model
Synchronous
(push)
Asynchronous
(event)
Stream
(Poll-based)
/order
Amazon API
Gateway
Lambda
function
Amazon
DynamoDB
Amazon
Kinesis
changes
AWS Lambda
service
function
Amazon
SNS
Amazon
S3
reqs
Lambda
function
Amazon
SQS + FIFO
NEW!!!

Designate an asynchronous target for Lambda function invocation results. You
can set one destination for a success, and another for a failure.
AWS Lambda Destinations

• For Lambda functions consuming events from Kinesis or DynamoDB
Streams, it’s now possible to limit the retry count, limit the age of records
being retried, configure a failure destination, or split a batch to isolate a
problem record. These capabilities will help you deal with potential
“poison pill” records that would previously cause streams to pause in
processing.
• For asynchronous Lambda invocations, you can now set the maximum
event age and retry attempts on the event. If either configured condition
is met, the event can be routed to a dead letter queue (DLQ), Lambda
destination, or it can be discarded.
Lambda Streams and Async-based invocations

• Batch Window: batch records up to 300s before invoke Lambda
• Concurrent batches per shard – Process multiple batches from the
same shard concurrently.
Lambda advanced scaling controls

The function lifecycle
Bootstrap
the runtime
Start your
code
Full
cold start
Partial
cold start
Warm
start
Download
your code
Start new
Execution
environment
AWS optimization Your optimization

Provisioned Concurrency keeps functions initialized and hyper-ready to
respond in double-digit milliseconds. Customers fully control when or
how long to enable Provisioned Concurrency.
Ideal for latency-sensitive
applications
You fully control
when to enable it
No changes required
to your code
Fully serverless
Provisioned Concurrency for AWS Lambda

• Applications that have strict latency
SLAs
• Have direct interaction with end-users
• Have strict regulatory requirements
• Leverage languages that have a slower
cold start time or require large
deployment packages
• Applications that support high-
velocity traffic bursts
• Serve content such as ads during a live
stream
• Mobile applications such as games
• Marketing blitzes or flash sales
Provisioned Concurrency for AWS Lambda

• Integrate VPC resources in serverless
apps
• Use new services with Lambda
functions (e.g. ElastiCache)
VPC to VPC NAT

Security Model
Execution RoleLambda Function
+ =
Allowed
Actions
IAM Role with:
• IAM Policy Permissions
+
Lambda Trigger
Function Policy:
• Service or event source
to call Lambda

Versioning Not Enabled
Version $LATEST
arn:aws:lambda:[region]:[acct-id]:function:[name]:$LATEST

Versioning Enabled
Version $LATEST
arn:aws:lambda:[region]:[acct-id]:function:[name]:3
3
2
1

Aliases with Versioning Enabled
Version $LATEST
arn:aws:lambda:[region]:[acct-id]:function:[name]:PROD
3
2

Amazon SQS FIFO as an event source

Amazon Elastic File System (EFS) for Lambda
• Share data across 1000s of
function invocations
• Achieve high performance,
highly available, durable
storage with persistent volumes
• Pay only for what you use
Availability zone Availability zone
EFS Mount
Target
EFS
Mount
Target
Amazon EFS
file system
AWS
Lambda

New Workloads on AWS Lambda
Large File
Data manipulation
Large Scale
Media Processing
AI/ML
Analytics
Realtime
applications
High Res Images
HD Videos
Zip/Archives
Git
MXNet
TensorFlow
Content Management
Web apps
Simplify Application Architecture
Process files of any size
Reduce Costs

RDS Proxy
Amazon RDS
RDS Proxy
AWS Secrets Manager AWS IAM
Connection
Pool
SQL / TLS
AWS Lambda Functions

Fully managed, highly available database proxy feature for Amazon
RDS. Pools and shares DB connections to make applications more
scalable, more resilient to database failures, and more secure.
Pool and share DB
connections for
improved app scaling
Increase app
availability and reduce
DB failover times
Manage app data
security with DB
access controls
Fully managed DB
proxy, compatible
with your database
Amazon RDS Proxy

Lambda Layers
Lets functions easily share code: Upload layer
once, reference within any function
Promote separation of responsibilities, lets
developers iterate faster on writing business logic
Built in support for secure sharing by ecosystem

Lambda Runtime API
Bring any Linux compatible language runtime
Powered by new Runtime API - Codifies the
runtime calling conventions and integration points
At launch, custom runtimes powering Ruby
support in AWS Lambda, more runtimes from
partners (like Erlang)
Custom runtimes distributed as “layers”
Rule
Stack

4
AWS Step Functions

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
The art of the state: Coordinating services
using AWS Step Functions

In a monolith, everything gets deployed together

With microservices, we split the work
between multiple systems

Microservices can give us increased
agility and scalability

But distributed systems can be harder
to coordinate and debug

Example orchestration
Processing new bank account
applications

A state machine
Describes a collection of computational
steps split into discrete states
Has one starting state and
always one active state (while executing)
The active state receives input,
takes some action, and generates output
Transitions between states are based on
state outputs and rules that we define

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential
AWS Step Functions
Resilient workflow automation
Built-in error handling
Powerful AWS service integration
First-class support for integrating with
your own services
Auditable execution history and visual monitoring
Fully-managed state machines on AWS

AWS Step Functions
The basics

How AWS Step Functions work
The workflows you build with Step Functions are called state
machines, and each step of your workflow is called a state.
When you execute your state machine, each move from one
state to the next is called a state transition.
You can reuse components, easily edit the sequence of steps or
swap out the code called by task states as your needs change.

Amazon States Language
https://states-language.net/spec.html
{
"Comment": "A simple minimal example",
"StartAt": "Hello World",
"States": {
"Hello World": {
"Type": "Task",
"Resource": "arn:aws:lambda...HelloWorld",
"End": true
},
[. . .]
}
}

Example workflow: opening an
account
Wait for a callback
Parallel Steps
Branching Choice
Tasks

Performing a task
Call an AWS Lambda Function
Wait for a polling worker to
perform an activity
Pass parameters to an API of
an integrated AWS Service

Performing a task
Example: Execute a AWS Lambda Function
"Verify Identity Documents": {
"Type": "Task",
"Parameters": {
"name.$": "$.application.name"
"identityDoc.$": "$.application.idDocS3path"
},
"Resource": "arn:aws:lambda...VerifyIdDocs",
"End": true
}

Executing branches
in parallel
Contains an array of state
machines branches to
execute in parallel
Outputs an array of outputs
from each state machine in
its branches

Executing branches
in parallel
Example: Run two branches in parallel
"Perform Automated Checks": {
"Type": "Parallel",
"Branches": [
{
"StartAt": "Verify Identity Documents",
"States": { "Verify Identity Documents": { … } }
},
{
"StartAt": "Check Address",
"States": { "Check Address": { … } }
}
]
},
"ResultPath": "$.checks",
"Next": "Human Review Required?"
}

Making a choice
Like a switch statement in
programming
Inspects an array of choice
expressions, comparing
variables to values
Determines which state to
transition to next

Making a choice
Example: Choose next step based on
state outputs
"Human Review Required?": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.checks[0].flagged",
"BooleanEquals": true,
"Next": "Wait For Review"
},
{
"Variable": "$.checks[1].flagged",
"BooleanEquals": true,
"Next": "Wait For Review"
}
],
"Default": "Approve Application"
}

Waiting for a callback
Generates a Task Token and
passes it to an integrated
service
When the recipient process is
complete, it calls
SendTaskSuccess or
SendTaskFailure with the Task
Token
Workflow then resumes its
execution

Waiting for a callback
Example: Pause and wait for an
external callback
"Type": "Task",
"Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
"Parameters": {
"FunctionName": "FlagApplicationForReview",
"Payload": {
"applicationId.$": "$.application.id",
"taskToken.$": "$$.Task.Token"
}
},
"ResultPath": "$.reviewDecision",
"Next": "ReviewApproved?"

Error handling
Failures can happen due to Timeouts, Failed
Tasks, or Insufficient Permissions
Tasks can Retry when errors occur using a
BackoffRate up to MaxAttempts
Tasks can Catch specific errors and transition to
other states

Working with AWS Step Functions
Visualise in the Console
Define in JSON Monitor Executions

AWS Step Functions
Diving deeper

State types
Task Execute work
Choice Add branching logic
Wait Add a timed delay
Parallel Execute branches in parallel
Map Process each of an input array's items with a state machine
Succeed Signal a successful execution and stop
Fail Signal a failed execution and stop
Pass Pass input to output

AWS Step Functions service integrations
Amazon
Elastic Container Service
AWS
Lambda
AWS
Batch
Amazon
DynamoDB
Amazon
SageMaker
AWS
Glue
AWS
Step Functions
Amazon
Simple Notification Service
Amazon
Simple Queue Service

NEW
AWS Step Functions
Express Workflows

AWS Step Functions Express Workflows
Orchestrate AWS compute, database, and messaging services at rates up to
100,000 events per second, suitable for high-volume event processing workloads
such as IoT data ingestion, microservices orchestration, and streaming data
processing and transformation
NEW

Standard vs. express workflows
Standard Express
Maximum
duration
365 days 5 minutes
Execution
start rate
Over 2,000 per second Over 100,000 per second
State
transition rate
Over 4,000 per second
per account
Nearly unlimited
Execution
semantics
Exactly-once workflow
execution
At-least-once workflow
execution

Standard vs. express workflows (continued)
Standard Express
Executions
Executions are persisted and have
ARNs
Executions are not persisted except
as log data
Execution
history
Stored in Step Functions, with tooling
for visual debugging
in the console
Sent to Amazon CloudWatch Logs
Service
integrations
Supports all service integrations
and activities
Supports all service integrations.
Does not support activities.
Patterns Supports all patterns
Does not support Job-run (.sync) or
Callback (.wait For Callback)

AWS Step Functions key benefits
Fully-managed service
High availability & automatic scaling
Visual monitoring & state management
Auditable execution history
Built-in error handling
Pay per use

15 minutes break and then…
Lab time!
Serverless Web Application

Getting started with the AWS Cloud
Development Kit (CDK)
Marek Kuczynski
Senior Serverless Solutions Architect
Amazon Web Services
@marekq

Level 0: Creating infrastructure by hand
Your organization’s
infrastructure

Level 1: Imperative infrastructure as code
infrastructure
deploy.script
AWS SDK

Level 1: Imperative infrastructure as code
• Lots of boilerplate
• What if something fails
and we need to retry?
• What if two people try to
run the script at once?
• Race conditions?
resource = getResource(xyz)
if (resource == desiredResource) {
return
} else if (!resource) {
createResource(desiredResource)
} else {
updateResource(desiredResource)
}deploy.script

Level 2: Declarative infrastructure as code
infrastructure
infrastructure.txt
AWS CloudFormation
HashiCorp
Terraform
AWS SDK
AWS SAM (Serverless
Application Model)

Level 2: Declarative stack using CloudFormation
template.yml
• Just a list of each resource
to create and its
properties, in this case
YAML format
• Some minor helper
functions may be built in
to aid in fetching values
dynamically
Resources:
# VPC in which containers will be networked.
# It has two public subnets
# We distribute the subnets across the first two available subnets
# for the region, for high availability.
VPC:
Type: AWS::EC2::VPC
Properties:
EnableDnsSupport: true
EnableDnsHostnames: true
CidrBlock: !FindInMap ['SubnetConfig', 'VPC', 'CIDR']
# Two public subnets, where containers can have public IP addresses
PublicSubnetOne:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone:
Fn::Select:
- 0
- Fn::GetAZs: {Ref: 'AWS::Region'}
VpcId: !Ref 'VPC'
CidrBlock: !FindInMap ['SubnetConfig', 'PublicOne', 'CIDR']
MapPublicIpOnLaunch: true
PublicSubnetTwo:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone:
Fn::Select:
- 1
- Fn::GetAZs: {Ref: 'AWS::Region'}
VpcId: !Ref 'VPC'
CidrBlock: !FindInMap ['SubnetConfig', 'PublicTwo', 'CIDR']
MapPublicIpOnLaunch: true

The AWS Serverless Application Model (SAM)
CloudFormation extension optimized for
serverless
New serverless resource types: functions, APIs,
and tables
Supports anything CloudFormation supports
Open specification (Apache 2.0)
https://github.com/awslabs/serverless-application-model

Declarative template in SAM
AWSTemplateFormatVersion: '2010-09-09’
Transform: AWS::Serverless-2016-10-31
Resources:
GetHtmlFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./todo_list_lambda
Handler: index.gethtml
Runtime: nodejs12.x
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetHtml:
Type: Api
Properties:
Path: /{proxy+}
Method: ANY
ListTable:
Type: AWS::Serverless::SimpleTable
Tells CloudFormation this is a SAM
template it needs to “transform”
Creates a Lambda function with the
referenced managed IAM policy,
runtime, code at the referenced zip
location, and handler as defined.
Also creates an API Gateway and
takes care of all
mapping/permissions necessary
Creates a DynamoDB table with 5
Read & Write units

Level 3: AWS Cloud Development Kit (AWS CDK)
infrastructure
app.js
AWS CloudFormation AWS SDKAWS CDK

Level 3: AWS CDK
• Write in a familiar
programming language,
no need to learn a new
language
• Create many underlying
AWS resources at once
with a single construct
• Each stack is made up of
“constructs,” which are
simple classes in the code
• Still declarative, no need
to handle create vs update
cdk_app.js
lambda_function.py

VPC
Public Subnet in
Availability Zone
Public Subnet in
Availability Zone 2
Private Subnet in
Availability Zone
Private Subnet in
Availability Zone 2
Internet
gateway
NAT
gateway
NAT
gateway
One CDK construct expands to many underlying resources
cdk deploy// Network for all the resources
const vpc = new ec2.Vpc(stack, 'MyVpc', { maxAzs: 2 });

One CDK construct expands to many underlying
resources
270 lines of AWS
CloudFormation YAML
I don’t have to write!
cdk synth// Network for all the resources
const vpc = new ec2.Vpc(stack, 'MyVpc', { maxAzs: 2 });

CDK constructs are available in multiple languages

AWS Cloud Development Kit (AWS CDK)
The big picture—from AWS CDK app to provisioned infrastructure
CloudFormation
Template
“compiler”
CDK CLI
“processor”
“assembly
language”
“source”
synthesize deployexecutes

A hello world demo
Let’s create a simple API Gateway and Lambda function using CDK.
Source: https://github.com/marekq/hello-world-cdk

With CDK, you can combine Fargate with Lambda
Source: https://github.com/marekq/sqs-fargate-poller

X-Ray tracing for both Lambda and Fargate

• AWS Amplify Console and CLI
The fastest way to build mobile and web applications
• Serverless Application Model (SAM) CLI
Build serverless apps using a declarative YAML template
• Cloud Development Kit (CDK)
Define cloud resources in your favourite programming language
Three serverless framework options from AWS

NEW! AWS Solutions Constructs for CDK
https://aws.amazon.com/blogs/aws/aws-solutions-constructs-a-library-of-architecture-patterns-for-the-aws-cdk/

AWS Solutions Constructs for CDK

CDK Day conference on 30th September
www.cdkday.com

Thank you!
Marek Kuczynski
Senior Serverless Solutions Architect
Twitter: @marekq
Email: marekku@amazon.nl

Our workshop after the break
• We will build an API using the CDK.
• The full manual and code samples can be found at
https://cdkworkshop.com/
• As requirements, install the following;
• The AWS CDK CLI
• VS Code or any code editor with highlighting
• Choose your favourite programming language (TypeScript, Python, .NET, Java)

Come costruire un'architettura Serverless nel Cloud AWS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Come costruire un'architettura Serverless nel Cloud AWS

Similaire à Come costruire un'architettura Serverless nel Cloud AWS (20)

Plus de Amazon Web Services

Plus de Amazon Web Services (20)

Come costruire un'architettura Serverless nel Cloud AWS