(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience

#breizhcamp
2 ans (et + !) de retourS d’expérience
#serverless
Adrien Blind, Laurent Doguin,
Laurent Grangeau, Ludovic Piot

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
− FaaS, la nouvelle coqueluche du marché

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

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

What do you really want?
On demand
Pay as you go
ElasticCloud
Agile
DevOps
Microservice
architecture
Deliver rapidely and flowly
valuable apps for the business

A new “cloudy” kid on the block!

“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)
A single definition for Serverless?

❏ 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 20 ms
Pay-as-you-go → Scale to zero
What are we talking about?

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

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

Cloud: CaaS
❏ 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

❏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,
CosmosDB, etc.)

❏ 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
FaaS
platform
FaaS compute capacity abstracted from dev perspective
Cloud: FaaS
Client
Instanciated
function
(your code)
Instanciated
function
(your code)
Instanciated
function
(your code)
Gateway

❏ 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 framework
You may leverage on existing CaaS and put value on top of it
• Container encapsulation of the function
• Kubernetes orchestration
Cloud: FaaS

Serverless key aspects -dev/app perspective
❏ 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...
Devs gain a greater productivity, refocusing on business valuable code

Serverless key aspects -ops/ptf perspective
❏ 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
Ops gets more efficiency and cost-saving, offloading several concerns
to platform

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

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

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

L’infogérance : grandeur et naufrage !

Modèle d’activité historique
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 historique
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

Etat des lieux en 2015
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

Etat des lieux en 2015
Server
Hypervisor
VM
OS
Libs
Middle
ware
conf.
Apps
Kernel
HDW
conf.conf.
Storage
Network
Data
Responsabilité
contractuelle
Réalité
opérationnelle
Build
build
Run
GCC
GCC
GCC
GCC
build
GCC?
APP
APP
APP
APP
APP
APP
APP

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

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.conf
. Container
Libs
OS
conf.conf.
Image
Container
Middle
wares
conf.
Container
Apps
conf.
ImageImage
☹ Not
prod-ready
Container
Apps
conf. prod-r
eady
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

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

Shift from machine to application
BASIC DEPLOYMENT UNIT
from machine to application
Production grade
▪ Provisionning on-demand
▪ Immutable architecture
▪ No interruption of service
▪ Security
▪ Automatic scalability
▪ Monitoring and logs
▪ No-OPS!

PaaS - under the hood
Provisionning on-demand
▪ CLI, Web console, API
▪ Runtime and add-ons catalog
▪ Dynamically configured reverse-proxies & DNS
▪ Self-healing and autoscaling
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 pattern
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é

Public offers
AWS Azure
Compute AWS Lambda Azure functions
API proxy Amazon API Gateway Azure API Management
Storage Amazon S3 Azure Storage
Data store Amazon DynamoDB Azure CosmosDB
Messaging Amazon SNS & SQS Azure ServiceBus
Orchestration AWS Step Functions Azure Durable functions

On-Premise
Serverless Functions made simple
for Docker and Kubernetes

OpenFaaS highlights
❏ Ease of use through UI portal and one-click install
helm upgrade --install rivieradev openfaas/ --namespace rivieradev -f values.yaml
❏ 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
faas-cli build | push | deploy -f myfn.yml
❏ Auto-scales as demand increases

OpenFaaS highlights
❏ 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
# callme.yaml
provider:
name: faas
gateway: http://gateway-devoxx.laurentgrangeau.fr
functions:
callme:
lang: node
handler: ./callme
image: laurentgrangeau/callme
# package.json
{
"name": "function",
"version": "1.0.0",
"description": "",
"main": "handler.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
# handler.js
"use strict"
module.exports = (context, callback) => {
callback(undefined, {status: "done"});
}

Orchestration - AWS step functions

Orchestration - Azure durable functions

CI/CD workflow
Code
Build / Unit
testing
Development
Integration
tests
Staging
Acceptance
tests
Production
Continuous Integration
Continuous Delivery
Continuous Deployment
AWS Azure
CI/CD Workflow
AWS CodeCommit
AWS CodeBuild
AWS CodeDeploy
AWS CodePipeline
Microsoft VSTS
OpenFaas
Git, Gitlab, GitHub
Jenkins, Spinnaker,
Gitlab-CI, BitBucket Pipelines, TravisCI, CircleCI
Nexus, DockerHub, Sonarqube

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;

Reporting : monitoring performance
AWS Azure OpenFaaS
Analytics Amazon Kinesis
Amazon Athena
Azure Log
Analytics
Prometheus
Grafana
Performance
monitoring
Amazon
CloudWatch
Azure AppInsight

Telemetry : distributed tracing
AWS Azure OpenFaaS
Telemetry -
distributed
tracing
Amazon XRay Azure
AppInsight
Opentracing
Jaeger (Uber)
Zipkin

Telemetry : distributed tracing

Versioning
Azure :
- Use proxies

Versioning - AWS
AWS Azure OpenFaaS
Versionning AWS Lambda Azure function
proxy
Tag docker
image

Versioning - Azure
AWS Azure OpenFaaS
Versionning AWS Lambda Azure function
proxy
Tag docker
image

Canary release & blue/green deployment
# 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} }’
AWS Azure OpenFaaS
Canary release
Traffic shaping feature
in AWS Lambda
Nope
Istio traffic
shaping
Blue/green
deployment
Deployment
slots

Blue/Green
Azure :
- Use slots

Resource dependencies
# serverless.yml - Open Service Broker example
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: my-cosmosdb-binding
namespace: default
spec:
instanceRef:
name: my-cosmosdb-instance
secretName: my-cosmosdb-secret
# serverless.yml - AWS CloudFormation example
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
AWS Azure OpenFaaS
Resource
dependencies
Serverless or
Claudia.js frameworks
Terraform
Cloudformation
Azure Resource
Manager
Terraform
Open Service Broker
API

FaaS - the Clever Cloud way…
Function deployment
▪ Functions built on-site as WebAssembly binary
▪ Each function isolated into a VM
▪ VM have no OS but a lightweight WASM
“Bootloader”
■ the Unikernel way
CLI
Hypervisors VMs
Building WebAssembly
binaries
Dev
hipster
WASM function
+ bootloader”

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
It’s a
match!

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
EDGE

Unleash from the 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...
Edge
Computing
Serverless
Architecture
Internet Of
Things

(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience

More Related Content

What's hot

Similar to (RivieraDev 2018) #serverless - 2 ans de retourS d'expérience

More from Ludovic Piot

Recently uploaded

(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience