DevoxxFR 2017: Serverless architectures - 3 visions for serverless

#DevoxxFR
Devoxx France 2017
Adrien Blind @adrienblind
Laurent Doguin @ldoguin
Laurent Grangeau @laurentgrangeau
Ludovic Piot @lpiot
1
🛳 Mettez-le en œuvre dans votre entreprise
et arrivez à bon port
#serverless

Nous allons vous parler de…
● La notion de serverless, vaste débat…
● 3 visions différentes du serverless
− ReX Oxalide : almost-CaaS avec Kubernetes
− ReX Clever Cloud : You write code, we run IT (aPaaS)
− FaaS, la nouvelle coqueluche du marché

Avec, par ordre d’apparition…
Adrien Blind
@AdrienBl
ind
Thought Leader,
Docker Captain
Ludovic Piot
@lpiot
Head of
Customer Care
Laurent Doguin
@ldoguin
Developer
Relations VP
Laurent Grangeau
@laurentgran
geau
Cloud Solution
Architect

Introduction - la notion de Serverless
Introduction
la notion de Serverless,
vaste débat !

What do you really want
Deliver rapidely and flowly valuable apps
for the business

Cloud
for the business
Agile
DevOps
Microservice
architecture
Craftsmanship

On demand
Pay as you go
ElasticCloud
for the business
Agile
DevOps
Microservice
architecture
Craftsmanship

A new “cloudy” kid on the block

A single definition for Serverless?
“Serverless computing is a cloud computing execution model in which the cloud provider dynamically manages the
allocation of machine resources”
- Wikipedia
“Serverless computing refers to the concept of building and running applications that do not require server
management. It describes a finer-grained deployment model where applications, bundled as one or more
functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand
needed at the moment.”
- CNCF foundation whitepaper on Serverless
“Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend
as a Service or "BaaS") or on custom code that's run in ephemeral containers (Function as a Service or "FaaS") [...].
such architectures remove the need for the traditional 'always on' server system sitting behind an application.”
- Mike Roberts, martinfowler.com (2016)
“If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.”
- Adrian Cockroft (2016)

What are we talking about
❏ Dev/App perspective
Arch. design & granularity? Ephemeral apps? PaaS pattern?
Mostly all of them!
❏ Ops/platform perspective: infrastructure abstraction
Elastic → autoscaling
On-demand → boot in 20ms
Pay-as-you-go → Scale to zero
Cloud managed services
& … NoOps?

2 major serverless tendencies
❏ BaaS, aka Backend-as-a-Service
❏ FaaS, aka Functions-as-a-Service

❏BaaS, aka Backend-as-a-Service
❏ FaaS, aka Functions-as-a-Service

Cloud: IaaS
❏ End-product is almost the same (virtual machines)
❏ Facilitates lift & shift
❏ Interaction with the product change: cloud principles,
automation/infra-as-code
❏ Stimulated the commoditization trend: ops no longer deliver
per-app infrastructure architectures
❏ Starts to shift resiliency & scalability topics from infra to app

❏ Portability: containers isolate app/runtimes from subsequent OS
❏ Orchestrators enables to consider a pool of OS as a global resource
❏ Auto-scalability mostly based on infrastructure metrics (CPU)
❏ Pricing model mostly related to subsequent infrastructure used (cluster nodes)
❏ Containers commonly associated to finer app granularity
Cloud: CaaS

Cloud: PaaS or PaaS?
❏ PaaS stands for Platform-as-a-Service
❏ Application PaaS (aPaaS) pioneer: Google App engine
❏ xPaaS = managed services (DBaaS, object storage etc.)
❏ Complete abstraction from infrastructure
❏ Pricing model not related to infrastructure
❏ Autoscaling & resilient by design

Backend-as-a-Service architecture
BaaS → no!
PaaS
CaaS
IaaS

❏Not a cloud service offer, it’s an architecture concept
❏Build apps directly leveraging on PaaS services
❏Security paradigms shifts
From perimetric to embedded
Auth/Authz/Cipher everything
Backend-as-a-Service architecture
Authentication
Object Storage
Databases (ex.
DynamoDB, etc.)

❏ BaaS, aka Backend-as-a-Service
❏FaaS, aka Functions-as-a-Service

Client
Gateway
FaaS
platform
FaaS compute capacity abstracted from app perspective
Cloud: FaaS
❏ Ephemeral: platform waits requests...

Client
Instanciated
function
(your code)
Gateway
FaaS
platform
Cloud: FaaS
❏ Ephemeral: platform waits requests and
instantiate function on demand, which
“lives” the time to deliver the result: not
always-on!

❏ Ephemeral: platform waits requests and
instantiate function on demand, which
“lives” the time to deliver the result: not
always-on!
❏ Dynamic scalability & resilience provided
by the platform: more calls, more
instances
❏ Extremely fine grained pay-per-use on
public cloud: per-call costs
Client
Instanciated
function
(your code)
Instanciated
function
(your code)
Instanciated
function
(your code)
Gateway
FaaS
platform
Cloud: FaaS

❏Beware of design constraints applying to your app
❏ Service/function granularity
❏ Stateless services
❏ Small wake up time
❏ No long-running services
❏Deal with function graph calls & orchestration
❏Possible Vendor lock-in: check out serverless.io?
❏Testing → you must deploy on the platform everytime
❏Adapt DevOps practices: monitoring, deployment, versioning...
FaaS constraints

All major cloud vendors have products
Alternatively you can deploy your own FaaS fmk
You may leverage on existing CaaS and put value on top of it
• Container encapsulation of the function
• Kubernetes orchestration
FaaS on public cloud & FaaS on premises

❏ Serverless is an architecture
trend, not just a new cloud
service offer (aka FaaS)
❏ A serverless app is a mashup of
value-added, managed services:
aPaaS, xPaaS, FaaS…
❏ Fits today’s architecture stakes:
cloud native apps, 12 factors...
Serverless key aspects from Dev/App perspective
Schema from martinfowler.com
Devs gain a greater productivity, refocusing on business valuable code

Ops gets more efficiency and cost-saving, offloading
several concerns to platform
❏ You no longer manage infrastructure aspects directly: Auto-
scalability & resilience provided by design
❏ Close to NoOps
❏ Cloud promise at its finest “resolution”
On-demand, Elastic, Pay-Per-Use
Serverless key aspects from Ops/platform perspective

Focus on value & better TTM
but support platform constraints
More flexibility, more tuning
capacity… but assume plumbing
Functions
Serverless key aspects
ABSTRACT
FOCUSINFRA
Microservices
Monoliths
CaaS
IaaS
FaaS
& PaaS

❏ Microservices
❏ Stream processing
❏ IoT / Event-driven-programming
❏ Batch / Scheduled tasks
❏ May even replace some old compute grids ;)
Some usecases

Finally, THE silver bullet?
Highly valuable, but not THE definitive silver bullet

There are 2 kind of spurs my friend. Those that do
serverless, those that don’t.

ReX #1 - almost-CaaS avec Kubernetes
Retour d’expérience #1
almost-CaaS
avec Kubernetes

L’infogérance : grandeur et naufrage !
Problème :
Vous avez 40 minutes !

Modèle d’activité en 2015
Activité Dispositif
organisationnel
Fonction ITIL Eléments
facilitant
La promesse La réalité
MCO – Maintien
en condition
opérationnelle
de l’application
Horaire : 24/7
▪ équipe élargie
intervenant sur les
plateformes de
tous les clients
(100+)
▪ traitement sur
procédure
▪ ou analyse et
work-around
(rollback)
traitement des
événements et
incidents
augmentation de la
maîtrise par :
▪ standardisat° des
plateformes (rebuild
ou audit)
▪ automatisation des
procédures
▪ GTI – Temps garanti
d’intervention
(30’ – 1h)
▪ GTR – Temps
garanti de
rétablissement
(1 – 3h)
▪ peu de maîtrise du
contexte client
▪ pertinence des
procédures
▪ maîtrise relative
▪ context-switching
▪ implication faible
GCC –
Gestion
continue des
changements
liés au projet
client
Horaire : 8/5
▪ équipe restreinte
et dédiée aux
plateformes de
quelques clients
▪ mode micro-projet
▪ déclenchement
par ticket ou lors
des CoPil/ComOp
▪ résolution des
problèmes
▪ application des
changements
augmentation de la
productivité par :
▪ standardisat° des
plateformes
▪ expertise des
équipes
▪ automatisation des
actions
▪ accompagnement du
projet dans le design
et l’implémentation
de son architecture
technique
▪ KPIs ?
▪ priorisation et
allocation de
ressource au coup par
coup (délai)
▪ intervention fire-and-
forget
▪ participation
épisodique au projet
▪ catalogue
technologique limité

Etat des lieux en 2015
CONTRAINTES TECHNIQUES
▪ choix d’infrastructure restreint
▪ choix d’architecture technique contraint
▪ partage des outils de déploiement
▪ partage des secrets
CONTRAINTES ORGANISATIONNELLES
▪ concurrence pour la disponibilité des ressources
▪ intégrer des équipes tierces dans le design d’architecture
▪ interlocuteurs multiples sur la gestion des incidents
▪ organisation à 2 vitesses entre le build et le run
INCOMPRÉHENSION DU MODÈLE
▪ zones de responsabilité et de forfait flous
Server
Hypervisor
VM
OS
Libs
Middle
ware
conf.
Apps
Kernel
HDW
conf.conf.
Storage
Network
Logs/Metrology/Backups
Data
Build
build
Run
GCC
GCC
GCC
GCC
build
GCC?
APP
APP
APP
APP
APP
APP
APP

Server
Hypervisor
VM
OS
Libs
Middle
ware
conf.
Apps
Kernel
HDW
conf.conf.
Storage
Network
Data
Responsabilité contractuelle
Build
build
Run
GCC
GCC
GCC
GCC
build
GCC?
APP
APP
APP
APP
APP
APP
APP

Server
Hypervisor
VM
OS
Libs
Middle
ware
conf.
Apps
Kernel
HDW
conf.conf.
Storage
Network
Data
Responsabilité contractuelleRéalité opérationnelle
Build
build
Run
GCC
GCC
GCC
GCC
build
GCC?
APP
APP
APP
APP
APP
APP
APP

DevOps comme facilitateur
Solution :
Renverser le modèle

Renverser le modèle
OBJECTIFS
▪ ré-aligner les promesses et la réalité
opérationnelle
▪ augmenter la souplesse d’une prestation de
service
▪ rétablir la confiance et la collaboration
ELÉMENTS DU MODÈLES
▪ communication et proximité renforcées
▪ ouverture à des technologies hors-catalogue
▪ partage des outils, et des assets technologiques
▪ propriété du client renforcée
▪ collaboration sur du matériau commun
▪ automatisation maximale
▪ responsabilité partagée

Le DevOps comme solution
L’approche DevOps La démarche DevOps
C
A
L
M
S
Coût Temps
Qualité Satisfaction
the Beal-Hedemark
golden square
ulture
utomation
easurement
haring
ean

Partage des assets technologiques

S’inscrire dans un mode de projet continu

Tirer parti du modèle Cloud
On-premise Iaas Paas Caas
RESPONSABILITÉS
Repréciser la zone de
responsabilité de chaque
acteur… quitte à avoir des
zones de responsabilité
partagées.
▪ Cloud provider
▪ Infogérant
▪ Client
PROPRIÉTÉ
Les plateformes Cloud sont en
propriété du client.
Potentielle délégation de
gouvernance.
Hypervisor
VM
OS
Libs
conf.
Kernel
HDW
Middleware
conf.
Apps
conf.
Server Storage
Network
Logs / Metrology / Backups
Data
Runtime
conf.
Container
conf.

Tirer parti de l’héritage des images Docker
Dev team
Ops team
Container
Apps
Middle
wares
Libs
OS
conf.conf.conf.con
f.
Container
Libs
OS
conf.conf.
Image
Container
Middle
wares
conf.
Container
Apps
conf.
ImageImage
☹️ Not
prod-ready
Container
Apps
conf.
😀
prod-
ready
😀
Prod
ready Image
😀
Prod
ready

Serverless or not?
Serverless or not?
Managed infrastructure
and services
Usage ✅
Cost ⛅
▪ Infrastructure is fully managed
▪ K8S primitives empower user enough to provision
resources (volume claim, ingress)
▪ services are fully managed
▪ Runtimes are partially managed since they are included in
application docker images
Abstraction of any
server notion
Usage ✅
Cost ❌
▪ On a developper perspective, YES
▪ Self-healing and auto-scaling
▪ But on a cost perspective, he still pays for servers
Cost scales to 0 Cost ❌ ▪ On a developper perspective, YES
Fast provisionning Usage ✅
▪ Booting up a K8S pod depends on what the Docker image
is containing. Most of the time < 10 sec.

ReX #2 - le PaaS de Clever Cloud
le PaaS de Clever Cloud
You write code - We Run IT

Promise:
git push and it works!
PaaS for developers

PaaS for developers
PaaS promise
▪ git push and it works!
▪ Production grade!
▪ No-OPS!
▪ Limited catalog
▪ Opinionated way
of running apps
▪ No vendor lock-in
DEV OPS

PaaS for developers
PaaS promise
▪ git push and it works!
▪ Production grade!
▪ No-OPS!
Using a PaaS:
▪ Choose a runtime
+ build tool
▪ Write your app. code
▪ Add git remote branch
▪ Push to remote
▪ You are in production!
DEVELOPER ACTIVITY
PLATFORM ACTIVITY

Git push and it works!
PaaS for developers

Shift from machine to application
BASIC DEPLOYMENT UNIT
from Machine to Application

Production grade!
Production grade
▪ Provisionning on-demand
▪ Immutable architecture
▪ No interruption of service
▪ Security
▪ Automatic scalability
▪ Monitoring and logs
▪ No-OPS!

Under the hood:
Ops and IT automation
PaaS - the Ops side

Provisionning on-demand
▪ CLI, Web console, API
▪ Runtime and add-ons catalog
▪ Dynamically configured reverse-proxies & DNS
▪ Self-healing and autoscaling
PaaS - under the hood
CLI
WebUI
API Message
broker
Deployment
scheduler
Dev
hipster
Reverse-proxies
Hypervisors VMs
Message
broker
VM images
catalog
Monitoring
& logging

Immutable infrastructure
▪ Preset KVM optimized and secured images
■ maintained on our own
■ copy-on-write -> VM boots in 7 sec
▪ Linux Exherbo distribution
■ maintained on our own
■ source-based
■ upstream
■ to be more reactive and efficient against security threats
▪ Application build on-site from source code
▪ Alerting users on old instances to make them redeploy
▪ Details here: https://www.youtube.com/watch?v=CeaoTAXkIZE
CLIPaaS
Ops
VM images
catalog
Hypervisors VMs
Building
binaries

Application deployment
▪ Application build on-site from source code
▪ Automated build
■ introspect source code
to determine build tool needed
■ keep build cache
for autoscaling purpose
CLI
Hypervisors VMs
Building
binaries
Dev
hipster
App
deployer

Blue/Green deployment
Blue/green
deployment
▪ No interruption of service
▪ Auto-restart when crashed
▪ Shadow upgrade
▪ Dynamic scalability

Serverless or not?
Serverless or not?
Managed infrastructure
and services
Usage ✅
Cost ⛅
▪ Infrastructure is fully managed
▪ User cannot claim any specific infrastructure resource BUT
use available add-ons
▪ services are fully managed
▪ Runtimes are fully managed
Abstraction of any
server notion
Usage ✅
Cost ❌
▪ On a developper perspective, YES
▪ Self-healing and auto-scaling
▪ But on a cost perspective, he still pays for servers
Cost scales to 0 Cost ⛅ ▪ Auto-scaling can get cost very low, but still not 0 yet
Fast provisionning Usage ✅ ▪ Booting up an app is around 7 sec after the first build

ReX #3 - le FaaS
FaaS, la nouvelle
coqueluche du marché

On-Premise
Serverless Functions made simple for Docker and
Kubernetes

Highlights
- Ease of use through UI portal and one-click install
- Write functions in any language for Linux or Windows and
package in Docker/OCI image format
- Portable - runs on existing hardware or public/private cloud -
Kubernetes and Docker Swarm native
- CLI available with YAML format for templating and defining
functions
- Auto-scales as demand increases

OpenFaaS
- You can chain functions on client-side
- You can combine functions inside code
- You can call functions asynchronously
- You can deploy not only HTTP functions
- Trigger functions on AMQP or even Kafka
- There is a CRD to enable functions deployment from kubectl

Demo
faas-cli build -f myfn.yml
faas-cli push -f myfn.yml
faas-cli deploy -f myfn.yml

Reporting : monitoring performance
OpenFaaS :
- Prometheus + Grafana

CI/CD workflow
OpenFaaS :
- Use your favorite tool
- Git
- Jenkins
- Nexus
- Sonarqube
- Spinnaker
- Use SaaS tooling : TravisCI, CircleCI, DockerHub, …
- Use OpenFaaS cloud

Versioning
OpenFaaS :
- Leverage on Docker
- Tag version on docker images

Canary release
OpenFaaS :
- Use traffic shaping w/ Istio

Blue/Green
OpenFaaS :
- Use traffic shaping w/ Istio

Telemetry : distributed tracing
OpenFaaS :
- Opentracing
- Implementations :
- Jaeger (Uber)
- Zipkin

Public offers
AWS :
- Compute : AWS Lambda
- API Proxy : Amazon API Gateway
- Storage : Amazon S3
- Datastore : Amazon DynamoDB
- Messaging : Amazon SNS & SQS
- Orchestration : AWS Step Functions
- Analytics : Amazon Kinesis & Athena

Public offers
Azure :
- Compute : Azure functions
- API Proxy : Azure API Management
- Storage : Azure Storage
- Datastore : Azure CosmosDB
- Messaging : Azure ServiceBus
- Orchestration : Azure Durable functions
- Analytics : Azure Log Analytics

Azure Durable functions
Chain functions
Fan-in / Fan-out

Azure Durable functions
Async functions
Human interaction

CI/CD workflow
Code
Build / Unit testing
Development
Integration tests
Staging
Acceptance tests
Production
Continuous Integration
Continuous Delivery
Continuous Deployment

CI/CD workflow
AWS :
- AWS CodeCommit
- AWS CodeBuild
- AWS CodeDeploy
- AWS CodePipeline

CI/CD workflow
Azure :
- Microsoft VSTS

Testing
const db = require('db').connect();
const mailer = require('mailer');
module.exports.saveUser = (event, context, callback) => {
const user = {
email: event.email,
created_at: Date.now()
}
db.saveUser(user, function (err) {
if (err) {
callback(err);
} else {
mailer.sendWelcomeEmail(event.email);
callback();
}
});
};

Testing
const db = require('db').connect();
const mailer = require('mailer');
const Users = require('users');
let users = new Users(db, mailer);
module.exports.saveUser = (event, context, callback) => {
users.save(event.email, callback);
};
class Users {
constructor(db, mailer) {
this.db = db;
this.mailer = mailer;
}
save(email, callback) {
const user = {
email: email,
created_at: Date.now()
}
this.db.saveUser(user, function (err) {
if (err) {
callback(err);
} else {
this.mailer.sendWelcomeEmail(email);
callback();
}
});
}
}
module.exports = Users;

Azure :
- Azure Monitor

AWS :
- Amazon Cloudwatch

Azure :
- Azure AppInsight

AWS :
- Amazon XRay

Versioning
Azure :
- Use proxies

Versioning
AWS :
- Publish new code
- Automatic versioning
- Immutable snapshot

Versioning
aws lambda create-function --region region --function-name helloworld --zip-file fileb://file-path/helloworld.zip --
role arn:aws:iam::account-id:role/lambda_basic_execution --handler helloworld.handler --runtime nodejs6.10 --
profile adminuser
aws lambda create-alias --region region --function-name helloworld --description "sample alias" --function-version
"$LATEST" --name DEV --profile adminuser
aws lambda publish-version --region region --function-name helloworld --profile adminuser
aws lambda create-alias --region region --function-name helloworld --description "sample alias" --function-version 1
--name BETA --profile adminuser
aws lambda create-alias --region region --function-name helloworld --description "sample alias" --function-version 1
--name PROD --profile adminuser
aws lambda publish-version --region region --function-name helloworld --profile adminuser
aws lambda update-alias --region region --function-name helloworld --function-version 2 --name BETA --profile
adminuser

Canary release
Azure :
- Not existent at the moment

Canary release
AWS :
- Use traffic shaping

Canary release
# Point alias to new version, weighted at 5% (original version at 95% of traffic)
aws lambda update-alias --function-name my-function --name my-alias routing-config
‘{“AdditionalVersionWeights” : {“2” : 0.05} }’

Blue/Green
Azure :
- Use slots

Blue/Green
AWS :
- Use traffic shaping (like canary release)
# Point alias to new version, weighted at 100%
aws lambda update-alias --function-name my-function --name my-alias routing-config
‘{“AdditionalVersionWeights” : {“2” : 1} }’

Resource dependencies
AWS :
- Use framework like Serverless or Claudia.js
- Use Terraform
- Use Cloudformation

# serverless.yml
service: usersCrud
provider: aws
functions:
resources: // CloudFormation template syntax
Resources:
usersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: usersTable
AttributeDefinitions:
- AttributeName: email
AttributeType: S
KeySchema:
- AttributeName: email
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1

Azure :
- Use Azure Resource Manager
- Use Terraform

OpenFaaS :
- Openservicebroker API

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: my-cosmosdb-binding
namespace: default
spec:
instanceRef:
name: my-cosmosdb-instance
secretName: my-cosmosdb-secret

Enfin, le mot de la fin
Enfin, le mot de la fin
Serverless & Beyond

Serverless & IoT
❏ IoT generates large loads of small & basic-to-process
events, in huge quantity
❏ It calls for an event-driven programming approach
❏ … which fits well with the idea of simple, elementary
functions of Serverless/FaaS computing
Serverless
+
IoT

Serverless & Edge Computing
❏ Google Trends graphs for “Serverless” & “Edge computing” terms
❏ Beware, scales are not the same ;)
❏ Anyway, an interesting correlation to notice, isn’t it ?

WTF with Edge computing?
❏ Offload computing tasks close to the
data, at the boarder of the network / out
from the cloud
❏ Example, precompute face recognition
close to a camera, to avoid uploading the
whole video flow to the cloud
❏ Particularly valuable in an IoT landscape
CLOUD

Major cloud vendors are building their strategy on top of the
following triptic, to unleash their service from the cloud
For instance: Azure IoT Edge / Sphere, AWS Greengrass...
Unleash from the cloud
Edge
Computing
Serverless
Architecture
Internet Of
Things

DevoxxFR 2017: Serverless architectures - 3 visions for serverless

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DevoxxFR 2017: Serverless architectures - 3 visions for serverless

Similar to DevoxxFR 2017: Serverless architectures - 3 visions for serverless (20)

More from Ludovic Piot

More from Ludovic Piot (13)

Recently uploaded

Recently uploaded (20)

DevoxxFR 2017: Serverless architectures - 3 visions for serverless