31 May 2017 - at EPITA
Introduction to
Serverless through
Architectural Patterns
1/18
Who am I?
DevOps @CloudScreener
EPITA 2015
Specialised in Systems, Networks and Security
Cloud Systems Engineer @Axiad IDS, 2015-2016
Passion for creating products,
while learning new technologies
@MathieuMailhos
Cloud & Ops Enthousiast
2/18
Context & Introduction
I/ Introducing Serverless
II/ Architectural Patterns
III/ Serverless Framework Demo
IV/ Overall Benefits and Drawbacks
Conclusion
Agenda
3/18
Adopt the lean startup methodology:
Business Hypothesis needs to be validated
Only invest time and money on non-risky projects
If you fail, fail fast. Then learn and retry.
We need less overhead in our development
Focus on building the product:
Remove the boring and hard part around managing
your infrastructure
Timing is a major key of success
4/18
Internet based systems where application process rely on:
1. A combination of 3rd party services: Backend As A Service
2. Remote procedure calls: Function As A Service
3. Rich client-side logic
Basically, write scalable code without having to think about
details of the container, operating system or infrastructure that
run the program
Only pay for what you use
Connecting APIs to avoid hosting and managing servers
Introducing Serverless
5/18
Provide Hardware
by abstracting
physical
environment
Deploy in Months
Live for Years
Provide OS
through
Virtual Machines
Deploy in minutes
Live for weeks
Provide
Application
Environment
through
Containers
Deploy in seconds
Live for hours
Provide
completely
abstracted
environment
through
Functions
Deploy in
milliseconds
Live for seconds
Infrastructure Abstraction Evolution
Datacenter IaaS PaaS FaaS
6/18
Function As A Service
Multiple Providers:
AWS Lambda, Google Cloud Functions, MS Azure Functions, IBM OpenWhisk, Twilio Functions,
iron.io (on-premise), Galactic Fog (on-premise)
Or build your own: http://blog.alexellis.io/functions-as-a-service/
Unit of
deployment:
A Function
Stateless:
Running in an
ephemeral
containers
Pricing Model:
Pay per execution
count and length
Scaling & High
Availability:
Automatic
Execute code, without managing servers, based on direct
invocations or events
Use your own language
Zip and upload.
Choose the amount of
memory you need.
RAM, Disk and
Processes are not
persistent.
Do not count on them!
Usually, pay per 100ms.
Direct consequences of
running optimised code
Each vendor has its own
limits. However, there is
no SLA guaranteed (yet).
7/18
We can find all we need to build our product out there
APIs are the new libraries
Database,
Storage
Authentication,
Analytics,
Messaging,
Tooling (Logging, Monitoring…),
Artificial Intelligence,
As A Service
Backend As A Service
8/18
Standard Web App,
All the logic is on the servers
Serverless: More logic in the
client. Use of multiple services.
Implies the need to manage
monitoring and security on each
component.
Web Application Pattern
AWS API Gateway /
Google Cloud Endpoints: 

Gateway/Proxy for HTTP Calls.
Manage authentication, caching,
monitoring, throttling.
Update requests on the fly
9/18
Recurring Jobs:
Log analysis, SSL Checks, Backups…
Use of a scheduler / source of trigger
Multiple notifications channels, log file
Automations
Event Driven:
Processing files upload,
Reacting to database key change,
New created user…
10/18
Presenting the Fan Out Pattern
Batch Processing
Process huge volume of data on a regular basis
Non-interactive background job
Apply the MapReduce programming model to serverless
Speed depends on the number of invoked concurrent functions
Save state in any storage / database depending on your data structure
11/18
Stream Processing
Process non-interrupted stream of data in near real-time
Handle spiky traffic and message ordering
Use of Kinesis or a Message Queueing Service to store data
Beware of poisoning messages & be prepared for Lambda failures (DLQ)
Then process those data subsets by calling functions concurrently
Tune your functions capacities and concurrent calls to keep up with ingest rate
12/18
Demo
Write and deploy your entire serverless infrastructure using only
configuration files and functions
Handle multiple vendors
Serverless Framework
https://github.com/serverless/serverless
13/18
Demo
Custom OAuth Authentication
https://github.com/mathieumailhos/sls-oauth-instagram
14/18
Custom OAuth Authentication
Typical use case where 2 functions make you avoid provisioning a server, setting up the system and the
development environment, its security, installing a reverse proxy, monitoring it and managing it over time…
15/18
Overall Benefits and Drawbacks
Benefits
Costs: Don’t pay for idle, overall less Ops work
Scale: Managed by the vendor, no over-provisioning anymore
High-Availability: automatic availability zones redundancy
Ops: Easy to maintain and deploy
Time: focus on code only
Greener: shared environment
Drawbacks
Beware of Vendor lock-in: migrations won’t be easy
Multi tenancy problems: security, robustness, performances
More front-end development required
Stateless changes the way to code, might require additional component
Startup latency and network dependencies
Debugging, Versioning, Testing and Monitoring can be tricky: need more tools
16/18
Conclusion
Serverless is not a correct approach for every problem
since it still has major drawbacks: latency, vendor lock-in…
But it is awesome when applied to lean methodology: deliver
fast, get feedbacks quickly.
Easy to get started: take advantage of the “free tier”

plan provided by vendors.
Bring huge opportunities for engineers with both
infrastructure and development skills.
17/18
Thank You
Question Time!
@MathieuMailhos linkedin.com/in/mathieumailhos github.com/MathieuMailhos
18/18

Introduction to Serverless through Architectural Patterns

  • 1.
    31 May 2017- at EPITA Introduction to Serverless through Architectural Patterns 1/18
  • 2.
    Who am I? DevOps@CloudScreener EPITA 2015 Specialised in Systems, Networks and Security Cloud Systems Engineer @Axiad IDS, 2015-2016 Passion for creating products, while learning new technologies @MathieuMailhos Cloud & Ops Enthousiast 2/18
  • 3.
    Context & Introduction I/Introducing Serverless II/ Architectural Patterns III/ Serverless Framework Demo IV/ Overall Benefits and Drawbacks Conclusion Agenda 3/18
  • 4.
    Adopt the leanstartup methodology: Business Hypothesis needs to be validated Only invest time and money on non-risky projects If you fail, fail fast. Then learn and retry. We need less overhead in our development Focus on building the product: Remove the boring and hard part around managing your infrastructure Timing is a major key of success 4/18
  • 5.
    Internet based systemswhere application process rely on: 1. A combination of 3rd party services: Backend As A Service 2. Remote procedure calls: Function As A Service 3. Rich client-side logic Basically, write scalable code without having to think about details of the container, operating system or infrastructure that run the program Only pay for what you use Connecting APIs to avoid hosting and managing servers Introducing Serverless 5/18
  • 6.
    Provide Hardware by abstracting physical environment Deployin Months Live for Years Provide OS through Virtual Machines Deploy in minutes Live for weeks Provide Application Environment through Containers Deploy in seconds Live for hours Provide completely abstracted environment through Functions Deploy in milliseconds Live for seconds Infrastructure Abstraction Evolution Datacenter IaaS PaaS FaaS 6/18
  • 7.
    Function As AService Multiple Providers: AWS Lambda, Google Cloud Functions, MS Azure Functions, IBM OpenWhisk, Twilio Functions, iron.io (on-premise), Galactic Fog (on-premise) Or build your own: http://blog.alexellis.io/functions-as-a-service/ Unit of deployment: A Function Stateless: Running in an ephemeral containers Pricing Model: Pay per execution count and length Scaling & High Availability: Automatic Execute code, without managing servers, based on direct invocations or events Use your own language Zip and upload. Choose the amount of memory you need. RAM, Disk and Processes are not persistent. Do not count on them! Usually, pay per 100ms. Direct consequences of running optimised code Each vendor has its own limits. However, there is no SLA guaranteed (yet). 7/18
  • 8.
    We can findall we need to build our product out there APIs are the new libraries Database, Storage Authentication, Analytics, Messaging, Tooling (Logging, Monitoring…), Artificial Intelligence, As A Service Backend As A Service 8/18
  • 9.
    Standard Web App, Allthe logic is on the servers Serverless: More logic in the client. Use of multiple services. Implies the need to manage monitoring and security on each component. Web Application Pattern AWS API Gateway / Google Cloud Endpoints: 
 Gateway/Proxy for HTTP Calls. Manage authentication, caching, monitoring, throttling. Update requests on the fly 9/18
  • 10.
    Recurring Jobs: Log analysis,SSL Checks, Backups… Use of a scheduler / source of trigger Multiple notifications channels, log file Automations Event Driven: Processing files upload, Reacting to database key change, New created user… 10/18
  • 11.
    Presenting the FanOut Pattern Batch Processing Process huge volume of data on a regular basis Non-interactive background job Apply the MapReduce programming model to serverless Speed depends on the number of invoked concurrent functions Save state in any storage / database depending on your data structure 11/18
  • 12.
    Stream Processing Process non-interruptedstream of data in near real-time Handle spiky traffic and message ordering Use of Kinesis or a Message Queueing Service to store data Beware of poisoning messages & be prepared for Lambda failures (DLQ) Then process those data subsets by calling functions concurrently Tune your functions capacities and concurrent calls to keep up with ingest rate 12/18
  • 13.
    Demo Write and deployyour entire serverless infrastructure using only configuration files and functions Handle multiple vendors Serverless Framework https://github.com/serverless/serverless 13/18
  • 14.
  • 15.
    Custom OAuth Authentication Typicaluse case where 2 functions make you avoid provisioning a server, setting up the system and the development environment, its security, installing a reverse proxy, monitoring it and managing it over time… 15/18
  • 16.
    Overall Benefits andDrawbacks Benefits Costs: Don’t pay for idle, overall less Ops work Scale: Managed by the vendor, no over-provisioning anymore High-Availability: automatic availability zones redundancy Ops: Easy to maintain and deploy Time: focus on code only Greener: shared environment Drawbacks Beware of Vendor lock-in: migrations won’t be easy Multi tenancy problems: security, robustness, performances More front-end development required Stateless changes the way to code, might require additional component Startup latency and network dependencies Debugging, Versioning, Testing and Monitoring can be tricky: need more tools 16/18
  • 17.
    Conclusion Serverless is nota correct approach for every problem since it still has major drawbacks: latency, vendor lock-in… But it is awesome when applied to lean methodology: deliver fast, get feedbacks quickly. Easy to get started: take advantage of the “free tier”
 plan provided by vendors. Bring huge opportunities for engineers with both infrastructure and development skills. 17/18
  • 18.
    Thank You Question Time! @MathieuMailhoslinkedin.com/in/mathieumailhos github.com/MathieuMailhos 18/18