5 lignes de code... en Serverless

Le serverless : cette ""révolution"" qui promet des économies de coûts, une productivité accrue du personnel, une résilience opérationnelle et une agilité business. Dans cette session, nous allons explorer ces promesses à travers l'évolution d'un exemple concret de seulement 5 lignes de code. Nous partirons d'une base simple, qui illustre comment le serverless répond aux besoins initiaux avec brio. Puis, au fil du temps, des changements métier et des contraintes opérationnelles vont s'imposer, en impactant de près le code, l'architecture et toute l'organisation. Rendez-vous pour explorer le potentiel et les défis dans le monde fascinant du serverless.

Transcript

1. Duck Conf 2024 5 lignes de code… en Serverless
2. Wassel Alazhar Coding Architect Leader de la tribu Event Centric Architectures @wasselovski
3. Le menu À la poursuite des promesses du Serverless 1. Serverless : Quoi ? Pourquoi ? 2. Une histoire pour illustrer • On commence simple • On fait évoluer pour répondre des contraintes 3. Takeaways Tout le code, par ici 👆 Techniques Opérationnelles Business Organisationnelles
4. 10 ans de Serverless
5. Source : https://aws.amazon.com/fr/serverless « … Des technologies qui permettent d'exécuter le code, de gérer les données et d'intégrer les applications, le tout sans avoir à gérer les serveurs. Les technologies sans serveur offrent la scalabilité automatique, une haute disponibilité intégrée et un modèle de facturation à l'utilisation qui permettent d'augmenter l'agilité et d'optimiser les coûts. » Serverless… C’est quoi ?
6. « … Des technologies qui permettent d'exécuter le code, de gérer les données et d'intégrer les applications, le tout sans avoir à gérer les serveurs. Les technologies sans serveur offrent la scalabilité automatique, une haute disponibilité intégrée et un modèle de facturation à l'utilisation qui permettent d'augmenter l'agilité et d'optimiser les coûts. » Serverless… C’est quoi ? FAAS PAAS CAAS BAAS + Services managés Données Intégration Source : https://aws.amazon.com/fr/serverless
7. Source : Un architect barbu inconnu « … Des technologies qui permettent d'exécuter le code, de gérer les données et d'intégrer les applications, le tout sans avoir à gérer les serveurs. Les technologies sans serveur offrent la scalabilité automatique, une haute disponibilité intégrée et un modèle de facturation à l'utilisation qui permettent d'augmenter l'agilité et d'optimiser les coûts. » Serverless… C’est quoi ? Le Cloud sans se prendre la tête avec les VMs et Kubernetes
8. Promesses des plateformes Serverless • Cost Saving • Staff Productivity • Operational Resilience • Business Agility Source : https://aws.amazon.com/executive-insights/content/generating-business-value-with-aws-serverless
9. On n’a pas à se poser trop de questions…
10. On n’a pas à se poser trop de questions… Jusqu’à ce que
11. Paradoxe de Jevons À mesure que les améliorations technologiques augmentent l'efficacité avec laquelle une ressource est employée, la consommation totale de cette ressource peut augmenter au lieu de diminuer
12. 5 lignes de code
 … en Serverless Notre histoire commence ici
13. Un développeur enthousiaste Qui veut faire les choses bien Travaille pour une compagnie de réservation de chambres hotels
14. Un cloud provider moderne A un service pour tout
15. CHAPITRE 1 Un script déployé dans une « function »
16. Une « function » pour tout Vue d’ensemble Exemple avec Google Cloud
17. Une « function » pour tout Code d’Application Exemple en Python 1 2 3 4 5 Magie du Cloud provider
18. Une « function » pour tout Wardley Map
19. Une « function » pour tout Wardley Map *AAS Application Automation Serverless
20. Une « function » pour tout Code d’Automatisation Exemple en Pulumi écrit en Python 1 2
21. Une « function » pour tout Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility
22. Une « function » pour tout Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility Et ça marche tellement bien… qu’on livre de plus en plus de fonctionnalités
23. Une « function » pour tout Et ça marche bien, sans se poser trop de questions… Et ça marche tellement bien… qu’on livre de plus en plus de fonctionnalités … Jusqu’à ce qu’on n’arrive plus à livrer Taille limite de l’artefact déployé Cold start Framework imposé Gestion des connexions Db et back pressure Nombre limite d’exécutions parallèle dépassé Durée max d’exécution dépassée Taille mémoire max dépassée Latence
24. Une « function » pour tout L’étape d’après 1. Payer plus 2. Faire soi-même Cost Saving Staff Productivity Operational Resilience Business Agility
25. CHAPITRE 2 Du FAAS au PAAS (ou CAAS)
26. Fundamental theorem of software engineering We can solve any problem by introducing an extra level of indirection …except for the problem of too many levels of indirection.
27. Transaction Script
28. Une « function » pour tout Comment en sortir ? Framework open-source Framework du Cloud provider Le métier
29. Du FAAS au PAAS Code d’Application… On rajoute une couche Un « Transaction Script » portable Du code « jetable »
30. Un « transaction script » portable Vue d’ensemble
31. Un « transaction script » portable Code d’Application
32. Un « transaction script » portable Code d’Application… jetable Framework open-source Framework du Cloud provider Le métier
33. Un « transaction script » portable Code d’Application… On enlève une couche ! Le métier Framework open-source On jette la dépendance au Framework du Cloud Provider
34. Un « transaction script » portable Code d’Application… On maîtrise une couche Le métier Framework open-source On s’affranchit des contraintes du Framework du Cloud Provider
35. Un « transaction script » portable Code d’Automatisation… On rajoute une couche
36. Un « transaction script » portable Code d’Automatisation… On rajoute une couche
37. Un « transaction script » portable Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility
38. Un « transaction script » portable Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility Et ça marche tellement bien… qu’on fait de plus en plus de réservations !
39. Un « transaction script » portable Et ça marche bien, sans se poser trop de question… Et ça marche tellement bien… qu’on fait de plus en plus de réservations ! … Jusqu’à ce qu’on commence à en perdre Partial Failures Long Running Transaction
40. Un « transaction script » portable Ça marche tellement bien… Jusqu’à ce que - 💩 Le niveau de service de notre partenaire n’est pas satisfaisant - 🔐 On est coincé avec pendant un bout de temps - 💸 On perd du CA
41. Un « transaction script » portable L’étape d’après Cost Saving Staff Productivity Operational Resilience Business Agility Partial Failures Long Running Transaction
42. CHAPITRE 3 Intégration entre services As-A-Service
43. Fundamental theorem of software engineering We can solve any problem by introducing an extra level of indirection …except for the problem of too many levels of indirection.
44. Outbox pattern: Notifier après transaction
45. Notifier après transaction Vue d’ensemble
46. Notifier après transaction Une histoire de flèches Avant Après
47. Notifier après transaction Code d’Application
48. Notifier après transaction Vue d’ensemble - concrètement
49. Fundamental theorem of software engineering We can solve any problem by introducing an extra level of indirection …except for the problem of too many levels of indirection.
50. Notifier après transaction Vue d’ensemble - concrètement
51. Notifier après transaction Code d’Automatisation
52. Notifier après transaction Vue d’ensemble - concrètement… ailleurs Exemple avec AWS
53. Notifier après transaction Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility
54. Notifier après transaction Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility Et ça marche tellement bien… qu’on continue de rajouter des fonctionnalités
55. Notifier après transaction Et ça marche bien, sans se poser trop de questions… Et ça marche tellement bien… qu’on continue de rajouter des fonctionnalités … Jusqu’à ce qu’on y arrive plus Les règles de pricing se complexifient 
 et évoluent de plus en plus vite
56. Fundamental theorem of software engineering We can solve any problem by introducing an extra level of indirection …except for the problem of too many levels of indirection.
57. On sépare le pricing de la réservation !
58. CHAPITRE 4 Messaging As-A-Service
59. Event-Driven Consumer
60. Event-Driven Consumer Vue d’ensemble
61. Event-Driven Consumer Vue d’ensemble
62. Event-Driven Consumer Vue d’ensemble
63. Event-Driven Consumer Code d’Application
64. Event-Driven Consumer Code d’Automatisation - Booking
65. Event-Driven Consumer Code d’Automatisation - En dehors de Booking
66. Event-Driven Consumer Et ça marche bien, sans se poser trop de questions… • Cost Saving • Staff Productivity • Operational Resilience • Business Agility
67. Event-Driven Consumer Jusqu’à ce que… les règles changent L’activité de réservation a un impact sur la tarification proposée. La validation de pricing devient une transaction qui change l’état. Booking Pricing Dépend de Dépend de
68. CHAPITRE 5 Orchestration As-A-Service
69. Un Process Manager « Cloud Native » moderne
70. Un Process Manager « Cloud Native » Vue d’ensemble
71. Un Process Manager « Cloud Native » Vue d’ensemble
72. Un Process Manager « Cloud Native » Vue d’ensemble
73. Un Process Manager « Cloud Native » Code d’Application
74. Un Process Manager « Cloud Native » Code d’Automatisation
75. Un Process Manager « Cloud Native » Centralized Ownership
76. Un Process Manager « Cloud Native » Stream-aligned ownership Ownership du canal de publication ≠ Ownership d’administration du système de messagerie
77. Un Process Manager « Cloud Native » YAGNI Ownership du canal de publication ≠ Ownership d’administration du système de messagerie EN AVEZ-VOUS VRAIMENT BESOIN ?
78. Et nos développeurs vécurent heureux avec leur cloud providers et déployèrent beaucoup de fonctionnalités
79. … jusqu’à ce que Et nos développeurs vécurent heureux avec leur cloud providers et déployèrent beaucoup de fonctionnalités On change de cloud provider
80. Takeaways Une pléthore de services • Le Serverless baisse la barrière d’accès à certains types d’architectures (dont vous n’avez peut être pas besoin) • Il faut être prêt ! Les promesses se méritent • Le Serverless récompense le bon design : • Repenser les Responsabilités et Ownerships • Pouvoir changer de service • Le Serverless récompense le Continuous Delivery Le context reste roi • Partez de votre besoin • Le raisonnement avec le catalogue de services managés limite le choix des possibles et nous couple plus au cloud provider Simplicity is the ultimate sophistication • Introduire des abstractions est important pour maitriser la complexité • Enlever des abstractions est encore plus important