La technologie évolue rapidement. Ou peut-être n’est-ce qu’une impression, tant de nouveaux mouvements, approches et architectures surgissent de toutes parts. Ce mois-ci, c’est l’essor soudain des architectures « serverless » qui s’impose dans les fils Twitter et les esprits de tout le monde. Du moins, si vous évoluez dans l’univers Dev/Ops.
Pour ceux d’entre vous qui s’occupent de l’infrastructure, de l’architecture réseau et des opérations, et qui n’ont pas encore été submergés d’informations sur cette nouvelle architecture, il s’agit d’une évolution logique : architecture monolithique –> microservices –> architecture sans serveur. Les applications sont ainsi décomposées encore davantage : usage métier –> service –> fonction.

Littéralement, il s’agit de fonctions. Des fonctions événementielles et granulaires.
Et chacune se concentre sur un périmètre de logique applicative encore plus restreint que celui d’un microservice. Là où un microservice peut contenir toute la logique applicative nécessaire à la mise en œuvre d’un « service de profil », l’architecture serverless la décompose davantage en fonctions individuelles : une pour la connexion, une pour la déconnexion, une pour modifier votre mot de passe et une pour le réinitialiser. En somme, cela revient à créer un petit service spécialisé pour chaque action que vous pouvez effectuer dans une application.
Si l’on parle de « serverless », c’est parce qu’il s’agit essentiellement d’une forme très évoluée de PaaS. Ce qui est une bonne chose pour le PaaS, car ce marché n’est jamais vraiment devenu le mastodonte qu’il espérait être. Il reste un peu dans son coin, salué par les fanboys qui l’adorent, mais il a été largement ignoré et affiche une croissance loin d’être aussi spectaculaire que celle du cloud privé ou public, et encore moins que celle du SaaS. Dans une architecture serverless, le fournisseur de cloud est responsable de tout, à l’exception du code nécessaire pour exécuter une action lorsqu’un utilisateur appuie sur un bouton, coche une case ou clique sur un lien. C’est la dimension événementielle de l’architecture « event-driven » : quand l’utilisateur appuie sur un bouton exécuter function_in_the_cloud. Cette fonction fait généralement partie d’une API plus vaste, elle-même gérée par un autre service dans le cloud.
Ce qui est important ici, c’est que la personne qui écrit la fonction ne se charge pas de provisionner, configurer ou lancer une machine virtuelle ou un conteneur. Elle n’a pas à se soucier de détails opérationnels tels que la mise à l’échelle. Il lui suffit d’écrire quelques lignes de code et, d’un simple clic, voilà ! La fonctionnalité est immédiatement disponible.
C’est le cloud poussé à son paroxysme : la pile dont les développeurs sont désormais responsables se réduit à une seule couche, celle de l’application. « Nothing Else Matters », comme dirait Metallica. Tous les aspects opérationnels sont pris en charge par la plateforme sous-jacente. C’est du NoOps, du moins du point de vue du développeur.
Car vous savez que, sous la plateforme, il y a des serveurs, des services, une infrastructure et un réseau qui rendent possible cette fonctionnalité magique. Ce n’est simplement pas quelque chose dont le développeur doit se préoccuper. Mais vous, en tant que professionnel de l’exploitation de l’infrastructure ou du réseau, vous devez vous en soucier.
C’est pourquoi les entreprises ne sont probablement pas près de prendre le train en marche. Une telle prouesse nécessite un environnement de cloud computing pleinement opérationnel qui intègre non seulement des capacités de provisionnement de machines virtuelles ou de conteneurs, mais aussi la mise à l’échelle automatique. Autrement dit, une mise à l’échelle sans paramètres ni intervention des développeurs. Cela doit se faire tout seul, un point c’est tout. Ce n’est pas du libre-service, c’est de l’auto-service. Il ne s’agit pas seulement de mise à l’échelle, mais aussi de provisionnement automatique. Sans oublier la surveillance, la création de rapports et pratiquement tout ce qui relève aujourd’hui des opérations. C’est pourquoi on observe surtout ce modèle dans les environnements de fournisseurs de cloud bien établis : eux seuls disposent de l’infrastructure, de l’automatisation et de l’orchestration sous-jacentes nécessaires pour prendre en charge un modèle opérationnel aussi largement autonome.
Ainsi, pour l’heure, l’attention portée au serverless consiste principalement à explorer cette approche et à déterminer comment utiliser les solutions actuellement disponibles dans le cloud : Amazon Lambda, Google Cloud Functions, Microsoft Azure Functions, et IBM OpenWhisk. Ce n’est pas qu’il n’existe aucune offre facilitant les déploiements sur site, comme Serverless et Iron.io. Mais pour l’instant, le serverless n’en est encore qu’à ses tout (tout) débuts.
Cela dit, vous allez probablement commencer à entendre parler du serverless. Pour l’heure, ce ne sont encore que les moteurs d’une nouvelle architecture qui se mettent en marche. Il est peu probable que cela ait un impact sur la plupart des organisations à court terme (au cours des 12 à 15 prochains mois), mais il est bon de comprendre de quoi il retourne avant que cette architecture ne fasse escale dans les infrastructures sur site.
The NewStack propose un excellent aperçu si vous souhaitez en savoir plus sur le serverless, ses avantages actuels et les défis qu’il présente.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.