ServerlessConf 2018 Keynote - Debunking Serverless Myths (no video / detailed cost analysis version)

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Dr. Tim Wagner
General Manager, AWS Lambda and Amazon API Gateway
Serverless Myth

Myth #1:
“Serverless is insecure.”

Maybe you meant…?
• ”I have an agent that I used to secure my server fleet, but I
can’t install it now”
• ”I don’t trust my employees to use the security features.”
• “I leave things lying around and can’t be bothered to clean
them up.”

Shared responsibility model
Hypervisor and VPC
Physical server and network
Physical access
Application code
Language runtime
OS
Language runtime
OS
Hypervisor and VPC
Physical access
Application code
Classic Serverless

Hypervisor and VPC
Physical access
Application code
Language runtime
OS
Language runtime
OS
Hypervisor and VPC
Physical access
Application code

Access controls
Execution privilege controls
Automated auditing
• Code & config changes
• Invocations
• Data lake tools to scan audit
traces
Proactive “fleet-wide” policy
enforcement
Application code
Secure credential handling
Encryption at rest
Custom authorizers for APIs
Managed user pools/login

Vendors can only help *on the perimeter*!
Monolith
All you. Be sure not to mess up.

Serverless == Fine-grained vendor protection
Microservice
The full power of your cloud vendor
around every one of these, for every
single invocation.

New permissions boundary capability
Ability to restrict what a
user can grant indirectly
by creating Lambda
functions.

Serverless Security Benefits versus Classic Code
• Time-limited, no server affinity – makes serverless harder to
attack
• Frequent server reboots and professional management of
the fleet (think Spectre/Meltdown) versus, ahem, on-prem
state of the practice
• Fine-grained security: microservices have higher vendor
surface area, meaning more frequent and more detailed
checks

What’s not a myth here?
You have to use the features to benefit from them!
 If you’re not good at cleanup, write a serverless cron job to
email you if a function isn’t getting used.
 If your org doesn’t enforce consistency via pipelines or
CRs, then use AWS Config and/or CloudTrail to get there.

Myth #2:
“Serverless is too expensive;
you’ll need to go back to servers
at scale.”

A tale of two computes
Normalized to 1 GB
3-year reserved instance
US-East-1 Region:
$114
Amazon EC2 t2.medium
Constant use for 3 years
@ 1 concurrent execution:
$1,577
Uh oh
AWS Lambda 1GB

Oops, forgot something…
One instance isn’t fault tolerant; you need at least 2, and then
you need a router.

Normalized to 1 GB
X2, plus ALB
$1,030
$1,577
Still uh oh
AWS Lambda 1GB

Maybe we’re missing the bigger picture…
Serverless has lots of built-in functionality!
S3  Lambda
S3  SQS  t2 (poll + process)
Let’s say 1 TPS arrival rate to keep the math simple.
That’s $113 for SQS operations.
Lambda: Add $0.20/million requests = $19

Normalized to 1 GB
X2, plus ALB
$1,143
$1,596
Still uh oh
AWS Lambda 1GB

Also…burst credits aren’t apples-to-apples
We’re assuming a fully-utilized machine, but T’s utilize burst
crediting. What if we switched to C’s to make sure we have
continuous power (which Lambda provides)?
Redoing analysis with C4.large: $1,455
Lambda: $1,596
Hmm…~10% surcharge for “going serverless”?

Other forms of savings
TCO – “Think of the costs you’ll save in fleet ops!”
Time to market – “Our business will grow faster!”
A 10% markup for not having to deal with provisioning,
deploying, patching, security analysis, monitoring, etc. of
servers sounds a pretty good deal.
But, it doesn’t sound like a major economic improvement.

Q: Is the workload uniform?

Why is it *so darn hard* to keep
servers warm????

Forms of Waste: Periodic
WASTE
Actual
Load

Forms of Waste: High peak-to-Average
WASTE
Actual
Load

Forms of Waste: Peak Buffer (”Black Friday”)
WASTE
Actual
Load
o
o
p
s

Forms of Waste: Auto-Scaler discretization
WASTE
Actual
Load

When we last saw our serverless hero…
T2.Medium: $1,144
C4.large: $1,455
Lambda: $1,596 (10% premium to C4, 40% premium to T2)

If we look at utilization, the picture changes
$0
$200
$400
$600
$800
$1,000
$1,200
$1,400
$1,600
$1,800
100% 90% 80% 70% 60% 50% 40% 30% 20% 10%
Effect of Utilization on Cost
T2
C4
Lambda

We’re all above average here…?
My servers are always hot.
Oh bro, LOL

If we look at utilization, the picture changes
$0
$200
$400
$600
$800
$1,000
$1,200
$1,400
$1,600
$1,800
100% 90% 80% 70% 60% 50% 40% 30% 20% 10%
T2
C4
Lambda
Average
Enterprise
Utilization:

Factor in amazing auto-scaling: 20% of perfect
0
200
400
600
800
1,000
1,200
1,400
1,600
1,800
100% 90% 80% 70% 60% 50% 40% 30% 20% 10%
T2
C4
Lambda

Factor in amazing auto-scaling
0
200
400
600
800
1,000
1,200
1,400
1,600
1,800
100% 90% 80% 70% 60% 50% 40% 30% 20% 10%
T2
C4
Lambda
C breakeven ~90% T breakeven ~50%

The bottom line
Worst case: Similar cost but you save on server-related ops.
Best case: 10:1 or better cost compression
How to (roughly) estimate savings:
• Subtract safety margin from your server-based costs and
then divide by your peak-to-average ratio

That’s too much work; can’t you just give me the
answer?
Predicted Compute Savings by Category
(versus server-based designs):
Web, mobile, or IoT app: 5-10x
Streaming app: 2-5x
Batch computation: 0-4x

Is it ever not a rosy picture?
Sub-100ms: YMMV
For very fast jobs (single- and low double-digit ms), minimum billing
charges can lower cost efficiency, while utilization-related packing
improves cost efficiency. You’ll need to model these workloads more
precisely to know which effect dominates for your specific case.

Does it matter?
Worldwide Public Cloud Services Spending Forecast to Reach
$160 Billion This Year, According to IDC

Myth #3:
“Serverless is just an unzip
library.”

What *is* an application?

What is an application?
2014 answer:
”A bunch of code I have to build & test together into a
monolithic blob, which I then toss over the wall to an ops
team, who get it to run on a fleet of servers. Then, we hope
that some work comes its way.”
2018 answer: Managed services in the public cloud,
connected and customized with highly differentiated business
logic, that run (and bill) only when actually needed.

Managed services as building blocks
Amazon SNS
Amazon SQS
Amazon S3
Messaging
Monitoring and Debugging
Storage
AWS X-Ray
AWS Lambda
Amazon API Gateway
Orchestration
API Proxy
Compute
AWS Step Functions
Amazon DynamoDB
Amazon Kinesis
Analytics
Database
Edge Compute
AWS Greengrass
Lambda@Edge
Amazon Athena
Amazon Aurora
Serverless (coming soon)

Amazon API Gateway
API Proxy
AWS Lambda
Compute
Amazon S3
Storage
Example: Serverless web app
Amazon DynamoDB
Database
Amazon Aurora
Serverless (coming soon)
Static Content Dynamic Content
API Serving

AWS Lambda
Compute
Example: Serverless analytics
Amazon Kinesis
Analytics
Amazon Athena

Patterns for the Cloud Era
• Media transform on upload: Amazon S3 event +
AWS Lambda
• NoSQL data cleansing: Amazon DynamoDB
change streams + Lambda
• Serverless website: Amazon S3 + Amazon
DynamoDB + Amazon API Gateway + Lambda
• Click-stream analytics: Amazon Kinesis Data
Firehose + Lambda
• Ordered event processing: Kinesis + Lambda
• Multi-function fanout: Amazon SNS (or Lambda)
+ Lambda
• Workflows: AWS Step Functions + Lambda
• Event distribution: Amazon CloudWatch Events +
Lambda
• Serverless cron jobs: CloudWatch timer events +
Lambda
• GraphQL actions: AWS AppSync + Lambda
• On-the-fly image resizing: AWS Lambda@Edge
+ Amazon CloudFront
• Email rules: Amazon SES + Lambda
• Configuration policy enforcement: AWS Config +
Lambda
• Stored procedures: Amazon Aurora + Lambda
• Custom authorizers for APIs: API Gateway auth +
Lambda
• DevOps choreography: CloudWatch alarms +
Lambda
• Alexa skills: Amazon Alexa + Lambda
• Chatbots: Slack + Amazon Lex + Lambda
• IoT automation: AWS IoT + Lambda
• Smart devices: AWS Greengrass + Lambda
• On-premises file encrypt for transit: AWS
Snowball Edge + Lambda
• …

Meta-patterns
1. Service pushes async event to Lambda (S3, SNS)
2. Lambda grabs event from service (DynamoDB, Kinesis)
3. Synchronous exchange (Alexa, Lex)
4. Batch transform (Kinesis Data Firehose)
5. Microservice (API + Lambda + your choice of DB)
6. Customization via functions (AWS Config, SES rules)
7. Data-driven fanout (S3-Lambda, Lambda-Lambda)
8. Choreography (Step Functions + Lambda)
9. Lambda functions in devices (Greengrass, Snowball Edge)

Some final thoughts on this myth…
Managed Serverless is to FaaS library-on-DIY containers as
Public cloud services are to on-prem.
Secure, real-time, multi-dimensional bin packing with a 1 ms
decision entitlement onto a massive fleet of silicon offering
economies of scale to its consumers is a different beast than a
server running a convenience library.
Managed services are the “Design Patterns” of today.

Any predictions?

P.S.: Any predictions?
It’s getting hard to stay ahead of reality; here are some of my
earlier predictions:
• Lower ops costs (check)
• New software patterns emerge (check)
• Big data goes serverless (check)
• Rise of events/reactive systems (check)
• “Born serverless” startups emerge (check)
• HTTP FTW (ok this one is still in progress…)

Two predictions today:
1. Serverless is the new supercomputer (aka, every paper Eric
Jonas writes about serverless will come true).
2. Blockchain (ledger) owners embrace async, event-based
architectures…another “peanut butter and chocolate” combo.

Go Serverless!

ServerlessConf 2018 Keynote - Debunking Serverless Myths (no video / detailed cost analysis version)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a ServerlessConf 2018 Keynote - Debunking Serverless Myths (no video / detailed cost analysis version)

Similar a ServerlessConf 2018 Keynote - Debunking Serverless Myths (no video / detailed cost analysis version) (20)

Último

Último (20)

ServerlessConf 2018 Keynote - Debunking Serverless Myths (no video / detailed cost analysis version)

Notas del editor