(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
•
0 likes•247 views
The document discusses serverless computing from multiple perspectives. It begins with definitions of serverless from different sources and perspectives. It then discusses key aspects of serverless architectures for developers and operations teams. For developers, serverless allows a focus on business logic while infrastructure concerns are handled by the platform. For operations, serverless provides automatic scaling and an on-demand/pay-per-use model. The document then shares experiences with different serverless platforms, including an almost-CaaS model using Kubernetes and a PaaS from Clever Cloud.
Report
Share
(RivieraDev 2018) #serverless - 2 ans de retourS d'expérience
- 1. #breizhcamp 2 ans (et + !) de retourS d’expérience #serverless Adrien Blind, Laurent Doguin, Laurent Grangeau, Ludovic Piot
- 2. 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é
- 3. 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
- 4. Introduction - la notion de Serverless Introduction la notion de Serverless, vaste débat !
- 5. Are you a server hugger?
- 6. 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
- 7. A new kid on the block?
- 8. A new “cloudy” kid on the block!
- 9. “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?
- 10. ❏ 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?
- 11. ❏ BaaS, aka Backend-as-a-Service ❏ FaaS, aka Functions-as-a-Service 2 major serverless tendencies
- 12. 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.)
- 13. 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
- 14. ❏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.)
- 15. ❏ 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
- 16. ❏ 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
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. Some usecases ❏ Microservices ❏ Stream processing ❏ IoT / Event-driven-programming ❏ Batch / Scheduled tasks ❏ May even replace some old compute grids ;)
- 22. ReX #1 - almost-CaaS avec Kubernetes Retour d’expérience #1 almost-CaaS avec Kubernetes
- 23. L’infogérance : grandeur et naufrage !
- 24. 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é
- 25. 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
- 26. 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 Responsabilité contractuelle Build build Run GCC GCC GCC GCC build GCC? APP APP APP APP APP APP APP
- 27. 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 Responsabilité contractuelle Réalité opérationnelle Build build Run GCC GCC GCC GCC build GCC? APP APP APP APP APP APP APP
- 28. 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
- 29. 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.
- 30. 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
- 31. 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.
- 32. ReX #2 - le PaaS de Clever Cloud Retour d’expérience #2 le PaaS de Clever Cloud You write code - We Run IT
- 33. PaaS Players
- 34. 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
- 35. 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
- 36. Git push and it works!
- 37. 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!
- 38. 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
- 39. PaaS - under the hood 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
- 40. PaaS - under the hood 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
- 41. Blue/green deployment pattern Blue/green deployment ▪ No interruption of service ▪ Auto-restart when crashed ▪ Shadow upgrade ▪ Dynamic scalability
- 42. Will IT Scale?
- 43. 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
- 44. ReX #3 - le FaaS Retour d’expérience #3 FaaS, la nouvelle coqueluche du marché
- 45. 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
- 46. On-Premise Serverless Functions made simple for Docker and Kubernetes
- 47. On-Premise
- 48. 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
- 49. 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"}); }
- 50. Orchestration - AWS step functions
- 51. Orchestration - Azure durable functions
- 52. 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
- 53. 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(); } }); };
- 54. 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;
- 55. Reporting : monitoring performance AWS Azure OpenFaaS Analytics Amazon Kinesis Amazon Athena Azure Log Analytics Prometheus Grafana Performance monitoring Amazon CloudWatch Azure AppInsight
- 56. Reporting : monitoring performance AWS Azure OpenFaaS Analytics Amazon Kinesis Amazon Athena Azure Log Analytics Prometheus Grafana Performance monitoring Amazon CloudWatch Azure AppInsight
- 57. Telemetry : distributed tracing AWS Azure OpenFaaS Telemetry - distributed tracing Amazon XRay Azure AppInsight Opentracing Jaeger (Uber) Zipkin
- 58. Telemetry : distributed tracing
- 59. Istio
- 60. Versioning Azure : - Use proxies
- 61. Versioning - AWS AWS Azure OpenFaaS Versionning AWS Lambda Azure function proxy Tag docker image
- 62. Versioning - Azure AWS Azure OpenFaaS Versionning AWS Lambda Azure function proxy Tag docker image
- 63. 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
- 64. Blue/Green Azure : - Use slots
- 65. Blue/Green
- 66. Blue/Green
- 67. Blue/Green
- 68. 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
- 69. 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”
- 70. Enfin, le mot de la fin ! Enfin, le mot de la fin ! Serverless & beyond!
- 71. 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!
- 72. 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 ?
- 73. 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
- 74. 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
- 75. Questions ?
- 76. ROTI