Si vous passez suffisamment de temps dans le secteur des technologies de l‘information, vous commencerez à reconnaître les cycles de conversation. Une nouvelle solution est proposée, tout le monde est enthousiaste ; quelqu‘un fait remarquer que la nouvelle solution ne peut pas encore tout faire, tout le monde est désillusionné ; les gens déterminent ce à quoi la nouvelle solution sert - et ce à quoi elle ne sert pas - et l‘argument passe à la nouvelle solution suivante.
En ce moment, dans le baril, nous avons des architectures sans serveur.
L‘instigateur de l‘actuelle vague de critiques sur le serverless est David Heinemeier Hansson, mieux connu sous le nom de DHH, de Basecamp. DHH a publié une polémique intitulée Même Amazon n‘arrive pas à comprendre le serverless ou les microservicesdans laquelle il cite une étude de cas réalisée par l‘équipe d‘Amazon Prime Video sur son infrastructure.
Le rapport détaille les aspects internes du service Prime Video. DHH cite un passage sur les limites strictes de la mise à l‘échelle, mais c‘est cette note qui m‘a le plus éclairé :
Les deux opérations les plus coûteuses en termes de coûts étaient le flux de travail d‘orchestration et le transfert de données entre les composants distribués. Pour y remédier, nous avons regroupé tous les composants dans un seul processus afin de maintenir le transfert de données dans la mémoire du processus, ce qui a également simplifié la logique d‘orchestration.
DHH
Voici le problème : comme l‘a souligné Adrian Cockroft (de Netflix), rien dans le rapport original ne remettait en question le modèle sans serveur. Tout ce que l‘équipe d‘Amazon a dit, c‘est que le service et sa compréhension avaient mûri et que leurs besoins avaient changé :
Lorsque l‘on cherche à savoir comment construire quelque chose, la construction d‘un prototype en quelques jours ou semaines est une bonne approche. Ils ont ensuite essayé de le mettre à l‘échelle pour faire face à un trafic élevé et ont découvert que certaines transitions d‘état dans leurs fonctions d‘étape étaient trop fréquentes, et qu‘ils avaient des appels trop bavards entre les fonctions lambda AWS et S3. Ils ont pu réutiliser la majeure partie de leur code de travail en le combinant en un seul microservice de longue durée [...]
Adrian Cockroft
Lorsque vous commencez à créer un nouveau service, vous ne connaissez pas, par définition, ses caractéristiques de performance internes ni les modèles de charge auxquels les utilisateurs le soumettront. C‘est donc une bonne idée de pécher par excès de prudence et de flexibilité. C‘était après tout la promesse initiale du site cloud, qu‘il a clairement tenue. Alors qu‘à l‘époque du boom des dot-com, les startups prometteuses devaient dépenser des millions de dollars en capital d‘investissement pour acheter du matériel serveur, des licences logicielles, de l‘espace colo, etc. avant de pouvoir réellement commencer à développer le service qu‘elles proposaient, à l‘ère du cloud , il est possible de démarrer avec une carte de crédit. La mise en place de l‘infrastructure, qui prenait des semaines ou des mois et nécessitait l‘intervention d‘experts travaillant 24 heures sur 24, se fait désormais automatiquement en quelques minutes.
Le sans serveur est simplement la prochaine étape de cette évolution. Cloud est beaucoup plus flexible que de posséder son propre matériel, mais son modèle de tarification traditionnel reste rigide, exigeant que les utilisateurs évaluent leurs besoins dès le départ, et la mise à l‘échelle peut ne pas être aussi réactive ou granulaire que vous le souhaiteriez. Si votre fournisseur ne propose qu‘une taille de t-shirt, et que vous vous situez entre une petite et une moyenne taille, mais que vous pourriez avoir besoin d‘une grande taille si les choses se passent bien, vous risquez de vous retrouver face à des décisions difficiles à prendre. La technologie sans serveur promet au contraire de permettre à votre service d‘évoluer de zéro à la taille qu‘il doit atteindre, et vous permet de payer au fur et à mesure.
C‘est ici qu‘interviennent les mises en garde : beaucoup de choses qui prétendent être sans serveur... ne le sont pas. Le véritable serverless s‘étend jusqu‘à zéro: si personne n‘utilise votre service, vous ne payez rien. C‘est une garantie importante lorsque vous lancez un nouveau service : si les utilisateurs ne sont pas encore sur votre service, vous n‘avez pas de revenus, donc savoir que vos coûts seraient également nuls dans ce scénario vous donne une certaine tranquillité d‘esprit que vous n‘allez pas être sur le crochet pour une tonne de capacité que vous n‘utilisez pas.
Le revers de la médaille est que la nature purement basée sur la consommation de la tarification sans serveur s‘étend à l‘infini - et il y a donc un point de passage où il est plus logique de s‘engager sur une quantité définie de capacité plutôt que de continuer sur le modèle de paiement à l‘utilisation. Cette flexibilité financière s‘accompagne également d‘une complexité architecturale, ce qui permet également de déterminer où se situera le point de passage pour chaque architecture de service.
C‘est ce qui est arrivé à l‘équipe d‘Amazon Prime Video : elle a atteint ce point de passage et a constaté qu‘elle n‘avait plus besoin de payer le coût de cette flexibilité extrême. Étant donné qu‘elle se trouvait à l‘intérieur d‘Amazon, il n‘y avait probablement pas de coût direct de la même manière que pour un client AWS externe, bien que l‘on puisse supposer qu‘Amazon comptabilise cette capacité de manière assez granulaire. Toutefois, ce que l‘équipe décrit dans son rapport, c‘est le coût pour elle en termes de complexité architecturale et de performance du service. Ayant pris le temps de comprendre les besoins spécifiques de leur service, ils n‘ont plus besoin de payer ce tribut : ils ont simplifié leur architecture et obtenu de meilleures performances en câblant les voies spécifiques dont ils avaient besoin.
Ce qu‘il faut retenir, cependant, c‘est que nous sommes à la fin du processus. Si les architectes d‘Amazon Prime Video avaient dû travailler sans la flexibilité d‘une architecture distribuée, ils n‘en seraient peut-être jamais arrivés là. Au contraire, ils ont pu lancer leur service rapidement, l‘affiner rapidement en réponse à l‘évolution des modèles d‘utilisation et, maintenant que le rythme des changements s‘est stabilisé à un niveau gérable, ils ont revu leurs exigences architecturales à la lumière de l‘expertise qu‘ils ont durement acquise.
C‘est ainsi que les choses devraient être faites. Cette histoire n‘est pas un échec du serverless ; c‘est littéralement sa raison d‘être !
SnapLogic permet quelque chose de très similaire, avec une touche supplémentaire : vous pouvez connecter n‘importe quoi à n‘importe quoi, et tout le monde peut s‘impliquer. Les experts du domaine peuvent tirer parti de notre interface graphique à code bas/non-code pour concevoir des intégrations de données et d‘applications sans avoir besoin de connaissances en programmation. Si cette intégration prend de l‘ampleur et devient populaire, elle peut être remaniée par des experts pour supprimer les goulets d‘étranglement au niveau des performances, éviter les doublons et garantir la conformité. Il s‘agit là d‘un objectif ambitieux pour un projet qui en est à ses débuts, alors qu‘il s‘agit avant tout de permettre aux gens de se lancer et de créer les fonctionnalités dont ils ont besoin.
Sur ce point, SnapLogic peut également s‘intégrer à toutes sortes de services sans serveur et les assembler en un tout unifié. Notre approche commerciale et technologique consiste à travailler avec les architectures de nos utilisateurs, et non à imposer ou à contraindre leurs choix. C‘est pourquoi nous travaillons à la fois avec des infrastructures sur site et cloud , qu‘elles soient autogérées ou fournies en tant que service - ou en fait, entièrement sans serveur pour une flexibilité maximale.
L‘avantage pour l‘entreprise des architectures sans serveur et du développement low-code/no-code est la facilité à faire décoller un nouveau projet. Si vous surindexez la pureté architecturale dans les premières étapes, vous ne parviendrez jamais à faire quoi que ce soit. À l‘inverse, une fois que vous avez une bonne idée de ce que vous devez faire, vous devez absolument redoubler d‘efforts et intégrer ce que vous avez appris. Amazon semble bien s‘en sortir sur cette base. Nous devrions tous nous inspirer de leur exemple.
