Ville de Copenhague — Image sans rapport a priori

This is Serverless 🗣

À crier comme "This is Sparta" 😃

On entend un peu tout et n'importe quoi autour de Serverless. Il y a principalement beaucoup d'incompréhension et clairement un effet de mode. On peut facilement trouver plusieurs définitions, floues et minimalistes.
Je vous propose une histoire courte, un tour d'horizon, pour que vous puissiez vous faire votre propre opinion.

Oui, mon nom s'est fait Ă©corcher. Mais je l'ai bien vĂ©cu 🙂

La semaine derniĂšre j'ai eu le plaisir d'ĂȘtre invitĂ© Ă  parler Ă  ServerlessCPH pour prĂ©senter notre approche du Serverless. La confĂ©rence est en fait une forme de prolongation sur une journĂ©e de MicroCPH (1 track sur 2 jours) qui est organisĂ©e depuis plusieurs annĂ©es. Et quitte Ă  voyager, autant partir plusieurs jours, profiter de la ville et enchainer les 3 jours de confĂ©rence 🎉

Les organisateurs ont rassemblé une belle LineUp et ont vraiment bien organisé le programme et les conférenciers se sont enchainé presque avec poésie. Je ne vais pas vous couvrir toute la conférence, mais seulement les points que j'ai envie d'en retenir.

#MicroCPH

Le premier speaker a été Michael Nygard qui nous a parlé de Couplage et de Découplage. 
Ce que j'ai surtout retenu, c'est qu'il faut combattre l'obsession de découpler les composants de l'architecture. C'est globalement ce que l'on fait quand on conçoit un module, un composant ou un service en généralisant son usage, parce qu'on va l'exposer à tout un ensemble d'autres composants qui n'est pas du tout spécifié.
Le dĂ©couplage ne peut pas ĂȘtre un style d'architecture Ă  lui tout seul. Si on conçoit tous les services pour qu'ils fonctionnent en ignorant les autres, on finit avec un ocĂ©an de micro-service, avec un terrain fantastique Ă  effet de bord. Chaque nouveau service est absorbĂ© par le systĂšme et s'y noie.

MatiÚre fortement découplée

Alors oui, c'est un manque de vision, mais surtout une absence de couplage.
Michael nous a ensuite présenté différents couplages dans l'ingénierie habituelle.

Scharfenberg coupler (HLD 5509)

Par exemple le Sharfenberg's Coupler (Attelage en français) qui a Ă©tĂ© dessinĂ© en 1903 et est toujours d'actualitĂ©. Au final, ce sont deux systĂšmes, eux-mĂȘme appendices de plus grands systĂšmes (les locomotives, voir la rame tout entiĂšre), qui vont s'assembler et permettre Ă  deux systĂšmes qui ne sont peut-ĂȘtre mĂȘme pas de la mĂȘme Ă©poque de fonctionner ensemble. Les locomotives, en particulier les ingĂ©nieurs qui les ont conçues, n'ont pas prĂ©vu que les deux systĂšmes fonctionnent ensemble. Ils sont parfaitement dĂ©couplĂ©s. Ce sont les deux Ă©lĂ©ments du couplage qui leur permettent de travailler ensemble.

Vous avez dĂ©jĂ  senti, dans la rame, la rĂ©sistance qui augmente quand les tiges s’imbriquent. Et d’un coup ça se relĂąche, les deux rames ont un certain degrĂ© de libertĂ©, elles ne sont plus en tension. Le coupleur dĂ©finit les bornes de cette libertĂ©, de cette articulation entre les deux systĂšmes. Bref, dans la conception de nos systĂšmes, il faut donner autant d'attention aux composants qui dĂ©couplent qu'Ă  ceux qui couplent. Le dĂ©couplage sans couplages bien conçus n'est qu'un paradis pour les effets de bords.


On a eu le bonheur ensuite d'entendre parler Jonas Bonér mais aussi Ben Stopford qui nous ont parlé d'architectures basées sur des évÚnements, de CQRS et de Kafka streams comme les habitués l'auront deviné.
Ce que j'en ai retenu, c'est un lĂącher-prise. Oui, ces systĂšmes ne sont pas dĂ©terministes. La consistance est une option. Le dĂ©couplage du bus d'Ă©vĂšnement signifie qu'Ă  l'extĂ©rieur du service ou du micro-service, les choses seront "Eventually Consistent". Ça peut faire un peu peur, on aime le contrĂŽle, mais au final, c'est une forme de compromis. On ne peut pas avoir la concurrence, la "scalabilitĂ©" et la consistance absolue.

Extrait des slides de Stefan Tilkov (SpeakerDeck)

J'ai Ă©galement vĂ©cu le talk de Stefan Tilkov comme une baffe. Les back-ends engineers ont bien dĂ©coupĂ© le monolithe JEE, ont fait de beaux micro-services, mais en fait le front-end est magnifique monolithe. Oui, parce qu'en fait, ce sont les "fronteux" qui s'en occupent. Pire, on a dĂ©placĂ© une grande partie des dĂ©cisions que prend le logiciel, de la "business logic" dans ces Ă©normes SPAs. Et la preuve c'est cette dĂ©pendance Ă  un Framework (👋 Angular.io ?).

Heureusement que @d_kubyshkin est venu offrir une solution.
Il nous a expliqué comment ils se sont organisés chez Zalando pour répartir la responsabilité des fragments du front-end en prenant appui sur Mosaic. Cela leur a permis de se libérer de la frontiÚre entre le front et le reste et construire de véritable features teams, responsables de parties entiÚres du workflow. (photos sur twitter).

Tout ça c'Ă©tait trĂšs sympa ! À chaque fois, les experts en Microservices parlaient de Serverless comme si c'Ă©tait la prochaine tendance Ă  surveiller. Se permettant mĂȘme de faire des vannes : "On verra bien comment ils feront quand ils auront 2000 fonctions en prod", "On a dĂ©coupĂ© le gros monolithe đŸ’© en plein de petits micro-services [đŸ’©,đŸ’©,đŸ’©,
], maintenant on re-dĂ©coupe les micro-services en fonctions : [[đŸ’©,đŸ’©,đŸ’©,
], [đŸ’©,đŸ’©,đŸ’©,
][đŸ’©,đŸ’©,đŸ’©,
], 
] : ProblĂšme rĂ©solu !"

Si vous n'avez jamais vu de fonctions, je vous propose la documentation des produits de GCP et Azure ou encore OpenFaaS.

#ServerlessCPH

Chez Truspilot, les ingés ont mis en place un chan slack pour name and shame chaque déploiement d'EC2

Le lendemain on est donc entré dans #ServerlessCPH. Quand j'ai commencé à voir des gens avec des Slides "EC2 GTFO", je me suis senti déjà plus dans ma zone de confort.

Avec globalement deux points de vue du sujet qui, au premier coup d'oeil s'opposent, mais au final se complÚtent énormément.

Serverless: more than just FaaS

Le premier est Ben Kehoe qui globalement explique que chez iRobot, ils font des robots mais c'est pas leur métier de gérer des backends etc.

Le serverless, c'est se concentrer sur le métier, sur le fait d'apporter de la valeur business et pas passer son temps à maintenir l'existant. C'est plus que du NoOps, on n'y pense pas du tout, tout juste à l'étape design pour évaluer les effets de bords.
C'est tout le réseau de services que vous pouvez utiliser. Par exemple, utiliser Algolia plutÎt que de l'Elasticsearch, c'est déjà du Serverless. Parce que c'est pas à nous de penser aux failovers, à la montée en charge. On définit les indexes, on se concentre sur l'expérience des utilisateurs. Pour le reste, ça tiens et c'est tout.
Et du coup, le vendor-locking n'est pas fondamentalement mal, s'il permet de se libérer du fardeau opérationnel.


L'autre cotĂ© de la mĂȘme piĂšce de monnaie c'Ă©tait le sujet de Austen Collins. C'est une personne qui aime le YAML et les CLIs, ce qui attire rapidement ma compassion en fait. Si Serverless parle de Multi-Cloud c'est surtout parce qu'il veut qu'on puisse tirer le meilleur de chaque plateforme. Il y a effectivement pas mal de confĂ©renciers qui sont sur AWS et voudraient pouvoir utiliser BigQuery, mais ne le font pas. 
Austen a mis le doigt sur le couplage, ce sont les "Triggers" ou les "Events" qui déclenchent les fonctions qui apportent le plus de valeur et viennent avec le vendor-locking. 
Nous par exemple, sur 98 fonctions en prod, on doit en avoir 80 qui sont déclenchées par des triggers propres au SDK Firebase, 3 ou 4 qui sont des Webhooks pour faire ETL depuis d'autres entreprises et le reste ce sont des Cron Jobs qui viennent d'un service externe via HTTP. 
Bref c'est le sujet qu'il aborde avec Event Gateway et CloudEvents.

C'est quoi notre vision de #Serverless ?

En résumé, voici l'histoire que je suis venu raconter à Copenhague. On a monté la boite à deux développeurs. On a pas décidé du jour au lendemain de faire du serverless ou des fonctions, ce n'est pas un choix d'architecture. C'était surtout que l'on savait que passer du temps à discuter avec les développeurs, à aller chercher des boites chouettes et à vendre le service, c'était super important. Et on a toujours tranché de façon à ne passe se charger avec de la maintenance. On a aussi toujours voulu garder la capacité à pouvoir déployer un PoC en production dans la journée.

Quand on nous a dit "Sepa, c'est facile, c'est juste un Cron qui fait du XML à coder", on a utilisé Stripe Subscriptions.

Pour les fichiers on a intĂ©grĂ© Filestack dĂšs le dĂ©but. Twilio, Algolia, etc
 C'est ce que Yann IRBAH appelait "Web as a Framework" avant que Serverless soit cool. 
Et les fonctions sont venues plus tard.

Ce que l'on ne veut plus faire c'est du jobbing avec un systĂšme comme Resque que j'ai adorĂ© Ă  l'Ă©poque oĂč je faisais du Rails (Rails 3 tbh). On a mĂȘme refait un peu la mĂȘme chose sur notre node en utilisant Bee-queue contre un Redis. En fait, les workers forment Ă  eux seuls un monolithe. Et quand tu rajoutes un job, si celui-ci plante, il impacte tous les autres, c'est un joyeux dawa.

Je ne referai plus des Clients-Serveur oĂč le Client commande un job au serveur web qui le cache dans un Redis. 
La SPA est un composant comme les autres et elle utilise un eventbus ou autre pour émettre un évÚnement sans rien attendre en retour. Et le découplage se situe directement à ce niveau. Pas juste derriÚre une API.
Notre SPA ne "Commande" jamais une fonction.

Les fonctions sont venues par praticité. Je voulais rajouter une feature un peu gadget et je voulais pas mettre le dawa sur les workers et du coup je l'ai poussée sur une fonction. Au fur et à mesure on a continué a réécrire les fonctionnalités des workers node vers des fonctions.
Un jour on a eu une fonction qui a mis 25 minutes pour complĂ©ter le job et ça n'a eu aucun impact sur le systĂšme. D'habitude c'est grave, parce que le serveur web se prend un requĂȘte bloquante pendant 25 minutes et ça peut impacter de vĂ©ritables utilisateurs qui demandent juste Ă  avoir la SPA par exemple. Mais lĂ  non, c'est pas grave, parce que les fonctions sont parfaitement isolĂ©es.

Ces fonctions sont conçue de maniÚre trÚs "jetable". Elle sont le plus souvent conçues pour fonctionner spécifiquement avec un service externe (algolia, twilio, pipedrive, sendgrid) et assurent le couplage entre notre systÚme et le systÚme externe.

Par contre, notre serveur web est toujours chez Clever. Il est toujours conçu pour ĂȘtre requĂȘtĂ© par n'importe quel service externe (browser, scrapper) et il est toujours conçu de cette maniĂšre, dĂ©couplĂ© par design, et ne rĂ©duit pas le scope de ses consommateurs. C'est en soit un Microservice et pas une fonction et ça Ă  du sens.

Il y a aussi une notion d'Ă©chelle. On conçoit des systĂšmes pour qu'ils soient capable de prendre des charges Ă©normes alors qu'on en a rarement besoin. "Oui, on est une grosse entreprise avec des milliers de clients, il faut que vous soyez prĂȘt" =>rĂ©sultat une fois en prod : 2 appels par semaine, heureusement qu'on a mis une fonction ! Un kafka nous aurait coutĂ© une fortune !
Par contre, si on passe sur M6, notre serveur web va ĂȘtre chargĂ© et Clever va savoir gĂ©rer la solution.

Je parle de notre expérience avec tous ces sujets, et notamment des Do and Don't. Vous pouvez retrouver les slides ci-dessous.

Pour résumer

LĂ  oĂč il y a couplage, les fonctions c'est bien. On les conçoit pour un usage hyper-spĂ©cifique et bornĂ©. Si on conçoit le composant par aspect, il vaut mieux que ce soit une forme de Micro-service, conçu pour ĂȘtre utilisĂ© par un maximum de "clients". A priori, d'aprĂšs moi ce sont deux cas d'usage totalement diffĂ©rents. Si le cold-start de la fonction peut avoir un impact sur l'expĂ©rience des utilisateurs, alors c'Ă©tait une mauvaise idĂ©e.

Et le #serverless, d'aprĂšs moi, ce n'est pas juste des fonctions et bien plus que du NoOps.

La conversation continue !

AprÚs, je n'ai définitivement pas la science infuse et je suis content que le débat reste ouvert. Je serais content d'échanger avec vous sur ces sujets, que ce soit en AFK (on se voit au Web2Day ou à TakeOff Conf?) ou ici dans la section commentaire de cet article.

💙

Like what you read? Give Damien CavaillĂšs a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.