The document discusses serverless computing and functions as a service (FaaS) platforms. It provides an overview of Amazon Lambda including details on storage limits, duration limits, memory sizes, and how functions are executed in containers. It also summarizes the key points of Amazon's serverless manifesto and lists several FaaS providers and event sources. The document raises questions about the challenges of orchestrating containers at scale and implementing serverless architectures for low latency and state management.

1. @ewindisch @IOpipes
The Truth Behind Serverless
CTO & Co-founder, IOpipe
Erica Windisch

2. @ewindisch @IOpipes
What-a-less?

9. @ewindisch @IOpipes

10. Serverless
Culture
Don’t build, when you
can buy.
Build as little as
necessary.
Build with the minimum
operational complexity.
Maybe all you need are some circles

11. @ewindisch @IOpipes

12. @ewindisch @IOpipes

13. @ewindisch @IOpipes

14. @ewindisch @IOpipes

15. @ewindisch @IOpipes
The 12 Factor App
I. Codebase One codebase tracked in
revision control, many deploys
II. Dependencies Explicitly declare and isolate
dependencies
III. Config Store config in the environment
IV. Backing services Treat backing services
as attached resources
V. Build, release, run Strictly separate build
and run stages
VI. Processes Execute the app as one or more
stateless processes
VII. Port binding Export services via port
binding
VIII. Concurrency Scale out via the process
model
IX. Disposability Maximize robustness with
fast startup and graceful shutdown
X. Dev/prod parity Keep development,
staging, and production as similar as possible
XI. Logs Treat logs as event streams
XII. Admin processes Run admin/management
tasks as one-off processes

16. @ewindisch @IOpipes
Amazon’s “Serverless (functions) Manifesto”
✤ 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.

17. @ewindisch @IOpipes

18. @ewindisch @IOpipes
Platforms
- AWS Lambda
- Azure Functions
- Google Cloud
Functions
- Oracle’s fn()
- IBM Bluemix
Functions
- OpenWhisk
- Spring Functions
- Galactic Fog
- Stdlib
- Now.sh
- Auth0 Webtasks &
Extend
- AppEngine Classic
- Heroku
- Parse
- Firebase
- Google PubSub
- Google BigQuery
- AWS S3
- AWS SNS
- AWS Athena
- AWS Kinesis
- AWS DynamoDB
& more

19. @ewindisch @IOpipes
Platforms - FaaS providers
- AWS Lambda
- Azure Functions
- Google Cloud
Functions
- Oracle’s fn()
- IBM Bluemix
Functions
- OpenWhisk
- Spring Functions
- Galactic Fog
- Stdlib
- Now.sh
- Auth0 Webtasks &
Extend
- AppEngine Classic
- Heroku
- Parse
- Firebase
- Google PubSub
- Google BigQuery
- AWS S3
- AWS SNS
- AWS Athena
- AWS Kinesis
- AWS DynamoDB
& more

20. @ewindisch @IOpipes
Platforms - Event sources
- AWS Lambda
- Azure Functions
- Google Cloud
Functions
- Oracle’s fn()
- IBM Bluemix
Functions
- OpenWhisk
- Spring Functions
- Galactic Fog
- Stdlib
- Now.sh
- Auth0 Webtasks &
Extend
- AppEngine Classic
- Heroku
- Parse
- Firebase
- Google PubSub
- Google BigQuery
- AWS S3
- AWS SNS
- AWS Athena
- AWS Kinesis
- AWS DynamoDB
& more

21. Lambda Demo
console.aws.com

22. @ewindisch @IOpipes
75 GB storage limit for all functions

23. @ewindisch @IOpipes
5 minute maximum duration

24. @ewindisch @IOpipes
~20ms for “hello world”

25. @ewindisch @IOpipes
128MB to 1.5GB memory

26. @ewindisch @IOpipes
1000 containers max (by default)

27. @ewindisch @IOpipes
Functions lazy-loaded from s3

28. @ewindisch @IOpipes
Containers + processes long-lived,
automatically scaled and garbage-collected.
4.5 minutes to 4.5 hours

29. @ewindisch @IOpipes
Pauses / unpauses containers between events

30. @ewindisch @IOpipes
non-root user

31. @ewindisch @IOpipes
/ read-only
/tmp 512MB max
function mounted to /var/task

32. @ewindisch @IOpipes
Amazon’s “Serverless (functions) Manifesto”
✤ 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.

33. @ewindisch @IOpipes
Demo Slide
Click to add text

35. @ewindisch @IOpipes
App Creation
Upload to S3
CreateFunction API call pointing to S3 resource

36. @ewindisch @IOpipes
Warming
Amazon automatically scales VMs & allocates to users.
They do not warm processes/containers

37. @ewindisch @IOpipes
Triggers & Events
- Invoke functions via API
- Configure event source to function mappings

38. @ewindisch @IOpipes
Schedule
Events are mapped to running containers first,
Or new containers are spawned to process events.

39. @ewindisch @IOpipes
Invoke
Synchronous HTTP API
Container is spawned, if not existing.
Existing container is unpaused, fed event, then paused.

40. @ewindisch @IOpipes
Visibility
Logs and metrics are sent to Cloudwatch.

41. @ewindisch @IOpipes
Garbage Collection
- Reap containers when they're no longer active
- Reap VMs when they’re no longer active

42. @ewindisch @IOpipes
Orchestration Challenges

43. @ewindisch @IOpipes
Scaling VMs and scaling containers

44. @ewindisch @IOpipes
Each tenant needs a container cluster?

45. @ewindisch @IOpipes
Are Kubernetes or Swarm fast enough?

46. @ewindisch @IOpipes
HTTP + serialization/deserialization
for series of events are SLOW

47. @ewindisch @IOpipes
Implementation Details

48. @ewindisch @IOpipes
How to minimize latency of API
processing & response?

49. @ewindisch @IOpipes
how do we do messaging / communication?

50. @ewindisch @IOpipes
How do we manage state?

51. @ewindisch @IOpipes
How do we orchestrate containers?

52. @ewindisch @IOpipes
Which language?

53. @ewindisch @IOpipes
Putting it back
together
https://prezi.com/view/
K5Xz8xT6BoTYbx2EgGk1/

54. @ewindisch @IOpipes
Finally…

55. @ewindisch @IOpipes
Remember…

56. @ewindisch @IOpipes
It’s all about the events.

57. @ewindisch @IOpipes
Events are always immutable.

58. @ewindisch @IOpipes
Event processing can and should be immutable.

59. @ewindisch @IOpipes
Event processing should be fast & low-latency.

60. @ewindisch @IOpipes
Events generate events.
(it’s turtles all the way down)

61. @ewindisch @IOpipes
FaaS architecture should be designed
for performance and immutability

62. @ewindisch @IOpipes
Don’t build when you can buy
(you probably shouldn’t build anything I just showed you!)

63. Erica Windisch
CTO & Founder IOpipe, Inc.
@ewindisch
www.iopipe.com