Capitalisant sur les acquis de l’approche microservices démocratisée durant la dernière décennie, l’informatique « sans serveur » est l’ultime étape du « move to cloud ». Une évolution qui transforme radicalement la manière de développer des solutions applicatives. Avec une promesse forte : tirer pleinement profit des environnements cloud modernes et de leurs services managés, sur lesquels on déploie son code sans se soucier des ressources informatiques sous-jacentes, calcul ou stockage. Outre l’auto-scaling, la haute disponibilité et la facturation à l’usage, le modèle de développement « serverless » est aussi un investissement sur l’avenir, puisqu’il accélère le time to market des futures fonctionnalités. Et rend les applications plus évolutives, plus simples à maintenir.
Faire abstraction de l’infrastructure pour se concentrer sur le code
Le « serverless » est l’aboutissement du modèle DevOps, voire l’avènement du NoOps — un idéal qui tend vers l’automatisation complète du déploiement, du monitoring et de l’administration des applications, ainsi que de l’infrastructure sur laquelle elles s’exécutent. En effet, dans le cadre d’une architecture « serverless », le cloud provider (AWS, Google Cloud Platform, Microsoft Azure…) est responsable de l’exécution du code, allouant dynamiquement des ressources en fonction des besoins. Ceci permet au développeur de se concentrer sur son coeur de métier, mais l’oblige à travailler différemment. D’une part, en découpant l’application en microservices. D’autre part en maîtrisant l’écosystème FaaS — riche de plus de 200 services chez AWS —, et la manière d’interfacer les briques entre elles grâce aux « événements ». Une vraie rupture !
Historiquement, les applications reposaient sur une programmation synchrone : appel -> résultat. Avec le modèle cloud native et l’informatique serverless, les actions sont déclenchées par un ou des événements, par exemple le dépôt d’un fichier déclenchera l’exécution du code et donc la fonction, c’est-à-dire l’écriture dans une base de données.
Pascal Stalin, CTO de la pratice Digital Apps chez Claranet France
Moyennant quoi l’application bénéficie d’un environnement d’exécution qui offre le provisionnement et le dimensionnement automatique (gestion des montées en charge), la haute disponibilité des services et des données et une sécurisation sans faille des couches basses. Le tout sans aucun investissement de départ, coûts fixes ou compétences nécessaires à la gestion d’une infrastructure et de son cycle de vie, puisque la facturation est fonction de la consommation des ressources, à la milliseconde ou à l’octet près. « Ces environnements d’exécution garantissent les meilleurs standards du marché, en matière de SLA et de sécurisation des données. Un tel niveau de service est difficile à atteindre sur une infrastructure on-premise ou déployée dans un cloud privé ; la mutualisation opérée par le cloud provider et l’industrialisation de l’infogérance permet de rendre ces technologies accessibles à tous. » Et si la mise en place d’un backup demeure conseillée, c’est moins pour se protéger d’une défaillance de l’infrastructure — responsabilité qui incombe au cloud provider — que d’une éventuelle erreur humaine.
Investir sur l’avenir et réduire le time to market des applications
L’approche dite « micro-services », jumelée à l’abandon des machines virtuelles au profit de conteneurs, a déjà permis de réduire le délai de livraison des applications par rapport à la conception « monolithique » qui avait cours auparavant. Des équipes de développement plus resserrées peuvent ainsi travailler indépendamment sur différents pans fonctionnels, et les livrer au fur et à mesure. Le modèle de développement « serverless », qui respecte les préceptes du « cloud native », permet de gagner encore en agilité et d’étendre l’approche « déploiement continu » à l’infrastructure grâce à ce que l’on appelle l’« infra as a Code » (gérer et approvisionner une infrastructure avec des lignes de codes). Mais ce n’est pas son seul avantage. Exploiter les services de type PaaS (Platform as a Service) et surtout FaaS (Functions as a Service) que les cloud providers, AWS en tête, démultiplient depuis quelques années ouvre l’accès, très facilement, aux dernières innovations technologiques, notamment celles liées au machine learning et à l’intelligence artificielle : reconnaissance de caractères, speech to text, computer vision…
En outre, cibler une nouvelle zone géographique en rapprochant les services des utilisateurs ne nécessite plus de toucher au code ni de se soucier de la réplication des données entre différentes infrastructures géographiquement distantes… Il s’agit désormais, ni plus ni moins, d’une option activable en quelques clics auprès du cloud provider.
Un modèle de développement puissant, mais qui recèle de nouvelles formes de complexité
Si ce modèle d’architecture « serverless » est naturellement adopté par les startups et pour nombre de projets naissants, il est possible d’y convertir des applications existantes, en basculant progressivement des pans fonctionnels en mode serverless, et en déployant un API manager. Ce mode opératoire, efficace et économe, permet de moderniser des applications sans les redévelopper de zéro. D’y aller progressivement et d’accompagner le changement nécessaire dans la façon de travailler des équipes. Ceci sans hypothéquer l’avenir avec des choix techniques irréversibles.
Ceci dit, ce mode de développement ne convient pas à tous : il exige un certain degré de maturité dans la transition vers le cloud, et certains peuvent craindre, à juste titre, la dépendance vis-à-vis d’un unique cloud provider. Car les projets ainsi développés sont difficilement portables de l’écosystème d’un fournisseur à un autre. D’autre part, si la facturation « à la demande » profite immédiatement aux projets qui connaissent d’importantes variations d’usage, elle impliquera souvent de rationaliser et de mieux sécuriser les applications, pour éviter, par exemple, les appels d’API inutiles ou malveillants. Ainsi, le développement en mode « serverless » n’est pas moins exigeant, au contraire. Avec la facturation on-demand, la performance du code a un impact économique direct sur le projet. Si la sécurité des couches basses est assurée par le cloud provider, la sécurité de la couche applicative demeure votre prérogative, selon le principe de « shared responsability » et en vertu des obligations qui incombent à toute organisation qui manipule des données personnelles ou répond à des normes ou certifications. Le monitoring et le débogage sont également plus complexes qu’avec une application ou la programmation est « séquentielle ». Et la stratégie de découpage, a fortiori quand il s’agit de la modernisation d’une application existante, pour passer d’une solution e-commerce classique à une architecture « headless » (sans front-office), ne s’improvise pas.
Autant de raisons d’être bien accompagnés pour aborder cette révolution et en tirer le meilleur, au-delà de ce qui pourrait apparaître comme un effet de mode à ceux qui n’en saisissent pas tous les enjeux.