Préparez-vous. Le sans serveur arrive.
La technologie évolue rapidement. Ou peut-être que tout semble aller vite parce que de nouveaux mouvements, de nouvelles approches et de nouvelles architectures apparaissent à gauche et à droite. Ce mois-ci, c’est l’apparition soudaine des architectures « sans serveur » au premier plan du flux Twitter et de la conscience de chacun. Au moins si vous êtes dans le monde Dev/Ops.
Pour ceux d’entre vous qui s’intéressent à l’infrastructure, à l’architecture réseau et aux opérations et qui n’ont pas été inondés par cette nouvelle architecture, il s’agit d’une progression logique allant des architectures monolithiques -> microservices -> sans serveur. Il s’agit d’une répartition plus poussée des applications selon leur utilisation professionnelle -> service -> fonction.
Littéralement, il s’agit de fonctions. Fonctions pilotées par événements et à granularité fine.
Et chacun se concentre sur un champ d’application logique encore plus restreint qu’un microservice. Alors qu’un microservice peut contenir toute la logique d’application requise pour implémenter un « service de profil », l’architecture sans serveur le décompose en fonctions individuelles. Un pour la connexion, un pour la déconnexion, un pour changer votre mot de passe, un pour le réinitialiser. En gros, c’est comme créer un petit service ciblé pour chaque action que vous pourriez effectuer dans une application.
La raison pour laquelle on l'appelle « sans serveur » est qu'il s'agit essentiellement d'une forme très évoluée de PaaS. C’est une bonne chose pour le PaaS, car en tant que marché, le PaaS n’est jamais vraiment devenu le mastodonte qu’il espérait être. C'est juste un truc qui traîne, qui reçoit les acclamations des fanboys qui l'adorent, mais pour la plupart, il a été ignoré, se développant à un rythme qui n'est pas aussi excitant que le cloud privé ou public, et certainement pas comme le SaaS. Dans une architecture sans serveur, le fournisseur de cloud est responsable de tout, sauf du code requis pour effectuer une action lorsqu'un utilisateur appuie sur un bouton, une case à cocher ou clique sur un lien. C'est la partie événement de « piloté par événement » : lorsque l'utilisateur appuie sur le bouton, exécutez function_in_the_cloud . Cette fonction fait généralement partie d’une API plus vaste gérée par un autre service dans le cloud.
L’important ici est que la personne qui écrit la fonction ne provisionne pas , ne configure pas et ne lance pas une machine virtuelle ou un conteneur. Ils ne se soucient pas des détails opérationnels comme l’échelle. Ils écrivent simplement du code et en un clic, voilà ! Fonctionnalité instantanée.
Il s'agit du cloud poussé à l'extrême, puisque les développeurs de la pile sont désormais responsables de sa réduction à une seule couche, la couche applicative. Rien d’autre n’a d’importance, comme dirait Metallica. Chaque détail opérationnel est fourni par la plateforme sous-jacente. C'est NoOps, ou du moins du point de vue du développeur.
Parce que vous savez qu’il existe des serveurs, des services, une infrastructure et un réseau sous la plateforme qui fournissent cette capacité magique. Ce n’est tout simplement pas quelque chose dont le développeur doit s’inquiéter. Mais vous, en tant que professionnel de l’infrastructure ou des opérations réseau, vous le faites.
C’est pourquoi il est peu probable que les entreprises se lancent dans cette voie avant un certain temps. Un tel exploit nécessite un environnement de cloud computing entièrement opérationnel qui intègre non seulement des capacités de provisionnement de machines virtuelles ou de conteneurs, mais également une mise à l’échelle automatique . En d’autres termes, évoluez sans paramètres ni intervention des développeurs. Ça devrait juste arriver, bon sang, et c'est tout. Ce n’est pas du libre-service, c’est de l’auto- service. Ce n’est pas seulement une question d’évolutivité, c’est aussi une question d’approvisionnement automatique. Et le suivi, le reporting et à peu près tout ce qui touche aux opérations aujourd’hui. C'est pourquoi nous le voyons principalement dans les environnements de fournisseurs de cloud bien établis ; seuls eux disposent de l'infrastructure sous-jacente, de l'automatisation et de l'orchestration nécessaires pour prendre en charge un modèle opérationnel largement non interventionniste.
Donc, la majeure partie de l'attention portée au sans serveur à l'heure actuelle consiste à le tester et à déterminer comment travailler avec les incarnations actuelles disponibles dans le cloud : Amazon Lambda , Google Cloud Functions , Microsoft Azure Functions et IBM OpenWhisk . Ce n’est pas comme s’il n’existait pas d’offres pour aider les implémentations sur site telles que Serverless et Iron.io. Mais pour l'instant, il est encore tôt pour le sans serveur.
Pourtant, vous allez probablement commencer à entendre des rumeurs à propos du sans serveur. Pour l’instant, il s’agit en grande partie des moteurs d’une nouvelle architecture qui démarre. Il est peu probable que cela ait un impact sur la plupart des organisations à court terme (dans les 12 à 15 prochains mois), mais il est bon de comprendre de quoi il s’agit avant de s’arrêter sur site.
Le NewStack offre un excellent aperçu si vous souhaitez en savoir plus sur le sans serveur et sur les avantages et défis actuels.