Quand et comment utiliser l'architecture serverless

Les entreprises sont-elles prêtes pour le serverless ? C’est clairement une tendance à la hausse. Pour autant, cela ne veut pas dire que ce type d’architecture fonctionne de façon idéale pour tous les scénarios ou dans toutes les organisations. Le mode serverless est un modèle d’architecture logicielle dans lequel un fournisseur de services cloud fait tourner le serveur pour le compte de son client et gère dynamiquement l’allocation des ressources de traitement. Le terme « serverless » (littéralement : sans serveur) est donc inapproprié puisque des serveurs sont bel et bien mis en oeuvre dans le processus. La tarification pour ce type de services est basé sur la quantité réelle de ressources consommées par une application plutôt que sur une capacité d’unités pré-payées.

Le marché de l’architecture serverless a été estimé à 4,25 milliards de dollars pour l'année 2018 et devrait atteindre 14,93 milliards de dollars d’ici 2023, en progressant à un taux annuel composé de 29%, selon un rapport publié en août 2018 par le cabinet d’études Markets and Markets. L’Amérique du Nord représentera la part la plus important du marché, notamment en raison de son adoption précoce des services cloud. Le fait de ne plus avoir à gérer les serveurs dans l’entreprise - réduisant de ce fait les coûts d’infrastructure et simplifiant le déploiement et l’exécution - comptera parmi les principaux facteurs de croissance. La prolifération des architectures de micro-services en est un autre. Les services d’automatisation et d’intégration jouent un rôle majeur dans le déploiement de l’architecture serverless, selon Markets and Markets. Les premiers aident à gérer efficacement les micro-services - déployés sur des plateformes IT hybrides - pour fournir des réponses plus rapides tout en optimisant l’utilisation des ressources informatiques. Gartner est lui aussi optimiste sur les perspectives de ce modèle. Le cabinet d’études l’inclut dans ses 10 tendances qui vont impacter l’infrastructure et les opérations en 2019 et estime que ce modèle d’architecture logicielle émergent apporte la promesse d’éliminer la nécessité de devoir provisionner et gérer l’infrastructure.

Accélérer le cycle de vie du développement logiciel

Le serverless a un fort pouvoir d’attraction, pas seulement sur les développeurs d’applications, mais aussi sur les équipes chargées des opérations, pointe Ken Corless, consultant spécialisé sur les pratiques cloud chez Deloitte Consulting. Qu’il soit proposé par des fournisseurs de services cloud hyperscale ou mis en oeuvre sur site avec différentes solutions disponibles sur le marché, l’objectif de l’informatique serverless est le même : « automatiser et mettre en self-service de façon radicale pour accélérer le cycle de vie du développement de logiciel », rappelle Ken Corless. Pour les administrateurs IT, le serverless réduite le cycle « requête-réponse » basé sur les charges de travail basées sur des tickets et il leur permet de se concentrer sur des tâches de plus haut niveau telles que la conception d’infrastructure ou la création d’autres automatisation, explique le consultant.

Les administrateurs systèmes fournissent un autre cas d’usage important. « La véritable automatisation qu’ils recherchent peut être mise en oeuvre rapidement, facilement et de façon incrémentale avec les technologies serverless », ajoute le consultant. Par exemple, dans l’activité Cloud Managed Services de Deloitte, la société de conseil utilise largement le serverless pour automatiser le fonctionnement de l’offre. Mais de la même façon qu’avec les services cloud, il y a toutefois des scénarios où le serverless peut coûter plus cher que la mise en route de machines virtuelles, expose Ken Corless. Une application qui s’exécute actuellement sur des machines virtuelles avec un usage cohérent de 80% sur une base continue va probablement coûter plus cher dans un environnement serverless, estime le consultant. « La vraie promesse du serverless, toutefois, c’est d’avoir moins de personnes monopolisées par des tâches informatiques sans intérêt telles que le backup ou l’application des correctifs logiciels. Cela apporte deux bénéfices. Le premier, c’est que les personnes qui en étaient chargées peuvent maintenant créer de la valeur ailleurs dans l’IT ou dans l’entreprise. « Personne n’est emballé de devoir effectuer des changements de DNS », cite en exemple Ken Corless. « Ces personnes pourront développer d’autres capacités. Davantage d’automatisation, c’est ce que je vois arriver en premier ».

Cas d'usage typique : l'exécution déclenchée sur un événement

Le 2ème bénéfice, c’est la capacité pour les petites équipes - même dans une grande entreprise - d'être plus autonomes. « Lorsque l’expertise et la mise sur rails de la gestion d’infrastructure sont automatisées, les équipes peuvent se servir elles-mêmes et le faire de façon sûre », souligne M. Corless. « Toutefois, cela demande typiquement un peu d’investissement pour automatiser les standards et les règles, car ce que l’on constate souvent, c’est que les offres serverless ne sont pas assez sûres pour être utilisées sans certains garde-fous ou contraintes. »

La situation idéale pour recourir à une plateforme serverless, c’est lorsqu’une application tire profit d’un traitement déclenché par un événement (event-driven) en utilisant des services découplés, explique Larry Carvalho, directeur de recherche chez IDC, spécialiste des plateformes as a service. Les cas d’usage les plus courants se trouvent dans les applications liées à l’Internet des objets et dans les backends d’applications mobiles qui, justement, déclenchent des processus lors de la survenue d’un événement, explique M.Carvalho. Parmi les autres cas d’usage, on trouve les traitements batchs (effectués par lots en différé) ou au contraire le traitement des flux d’information pour réagir en temps réel aux événements.

Intégrer les contraintes du serverless dès la conception

Comment les entreprises peuvent-elles donc aborder le serverless à leur profit. Voici quelques pratiques suggérées par des experts. En premier lieu, il faut intégrer les contraintes du serverless dans la conception même du processus. Les équipes d’ingénierie qui se convertissent au serverless oublie souvent qu’il existe des contraintes strictes, même dans les produits les plus flexibles, rappelle Daniel Smith, architecte plateforme IoT chez Cordial Inc, un fournisseur de technologie de marketing. Selon lui, se rappeler que le serverless, ce n’est que le serveur ou le conteneur de quelqu’un d’autre, avec ses propres contraintes de conception, permettra de réussir. « La ligne de démarcation de la responsabilité est plus élevée dans la pile avec le serverless, ce qui signifie que des contraintes telles que le temps d’exécution total, le temps de CPU consommé ou encore la quantité de mémoire totale utilisée doivent être considérée pendant la conception et la mise en oeuvre », décrit-il.

Cordial a commencé à explorer les technologies serverless en 2015, dans le but de disposer d’un modèle de coût prévisible en période d’utilisation imprévisible des ressources. « En tant que start-up, il était intéressant d’avoir une structure de coût prévisible basée sur la demande », explique Daniel Smith. En mai 2018, l’entreprise commence à utiliser la technologie Workers de Cloudflare en remplacement de certains de ses systèmes. Cordial a une activité B-to-B qui l’amène à interagir avec des consommateurs pour le compte de ses clients. Ces interactions doivent être aussi rapides que possible. « Cela demande souvent de rapprocher la charge de travail au plus proche de la localisation géographique du consommateur », ce que permet le serverless, décrit par exemple l’architecte plateforme IoT. La start-up ayant réussi à réduire la taille de ses microservices, elle a souhaité les expérimenter avec des langages de programmation qu’elle n’aurait pas déployé autrement, ce qui lui a permis de fournir ses produits plus vite, avec davantage de confiance.

Concevoir des charges de travail limitées

Daniel Smith conseille une autre pratique : il faut concevoir des charges de travail limitées. Les entreprises devraient penser à l’architecture serverless comme à un moteur d’exécution pour une seule fonction, décrit l’architecte IoT de Cordial. « En affinant un peu plus cet objectif, l’entrée et la sortie de la fonction devraient être les données les plus réduites sur lesquelles il est possible de travailler », poursuit-il en explicitant : « au lieu d’utiliser une fonction serverless pour traiter un fichier de données, chaque ligne de données sera exécutée de façon séparée ». En réduisant la taille de chaque unité de travail, le récit commence à se focaliser sur la rapidité avec laquelle le réseau peut déplacer les données entre les services. « Pour des données en vol, par exemple, nous pouvons commencer à envisager le réseau comme une sorte de stockage volatile où chaque seconde nous accorde 10 Go de stockage par interface réseau », décrit encore Daniel Smith. « Le disque, qui est le composant le plus lent du système, est donc évité jusqu’à ce qu’une sortie de données finale doive être stockée de façon persistante ».

Générer des fonctions sans état

Une autre bonne pratique est suggérée par Daniel Dyla, ingénieur logiciel chez Dynatrace, éditeur spécialisé dans la gestion de la performance applicative. Les fonctions doivent être sans état (stateless), autant que possible, c’est-à-dire que l’on ne garde pas de trace de la précédente interaction. Les variables globales, que l’on trouve couramment dans les applications monolithiques, ne fonctionnent pas en mode serverless parce l’état global ne doit pas persister entre les invocations, explique Daniel Dyla. « Les fonctions serverless doivent donc avoir aussi peu d’état que possible. S’il est nécessaire d’indiquer un état, il est préférable d’avoir une fonction qui aille chercher l’état dans une base externe et qui appelle une autre fonction stateless pour effectuer le traitement effectif de la donnée. De cette façon, il sera possible de mettre en quarantaine, à des endroits convenus, les interactions nécessitant un état, afin de les gérer plus facilement ».

Cela fait deux ans environ que Dynatrace utilise la technologie serverless, attiré par son coût réduit, ses capacités de mise à l’échelle et ses invocations basées sur les événements. L’éditeur de logiciels la met en oeuvre pour interroger les systèmes qui doivent opérer de façon continue pour lancer des traitements groupés. « Le premier bénéfice que nous avons constaté, c’est le coût réduit », expose Daniel Dyla. Il décrit les fonctions serverless développées comme de petits bouts de code qui s’exécutent extrêmement rapidement en rafale.

Automatiser le déploiement et le test

Chez Relativity, un éditeur de logiciels de e-discovery, on conseille d’automatiser le déploiement et le test. Si certains outils facilitent le déploiement manuel de traitements serverless, l’automatisation du déploiement assure la cohérence de la mise en oeuvre sans laisser de place à l’erreur humaine, estime Hristo Papazov, ingénieur logiciel senior chez Relativity. L’automatisation permet aussi de faire adopter facilement ces technologies aux autres équipes d’une même entreprise. L’éditeur utilise l’offre serverless du cloud Azure de Microsoft pour chercher à améliorer l’expérience utilisateur de sa plateforme de e-discovery en assurant le bon fonctionnement de ses composants principaux. Relativity recourt au serverless pour ses outils de monitoring interne, en permettant aux utilisateurs de traiter d’importants volumes de données de télémétrie pour détecter rapidement des problèmes et les résoudre, explique Hristo Papazov.

Avec la complexité croissante des applications serverless, la partie test unitaire des cycles de développement devient critique et l’automatisation vient là aussi simplifier les choses, ajoute l’ingénieur logiciel. « Quand Microsoft a lancé Azure Functions il y a quelques temps, le test unitaire était très difficile à réaliser si ce n’est pratiquement impossible », relate-t-il. « Les choses ont beaucoup évolué depuis et il est maintenant très facile d’ajouter des tests unitaires à un projet ».

Décomposer les applications en services indépendants

Larry Carvalho, d’IDC, ajoute une bonne pratique à celles déjà évoquées en recommandant de bien comprendre l’architecture d’une application moderne. Les responsables devraient chercher à décomposer les applications en services indépendants, découplés et capables de s’exécuter rapidement, explique-t-il. Il conseille d’« architecturer une application sans état tout en tirant parti de services de support comme des API de gestion des communications et des fonctionnalités de sécurité pour l’identité des utilisateurs ». Par exemple, une application de serveur web s’exécutant de façon continue pour traiter les transactions entrantes pourrait être subdivisée en extrayant la logique métier et en l’exécutant sous forme de micro-services dans un framework serverless, décrit Larry Carvalho. « Cela supprime le coût de l’exécution continuelle du serveur tout en déléguant le casse-tête de la disponibilité au fournisseur de services cloud ».

Enfin, une dernière bonne pratique est soufflée par Ken Corless, de Deloitte Consulting : la cybersécurité doit être une priorité. Même si, avec les fournisseurs de technologies serverless, il n’est plus nécessaire de se soucier des mises à jour de sécurité sur les serveurs ni d’installer de logiciel antivirus, de telles offres sont basées sur des API « ce qui multiplie singulièrement les endpoints de votre solution », souligne le consultant. « Et si vos API sont utilisées par vos clients ou par vos partenaires, c’est encore plus effrayant ». Par conséquent, les entreprises pourraient avoir besoin de repenser leur approche des règles de pare-feux, car elles pourraient rapidement « créer une pagaille ingérable », avertit Ken Corless.