Making sense of AWS Serverless operations AWS Community Day NL 2024-
VadymKazulkin
26 views
62 slides
Oct 12, 2024
Slide 1 of 62
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
About This Presentation
There is a misunderstanding, that everything is possible with the Serverless Services in AWS, for example that your Lambda function may scale without limitations. But each AWS service (not only Serverless) has a big list of quotas that everybody needs to understand and take into account during the d...
There is a misunderstanding, that everything is possible with the Serverless Services in AWS, for example that your Lambda function may scale without limitations. But each AWS service (not only Serverless) has a big list of quotas that everybody needs to understand and take into account during the development.
In this talk I'll explain the most important things to be aware of for the scalability of the AWS Serverless services, explain quotas (from the hyper scalability point of view, but not only) of the services like API Gateway, Lambda, DynamoDB, Aurora Serverless, SQS, S3 and others and how to architect your solution with these quotas and technical concepts of the distributed systems in mind like token bucket algorithm, throughput and burst rate, concurrency, retry with exponential backoff and jitter and others.
I'll also talk about some general architetural decision what services to use in the Serverless applications: DynamoDB or Aurora (Serverless) for the database choice and SQS, SNS, Kinesis or EventBridge in case you use asynchronous communication/event-driven patterns.
Size: 2.64 MB
Language: en
Added: Oct 12, 2024
Slides: 62 pages
Slide Content
FirdawsAboulaye& Vadym Kazulkin ip.labs
Making sense of AWS Serverless operations
Vadym Kazulkin, ip.labs, October 3rd 2024
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Vadym Kazulkin
ip.labs GmbH Bonn, Germany
Co-Organizer of the Java User Group Bonn [email protected]
@VKazulkin
https://dev.to/vkazulkin
https://github.com/Vadym79/
https://de.slideshare.net/VadymKazulkin/
https://www.linkedin.com/in/vadymkazulkin
https://www.iplabs.de/
Contact
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
About ip.labs
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Challenges and lessons learned
Architect with AWS Serverless quotas and technical concepts in mind
General architectural decisions
SQS vs SNS vs Kinesis vs EventBridge
Aurora (Serverless) vs DynamoDB
Challenging Serverless observability
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Challenges and lessons learned
Architect with AWS Serverless quotas and technical concepts in mind
General architectural decisions
SQS vs SNS vs Kinesis vs EventBridge
Aurora (Serverless) vs DynamoDB
Challenging Serverless observability
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
account and current region limits
Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Service Quotas Request History
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://aws.amazon.com/de/blogs/compute/building-well-architected-serverless-applications-controlling-serverless-api-access-part-2/
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
•The throttle ratethen determines how
many requests are allowed per second
•The throttle burstdetermines how many
additional requests are allowed per
second
API Gateway throttling-related settings are
applied in the following order:
•Per-client or per-method throttling limits
that you set for an API stage in a usage
plan
•Per-method throttling limits that you set
for an API stage
•Account-level throttling per Region
•AWS Regional throttling
Token bucket algorithm
API Gateway Token Bucket Algorithm
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Default
throughput /
Throttle rate
The maximum number of requests per
second that your APIs can receive
10.000
Throttle burst rateThe maximum number of additional
requests per second that you can send in
one burst
5.000
API Gateway Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description ValueAdjustableMitigation
Max timeoutThe maximum integration
timeout in milliseconds
29 sec 1) Increase the limit
2) Lambda Function URL
with response streaming
API Payload
size
Maximum payload size for
non WebSocket API
10 MB 1)The client makes an
HTTP GET request to API
Gateway, and the
Lambda function
generates and returns a
presignedS3 URL
2)The client uploads the
image to S3 directly,
using the resigned S3
URL
API Gateway Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
Concurrencyis the number of in-flight requests your AWS Lambda function is
handling at the same time
Lambda Concurrency
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adju
stab
le
Mitigation
Concurrent
executions/
Concurrency
limit
The maximum number of
events that functions can
process simultaneously in
the current region
1.000 Rearchitect
Burst
Concurrency
Limit
After the initial burst,
concurrency scales by 1000
executions every 10
seconds up to your account
concurrency limit. Each
function within an account
now scales independently
from each other
•US West (Oregon), US
East (N. Virginia), Europe
(Ireland)=3.000
•Asia Pacific (Tokyo),
Europe (Frankfurt), US
East (Ohio)=1000
•All other Regions=500
Use
provisioned
concurrency
Lambda Important Service Quotas New
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://aws.amazon.com/de/blogs/compute/understanding-aws-lambdas-invoke-throttle-limits/
Lambda concurrencylimit is a limit on the
simultaneous in-flight invocations allowed at
the same time
Transaction per second (TPS) =
concurrency / function duration in
seconds
Lambda Concurrency and TPS
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota DescriptionValue Adjust
able
Mitigation
TPS
(Transaction
per Second)
The
maximum
number of
TPS
TPS = min(10 x
concurrency,
concurrency /
function duration
in seconds)
•If the function duration is exactly
100ms (or 1/10th of a second),
both terms in the min function
are equal
•If the function duration is over
100ms, the second term is lower
and TPS is limited as per
concurrency/function duration
•If the function duration is under
100ms, the first term is lower
and TPS is limited as per 10 x
concurrency
Lambda Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://aws.amazon.com/de/blogs/compute/understanding-aws-lambdas-invoke-throttle-limits/ https://www.linkedin.com/pulse/how-aws-lambda-works-underneath-shwetabh-shekhar/
The TPS limit exists to protect the Invoke Data Planefrom the high churn of short-
lived invocations. In case of short invocations of under 100ms, throughput is capped
as though the function duration is 100ms (at 10 x concurrency). This implies that
short lived invocations may be TPS limited, rather than concurrency limited.
Lambda TPS Quota
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
•Optimize for cost-performance
•Use AWS Lambda Power Tuning
•Reuse AWS Service clients/connections outside of the Lambda
handler
•Use the newest version of AWS SDK of programming language of your
choice
•Import only dependencies that you need (especially from AWS SDK)
•Minimize dependencies and package size
•Use a keep-alive directive to maintain persistent connections
•Implement (other) best practices to reduce cold starts
https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
General Best Practices for using Lambda
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value AdjustableMitigation
Function
timeout
The maximum timeout
that you can configure for
a function
15 min
Synchronous
payload
The maximum size of an
incoming synchronous
invocation requestor
outgoing response
6 MB For the Request:
•use API Gateway
serviceproxy to S3
•use pre-signed S3 URL and
upload directly to S3
For the Response:
Use response streaming (with
AWS Lambda Web Adapter )
https://theburningmonk.com/2020/04/hit-the-6mb-lambda-payload-limit-heres-what-you-can-do/
Lambda Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://aws.amazon.com/de/blogs/compute/introducing-aws-lambda-response-streaming/
You can use response streaming to send responses larger than Lambda’s 6 MB
response payload limit up to a soft limit of 20 MB.
•Response streaming currently supports the Node.js 14.x and subsequent
managed runtimes
•To indicate to the runtime that Lambda should stream your function’s responses,
you must wrap your function handler with the streamifyResponse() decorator.
This tells the runtime to use the correct stream logic path, allowing the function to
stream responses
exports.handler = awslambda.streamifyResponse(
async (event, responseStream, context) => {
responseStream.setContentType(“text/plain”);
responseStream.write(“Hello, world!”);
responseStream.end();});
Lambda Response Streaming
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjus
table
Mitigation
Table-level
read/wrtie
throughput limit
The maximum number of
read/write throughput allocated
for a table or global secondary
index
40.000 RCU/
40.000 WCU
Ask for quote
increase
Table-Level burst
capacity for
provisioned
capacity mode
During an occasional burst of
read or write activity, these extra
capacity units can be consumed
quickly
up to 300
seconds of
unused RCUs
and WCUs
Partition-level
read/write
throughput
The maximum number of
read/write throughput allocated
for a partition
3000 RCU /1000
WCU
Use best
practices to
avoid hot
partition
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#default-limits-throughput-capacity-modes
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-throughput-bursting
DynamoDB Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
On-Demand Capacity Mode is ideal for:
•Unknown workloads
•Frequently idle workloads
•Staging and (individual) test environments
•Unpredictable application traffic
•Low management overhead (truly serverless mode) is preferable
DynamoDB Provisioned Throughput vs On-Demand
Capacity Mode
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Initial throughput for
on-demand capacity
mode
Initial throughput for on-demand
capacity mode
See futher details
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#default-limits-throughput-capacity-modes
DynamoDB Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Newly created table with on-demand capacity mode:
•Enables newly created on-demand tables to serve up to 4,000 WCUs or
12,000 RCUs
•If you exceed double your previous traffic's peak within 30 minutes, then you
might experience throttling
•One solution is to pre-warm the tables to the anticipated peak capacity of the
spike by:
•Performing the load test
•Creating table in provisioned mode with high enough WCUs/RCUs and
then switch to on-demand mode
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.InitialThroughput
Initial Throughput for DynamoDB On-Demand Capacity
Mode
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Existing table switched from provisioned to on-demand capacity
mode:
•Your table will deliver at least as much throughput as it did prior to
switching to on-demand capacity mode
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.InitialThroughput
Initial Throughput for DynamoDB On-Demand Capacity
Mode
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
•Use high-cardinality attributes
•These are attributes that have distinct values for each item, like email_id,
employee_no, customer_id, session_id, order_id, and so on
•Use composite attributes
•Try to combine more than one attribute to form a unique key, if that meets your
access pattern. For example, consider an orders table with
customerid#productid#countrycodeas the partition key and order_dateas the sort
key, where the symbol # is used to split different field
•Add random numbers or digits from a predetermined range for write-heavy use
cases
•Suppose that you expect a large volume of writes for a partition key (for example,
greater than 1000K writes per second). In this case, use an additional prefix or suffix
(a fixed number from predetermined range, say 0–9) and add it to the partition key,
like InvoiceNumber#Random(0-N)
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html
https://aws.amazon.com/de/blogs/database/choosing-the-right-dynamodb-partition-key/
Recommendation for DynamoDB partition keys
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Serverless Application with Aurora (Serverless) instead of
DynamoDB
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Data API requestsper
second
The maximum number of requests to
the Data API per second allowed in
this account in the current AWS
Region
1.000
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html
Aurora Serverless v1 Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Data API
requests
per second
The maximum number of
requests to the Data API per
second allowed
The max_connectionsvalue for
Aurora Serverless v2DB
instances is based on the
memory size derived from the
maximum ACUs.
However, when you specify a
minimum capacity of 0.5 ACUs
on PostgreSQL-compatible DB
instances, the maximum value of
max_connectionsis capped at
2,000.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max-connections
Aurora Serverless v2 Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max-connections
Aurora Serverless v2 Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Data API HTTP
request body size
The maximum size allowed for the
HTTP request body
4 Megabytes
Data API maximum
result set size
The maximum size of the database
result set that can be returned by
the Data API.
1 Megabytes
Data API maximum
size of JSON response
string
The maximum size of the simplified
JSON response string returned by
the RDS Data API.
10 Megabytes
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html
Aurora Serverless v2 Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Throughput
per Standard
Queue
Standard queues support a nearly unlimited
number of transactions per second (TPS) per
API action.
Nearly
unlimited
SQS (Standard) Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-seahttps://aws.amazon.com/about-aws/whats-new/2023/11/aws-lambda-polling-scale-rate-sqs-event-source/?nc1=h_ls
https://aws.amazon.com/blogs/compute/introducing-faster-polling-scale-up-for-aws-lambda-functions-configured-with-amazon-sqs/
•When a Lambda function subscribes to an SQS
queue, Lambda polls the queue as it waits for
messages to arrive. It consumes messages in
batches, starting with 5functions at a time
•If there are more messages in the queue, Lambda
adds up to 300functions/concurrent executions
per minute, up to 1,000 functions (or up to your
account concurrency limit), to consume those
messages from the SQS queue
•This scaling behavior is managed by AWS and
cannot be modified
•To process more messages, you can optimize your
Lambda configuration for higher throughput
Lambda scaling with SQS standard queues
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
https://aws.amazon.com/de/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/
https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#services-sqs-batchfailurereporting
•Increase the allocated memory for your Lambda
function
•Optimize batching behavior:
•by default, Lambda batches up to
10 messagesin a queue to process them
during a single Lambda execution. You can
increase this number up to 10,000messages,
or up to 6MBof messages in a single batch
for standard SQS queues
•If each payload size is 256KB(the maximum
message size for SQS), Lambda can only take
23messagesper batch, regardless of the
batch size setting
•Implement partial batch responses
Lambda scaling with SQS standard queues
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Quota Description Value Adjustable
Throughput
per Standard
Queue
Standard queues support a nearly unlimited
number of transactions per second (TPS) per
API action.
Nearly
unlimited
In-Flight
Messages per
Standard Queue
The number of in-flight messages (received
from a queue by a consumer, but not yet
deleted from the queue) in a standard queue
120.000
Message size The size of a message 256KB
SQS (Standard) Important Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
The BatchWriteItemoperation puts
or deletes multiple items in one or
more tables.
A single call to BatchWriteItemcan
transmit up to 16MBof data over
the network, consisting of up to
25 item put or delete operations
use BatchWriteItem
https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchWriteItem.html
Use BatchWriteItemrequest for storing to DynamoDB
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
•Put DynamoDB Accelerator (DAX) in front of DynamoDB
•Requires putting Lambda behind VPC
•ElastiCachebefore Aurora Serverless
•Requires putting Lambda behind VPC
•No “pay as you go” pricing
•Enable API Gateway Caching
•Uses ElastiCachebehind the scenes
•No “pay as you go” pricing for ElastiCache
•Use CloudFront (and its caching capabilities) in front of API Gateway
Other Optimizations: Caching
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
•Set meaningful timeouts
•For API Gateway, Lambda
•Retry with exponential backoff and jitter
•AWS SDK supports them out of the box
•Implement idempotency
•AWS Lambda Powertools(Java, Python, Typescript) supports idempotency
module
https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html
https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
https://aws.amazon.com/de/blogs/architecture/exponential-backoff-and-jitter/
https://aws.amazon.com/blogs/compute/handling-lambda-functions-idempotency-with-aws-lambda-powertools/
Other Optimizations: Error Handling and Retries
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
More Serverless services, more service quotas ☺
•CloudFront
•EventBridge
•SNS
•Kinesis
•StepFunctions
Services Quotas of other Serveressservices
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
•Know, understand and observe the service quotas
•Architect with service quotas in mind
•AWS adjusts them from time to time
•In case I’d like to request the quota increase, provide a valid
justification for the new desired value
•Service quotas are valid per AWS account (per region)
•Use different AWS accounts for development and testing
•Use different AWS accounts for independent (micro-)services
•Separate AWS accounts on the team level
•Use AWS Organizations
General best practices for Service Quotas
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Challenges and lessons learned
Architect with AWS Serverless quotas and technical concepts in mind
General architectural decisions
SQS vs SNS vs Kinesis vs EventBridge
Aurora (Serverless) vs DynamoDB
Challenging Serverless observability
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
When to use SQS, SNS, Kinesis and EventBridge
https://www.serverlessguru.com/tips/sqs-vs-sns-vs-kinesis-vs-eventbridge
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
DynamoDB DynamoDB + DAX
Investment in
Knowledge
•Understanding of
NoSQL databases
•Understanding of
single-table design
principles
Same
Requires to put
Lambda into the VPC
to access the database
DynamoDB
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Aurora (Serverless v2)
+ RDS Proxy
Aurora (Serverless v2)
+ Data API
Investment in
Knowledge
Relational databases are
familiar to many developers
Same
Engine Support MySQL and PostgreSQL MySQL and PostgreSQL
Requires to put
Lambda into the
VPC to access the
database
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.html
https://dev.to/aws-builders/data-api-for-amazon-aurora-serverless-v2-with-aws-sdk-for-java-part-1-introduction-and-set-up-of-the-sample-application-3g71
Aurora (Serverless v2 )
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Challenges and lessons learned
Architect with AWS Serverless quotas and technical concepts in mind
General architectural decisions
SQS vs SNS vs Kinesis vs EventBridge
Aurora (Serverless) vs DynamoDB
Challenging Serverless observability
Firdaws Aboulaye & Vadym Kazulkin ip.labs
Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
Serverless reduces the need for (readily
available) ops skills but increases the
demand for (less readily available)
distributed system design skills.
https://architectelevator.com/cloud/serverless-illusion/
Serverless challenges
Firdaws Aboulaye & Vadym Kazulkin ip.labs
FAQ Ask me Anything
76 Amazon DevOps Guru for the Serverless Applications
Firdaws Aboulaye & Vadym Kazulkin ip.labs 77
Thank you
Amazon DevOps Guru for the Serverless Applications