Why Run in the Clouds

Why Run in the Clouds?

AWS Lambda

Content ~~Stolen~~ Curated by Steve Coffman

*aaS - Anything As a Service

IaaS - Infrastructure As A Service
PaaS - Platform As a Service
SaaS - Software As A Service
FaaS - Functions As a Service ⬅ You are here

You want to Kick *aaS, right? (Editor Note: I forgot where I stole this joke from)

Service Hosting	People Hosting
Physical Server, On Premise	Home Ownership
EC2 (Virtual Private Server)	Condo
ECS (Docker Containers )	Apartment
Lambda ("Serverless" Function)	Hotel

(Editor Note: This was my wife Jennifer's metaphor)

This chart I made up is kinda bullshit, but it sounds truthy

Type	Time to Value	Time to Scale	Cost of delivery	Utilization
Physical Server, Monolithic Service	Years	Months	$$$$$	Very Low
On Premises VM, Monolithic Service	Months	Days	$$$$	Low
AWS EC2, Microservices	Weeks	15 Minutes	$$$	Medium
AWS ECS (Docker), Microservices	Week(s)	15 seconds	$	High
AWS Lambda	Days	~500 ms (cold)	¢	100% (Perfect)

This quote is what I was trying to illustrate:

To optimize delivery the best practice was to amortize this high cost over a large amount of business logic in each release, and to release relatively infrequently. Given long lead times for infrastructure changes, it was necessary to pre-provision extra capacity in advance and this lead to very low average utilization.

—Adrian Cockcroft

From Michael Wittig:

There is less Ops in EC2 compared to your own VMware solution.
There is less Ops in RDS compared to your own Oracle database.
There is less Ops in Kinesis compared to your own Kafka cluster.
There is less Ops in Lambda compared to EC2

Also:

Less Dev in Lambda compared to your Play/Spring/Express Framework

From Revisting Serverless:

Frees up app developers from infrastructure concerns
App developers focus on business logic, less need for rockstar /ninja/fullstack engineers
Business pays for exactly what they consume
Business spend is proportional to business growth
Get away from instance based pricing, which is a rip off

AWS Lambda limits:

Node 6 (Node 8: April 2018)
maximum execution duration per request is set to 300 seconds
cold start response time largely dependent on file size (~500ms - 1800ms)
"Hot" response time almost instant (~ 0.32 ms)
1M free requests per month and 400,000 GB-seconds of compute time per month
AWS bills Lambda functions in 100-millisecond intervals
Lambda function deployment max package size (.zip file): 50 MB
Total size of all the deployment packages that can be uploaded per region: 75 GB
Max 1000 concurrent executions across all functions in a given region per account.

AWS Lambda Killer Use Cases:

Cloud Cron jobs
Authentication and Authorization (e.g. OAuth, JWT) for Single Page App
Filtering and transforming data on the fly
Log analysis on the fly
Event oriented architecture

AWS Lambda currently AW-kward:

Browser Websockets: Need AWS IoT Device Gateway with MQTT over WebSocket instead of API Gateway

AWS Lambda Poor Fit:

Huge files
Long Running Jobs

You should really check out:

Quotes:

In development, if you have thousands of Lambda files it’s super annoying because you have to share code, infrastructure, and resources across all these separate files. It gets complicated in the development and deployment phase. The function as the unit of deployment is powerful, but the function as the unit of development can be painful. -- Kiran Oliver

Unfortunately, these areas are emerging topics, which is a fancy way of saying there are still a lot of moving parts, and there are currently few best practice resources available in a central place. -- Michael Hausenblas

How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways? -- Courtney Nash

From AWS Lambda Test:

Base cost for 1 Million function calls taking 128MB RAM and running for 1ms:

base = 1000000 * $0.00001667 / 1000 / 1024 * 128 = $0.00208375

I will calculate the cost for 1 Million calls according to: Avg. 40ms startup time for Node.js ~ $0.08335

Even More Quotes

From Adrian Cockcroft:

The invocation latency for event driven functions is one of the key limitations that constrains complex applications, but over time those latencies are reducing.

The real point I’m making is that the ROI threshold for whether existing monolithic applications should be moved unchanged into the cloud or rewritten depends a lot on how much work it is to rewrite them. A typical datacenter to cloud migration would pick out the highly scaled and high rate of change applications to re-write from monoliths to microservices, and forklift the small or frozen applications intact. I think that AWS Lambda changes the equation, is likely to be the default way new and experimental applications are built, and also makes it worth looking at doing a lot more re-writes.

Serverless Manifesto

Rowan Udell:

While watching the Building Complex Serverless Applications talk from re:Invent 2016 I discovered The Serverless Compute Manifesto. I couldn't find it reproduced in an easy to use format, so here it is for future reference - yours and mine:

Function are the unit of deployment and scaling.
No machines, VMs, or containers visible in the programming model.
Permanent storage lives elsewhere.
Scales per request; Users cannot over- or under-provision capacity.
Never pay for idle (no cold servers/containers or their costs).
Implicitly fault-tolerant because functions can run anywhere.
BYOC - Bring Your Own Code.
Metrics and logging are a universal right.

I'm not sure who came up with it originally, but that talk was by David Potes and Ajay Nair from AWS.

From A Year with AWS Lambda:

Ideal For	Not Ideal For
Light-weight triggers	High volume microservices
Event driven architectures	Real time eventing
Low volume microservices	Global solutions where portability is key concern
Short-lived, stateless operations	Long-running tasks

StevenACoffman/Why Run in the Clouds.md