Examinons l’objectif des critères de décision les plus courants d’un développeur – temps et argent
L’architecture sans serveur est le nouveau paradigme du cloud computing qui promet de réduire les coûts globaux de développement et d’exploitation, grâce à une combinaison de nouvelles technologies et de structures de prix.
Bien que l’architecture évolue rapidement, le sans serveur manque une définition standard et un consensus général au sein de la communauté technique.
Le terme sans serveur est utilisé généreusement pour étiqueter tout, des produits commerciaux, des projets open source, aux aspects de l’architecture sous-jacente. Cela n’aide pas que ce terme implique l’absence de serveurs.
I am the only one who doesn't like Serverless as an architectural description? It says what it is *not*, so what would describe it better?
— Werner Vogels (@Werner) July 13, 2016
Avant d’essayer de définir le sans serveur, il est important de comprendre comment nous sommes arrivés à ce point d’inflexion de l’architecture moderne. Pour suivre l’évolution de serveurs vers des sans serveurs, examinons l’objectif des critères de décision les plus courants des développeurs : le temps et l’argent.
Les racks et les piles
Au début, il y avait des serveurs.
Rappelez-vous les serveurs ? Ces grandes boîtes plates et physiques avec des composants de qualité industrielle coûteux à l’intérieur ? Ils étaient généralement placés dans des centres de données avec des alimentations redondantes et des réseaux à haut débit.
Le serveur a été installé dans un rack de serveur, mis sous tension et connecté au réseau. Après l’installation initiale du système d’exploitation et des correctifs, le serveur devait être configuré avec des serveurs Web, des bases de données et des caches.
Une fois correctement configuré, le code de l’application sera finalement copié sur chaque serveur. La fin de l’installation n’était que le début : les serveurs devaient être surveillés, les correctifs appliqués en permanence et les nouveaux serveurs ajoutés lorsque l’utilisation des applications augmentait ou que les serveurs échouaient.
L’effort nécessaire à l’administration d’un serveur dépasse de loin le temps nécessaire au développement d’une application – et représente un coût continu pour la durée de vie de l’application. La seule raison et l’avantage d’installer les serveurs physiques restent le contrôle absolu du matériel.
Aujourd’hui, ce modèle de serveurs en cours d’exécution a été rationalisé sous des formes commerciales telles que la colocation de serveurs, l’hébergement sans serveurs et les serveurs dédiés. Chacun des modèles varie quant au degré de main-d’œuvre requise, à la méthode d’acquisition du matériel et au modèle de tarification, mais ils sont tous toujours mieux adaptés à ceux qui ont besoin d’un contrôle absolu sur leur propre matériel.
En règle générale, cette approche comprend de grandes organisations avec des compétences spécifiques et des besoins spécialisés.
Exemples : Colocation gérée par Rackspace, Colocation de Joe’s Data Center, Rackspace OnMetal, Scaleway
C’est virtuellement un serveur
Avec l’avènement de la technologie de virtualisation, et en particulier de la prise en charge matérielle de ce dernier dans les processeurs vers 2005, un serveur physique pouvait être efficacement divisé en plusieurs serveurs virtuels ou machines virtuelles plus petits.
Chaque serveur virtuel peut exécuter sa propre copie séparée d’un système d’exploitation standard tel que Linux, Windows ou FreeBSD. A la fin de chaque instance, elle est isolée des autres serveurs virtuels exécutés sur la même machine physique.
Un serveur coûteux de 10 000 $ qui était surapprovisionné pourrait désormais être divisé en cinq serveurs de 2 000 $ plus petits – chacun exécutant un système d’exploitation différent, sans aucune modification de logiciel existant.
La virtualisation fonctionne grâce à une couche logicielle supplémentaire assistée par matériel appelée hyperviseur située sous un système d’exploitation traditionnel. Le but de l’hyperviseur est d’émuler efficacement un serveur physique, avec ou sans la coopération du système d’exploitation.
La virtualisation avait un côté intéressant : puisque l’hyperviseur agit comme intermédiaire entre une machine virtuelle et le matériel réel, une machine virtuelle en cours d’exécution pouvait être « figée » à tout moment dans un instantané ou snapshot de système, créant essentiellement un fichier d’instantané de grande taille.
L’instantané peut être copié sur un autre serveur et un clone exact de la machine virtuelle peut être restauré. L’instantané pourrait inclure de manière exhaustive tout ce qui concerne l’état de fonctionnement des programmes et le contenu de la mémoire allouée, ou simplement capturer une image du « disque dur ».
Une flotte de serveurs virtuels
Les hébergeurs commerciaux ont rapidement commencé à proposer des serveurs privés virtuels, ou VPS, au lieu d’utiliser un serveur dédié. Les fournisseurs installeraient et configureraient les systèmes d’exploitation populaires tels que Linux ou Windows sur des machines virtuelles, puis prendraient un instantané pour obtenir une copie principale.
Ces instantanés peuvent ensuite être copiés sur un nombre quelconque de serveurs physiques et restaurés sur une machine virtuelle pleinement opérationnelle en quelques minutes ou secondes. Ce processus pouvant être répété plusieurs fois, de grandes flottes de serveurs virtuels exécutant un logiciel identique pourraient être créées et détruites rapidement, plutôt que de configurer individuellement des serveurs physiques.
En tirant parti des machines virtuelles et des économies d’échelle, les fournisseurs ont également pu mieux utiliser leur flotte de serveurs physiques.
Avec les machines virtuelles, un seul serveur peut être efficacement divisé en plusieurs serveurs de tailles différentes, chacun pouvant être loué à un développeur différent. La combinaison de serveurs virtuels pourrait être modifiée à tout moment, ce qui permettrait d’offrir aux développeurs une plus grande variété de tailles de serveurs, tout en permettant une utilisation plus efficace de leur inventaire de serveurs physiques.
L’utilisation des développeurs de fournisseurs de serveurs privés virtuels avec quelques nouveaux avantages :
- Mis à l’échelle. Le système d’exploitation du serveur n’a dû être configuré qu’une seule fois, et l’état figé pouvait ensuite être réutilisé pour créer rapidement de nombreux serveurs virtuels identiques.
- Fiabilité. Si le serveur physique tombe en panne pour une raison quelconque, le fournisseur d’hébergement peut recréer automatiquement le VPS sur un serveur physique différent et basculer automatiquement l’ancienne adresse IP vers le nouveau VPS.
- Flexibilité. La disponibilité d’instances plus petites et moins chères a augmenté, ainsi que la possibilité de combiner des instances plus grandes pour optimiser les coûts par rapport aux besoins en performances.
- Contrôle des coûts. Puisqu’un VPS peut être facilement créé et détruit, les fournisseurs facturent généralement à l’heure ou au mois au lieu de l’année. De grandes flottes pourraient être créées pendant quelques heures, utilisées, puis détruites sans entraîner le coût d’un bail de serveur annuel.
La virtualisation a eu un impact considérable sur la rentabilité de la gestion de flottes de serveurs. Cette technologie a conduit à la popularité des installations gérées et peu coûteuses de divers systèmes logiciels tels que WordPress, ainsi que du serveur virtuel à 5 $ par mois, désormais très répandu, « payez au fur et à mesure ».
Exemples : Google Compute Engine, Amazon EC2, Linode,
Contenez-vous
En 2007, une nouvelle fonctionnalité apportée par Google au noyau Linux permettait de répliquer efficacement une forme limitée de virtualisation au sein du système d’exploitation Linux lui-même.
L’objectif principal de cette fonctionnalité était de regrouper en toute sécurité un programme Linux et toutes ses dépendances dans une image de conteneur. L’image peut ensuite être clonée et exécutée sur d’autres machines Linux – avec un degré d’isolation par rapport aux autres conteneurs s’exécutant sur la même machine.
Bien que cela ressemble beaucoup à la virtualisation, il existe un certain nombre de différences techniques importantes entre les machines virtuelles et les conteneurs.
La principale différence entre les conteneurs et les machines virtuelles réside dans le fait que les machines virtuelles exécutent un système d’exploitation par-dessus un hyperviseur, alors que les conteneurs exécutent des programmes par-dessus un système d’exploitation.
Conteneurs vs Machines virtuelles, avec l’aimable autorisation de Docker Inc. et RightScale Inc.
L’un des inconvénients du démarrage d’une machine virtuelle est que le processus implique un processus de démarrage complet du système d’exploitation ou nécessite la restauration de l’état du système en cours d’exécution à partir d’un instantané figé.
Ces deux procédures peuvent prendre de l’ordre de quelques minutes. Une fois la séquence de démarrage terminée, l’exécution d’une machine virtuelle consomme tout le système d’exploitation, avec tous les processeurs et mémoire associés.
Les conteneurs, quant à eux, s’exécutent au sein d’un système d’exploitation à hébergeur unique. Le programme en cours d’exécution consomme uniquement le processeur et la mémoire nécessaire au sein du conteneur. Quand un conteneur est démarré, le programme d’application à l’intérieur de celui-ci démarre comme un programme standard, mais il est limité par le système d’exploitation pour s’exécuter de manière isolée sur une seule partie de ressources système globales.
Cette fonctionnalité conduit à deux propriétés intéressantes des conteneurs par rapport aux machines virtuelles :
- Utilisation réduite des ressources. La surcharge de mémoire et de processeur d’un conteneur est de loin inférieure à celle d’une machine virtuelle. Les conteneurs ne disposent pas d’un système d’exploitation complet, constitué de processus en arrière-plan, de pilotes de périphériques et d’autres accessoires fonctionnant parallèlement aux programmes du développeur.
- Démarrage plus rapide. Les machines virtuelles doivent être soit démarrées via une procédure de démarrage du système d’exploitation standard, soit restaurées à partir d’un état suspendu. Par ailleurs, un conteneur démarre avec une latence comparable à un double-clic sur un programme sur votre bureau, tout en offrant de nombreux avantages des machines virtuelles.
Étant donné que les conteneurs consomment moins de mémoire et moins de cycles de processeur que les machines virtuelles entières, les fournisseurs pourraient utiliser leur flotte de serveurs physiques de manière encore plus efficace. Ainsi, au lieu de regrouper dix machines virtuelles sur un seul serveur, ils pourraient désormais regrouper cinquante conteneurs sur la même machine.
Between containers, cluster managers and virtual machines we've lost track of where our code even is. #inception
— Honest Update (@honest_update) November 3, 2015
Les fournisseurs pouvaient désormais proposer aux développeurs un nouveau compromis, leur permettant d’exécuter des applications plutôt qu’un conteneur et plutôt qu’une machine virtuelle. Les conteneurs constituaient une excellente option en supposant que le développeur n’avait pas besoin d’interagir avec les composants du système, il pouvait exprimer son application et toutes ses dépendances sous forme de système de fichiers, et cela fonctionnait sur quelques systèmes d’exploitation prenant en charge les conteneurs.
Avec les conteneurs, les développeurs bénéficiaient encore de nombreux avantages des machines virtuelles, tels que l’installation de bibliothèques système personnalisées et la modification de nombreux paramètres du système d’exploitation, mais avec un processus de déploiement plus rapide que les machines virtuelles.
Les images de conteneur étaient généralement petites, plus rapides à démarrer, faciles à tester et pouvaient être créées rapidement par des scripts et testées localement. En raison de l’utilisation de systèmes de fichiers en couches par les exécutions de conteneurs, les images peuvent être créées, mises à jour et téléchargées beaucoup plus rapidement que les images de machine virtuelle.
Toutefois, la méthode de facturation n’a pas changé : les fournisseurs ont exécuté des conteneurs en continu et facturé le nombre d’heures d’exécution de chaque conteneur. La facturation se produirait même si le conteneur consistait en un programme inactif qui ne fonctionnait pas et correspondait à l’expérience de la location d’un VPS à l’heure.
Exemples : Docker Engine, LXD, Mesos, Kubernetes, AWS ElasticBeanstalk
Plate-forme en tant que service (PaaS)
À un moment donné, les fournisseurs ont compris que de nombreux développeurs utilisaient des conteneurs configurés de la même manière pour exécuter leurs applications. Une configuration Web typique peut contenir un serveur Web, un environnement d’exécution et une infrastructure d’application Web, tels que Ruby on Rails ou PHP, ainsi que le code de l’application du développeur.
Ces conteneurs sont généralement servis en tant qu’API basée sur HTTP, permettant un accès facile à partir de Web frontends, d’applications natives et d’applications d’ordinateur de bureau. Parmi tous les composants et logiciels auxiliaires qui sont entrés dans la « pile » de logiciels, le seul qui importait vraiment aux développeurs était leur propre code d’application, ou leur logique métier.
Si les composants restants pouvaient être gérés par le fournisseur (tel que le serveur Web, le langage d’exécution, les bibliothèques système), le développeur pourrait alors être libre de se concentrer uniquement sur l’écriture de son code d’application. Le fournisseur serait responsable de la configuration d’un environnement de système d’exploitation largement standard pour le développeur. En retour, le développeur obtiendrait un environnement cohérent qui réduirait le temps de développement et les coûts de maintenance.
Afin d’atteindre l’objectif consistant à se concentrer uniquement sur la logique métier qui différencie votre produit, tout le reste doit être résumé dans un service standardisé. Le développeur doit apprendre à céder le contrôle de tout le reste au fournisseur, en comptant sur lui pour créer un environnement standard dans lequel exécuter le code du développeur.
Le fournisseur assume toutes les tâches associées à la maintenance et à l’exploitation d’un service Web évolutif – de la mise en service de serveurs virtuels ou physiques à la configuration du système d’exploitation et du logiciel serveur utilisés, en passant par la détermination de la version exacte de l’exécution d’une langue. Puisque le développeur n’a plus à se préoccuper de ces tâches, la taille du code nécessaire à la mise en production de son application est considérablement réduite.
Bien que cette approche ait conduit à l’évolution de la plate-forme en tant que service, où les développeurs pouvaient continuellement créer et détruire dynamiquement des conteneurs en cours d’exécution, les développeurs souhaitaient encore réaliser des économies de coûts supplémentaires.
Exemples : Heroku, Meteor Galaxy
Fonctions en tant que service (FaaS)
En raison de la petite taille et du temps d’exécution des conteneurs, les fournisseurs ont vite compris qu’ils pouvaient exécuter l’application du développeur lorsqu’une demande était reçue, puis l’arrêter immédiatement pour économiser des ressources.
Au lieu de conserver une copie du code du développeur en permanence et générant des frais de facturation, les fournisseurs pouvaient désormais attendre la demande d’un utilisateur et créer ensuite un conteneur contenant le code du développeur pour répondre à la demande. Une fois que le code du développeur a répondu à la demande, le conteneur est détruit, ce qui libère des ressources système pour d’autres demandes.
Cela conduit à l’une des caractéristiques déterminantes du paradigme sans serveur : des environnements de conteneur de courte durée, créés pour répondre aux demandes individuelles et à d’autres événements. Ces événements peuvent être des requêtes HTTP, des connexions WebSocket, des éléments de file d’attente de travail et des notifications de base de données, parmi beaucoup d’autres déclencheurs possibles.
Du point de vue du fournisseur, les requêtes d’applications multiples de développeurs peuvent être efficacement réparties sur une grande flotte de serveurs Web. Chaque conteneur est de courte durée – et ne consomme des ressources que pendant la durée de traitement d’une requête. La flotte du fournisseur peut être utilisée encore plus efficacement que les conteneurs qui fonctionnent en permanence, car ils consomment de la mémoire et des ressources de traitement, même inactifs.
Etant donné que les requêtes individuelles peuvent être acheminées vers n’importe quelle machine physique de la flotte, les fournisseurs ont été en mesure d’offrir aux développeurs le Saint Graal de la mise à l’échelle – un parallélisme instantané et massif – sans aucune dégradation du service en cas de forte augmentation soudaine du trafic (par exemple, après une publicité dans le Super Bowl).
Pour les développeurs, l’expérience sans serveur offre de nombreux autres avantages, en plus du parallélisme instantané.
- Code plus simple : au lieu d’écrire des programmes de service Web de longue durée, le paradigme sans serveur encourage de petits programmes sans état ou fonctions, qui peuvent être créés et détruits à la demande. Au lieu de garder une trace de chaque client connecté au serveur, le code du développeur peut maintenant supposer qu’il est créé pour communiquer avec un seul client.
- Pas de mise en service : au lieu de devoir déterminer les performances requises par une application avant sa mise en production, les développeurs peuvent désormais déployer une application sans serveur sans se soucier du nombre de serveurs ou d’instances à réserver.
- Pas de temps d’inactivité payé : avec une application sans serveur, le code de développeur n’est exécuté qu’en réponse à des événements déclencheurs, sur une flotte « invisible » de serveurs réels masqués à la vue du développeur. Le développeur n’a aucun contrôle sur le nombre de serveurs ou d’instances qu’il peut réserver. La seule unité facturable raisonnable est donc le temps total passé par le fournisseur à traiter tous les événements entrants.
Un principe majeur de l’écriture de code sans serveur est d’exprimer la logique métier en tant que programmes créés pour servir un seul événement déclencheur – et uniquement cet événement. Une fois que le programme a fini de gérer l’événement déclencheur, il est détruit.
Cette approche de l’architecture sans serveur contraste nettement avec la programmation client/serveur traditionnelle, dans laquelle un programme unique avec plusieurs threads peut accepter et répondre à de nombreuses connexions HTTP simultanées à l’aide de commodités telles que la mémoire partagée entre les requêtes.
Things I don't care about in a serverless environment –
1) The servers you use
2) Containers
3) Your electricity provider
4) Nuts and bolts— Simon Wardley (@swardley) April 8, 2017
En conséquence, il incombe désormais aux développeurs d’écrire ou de réécrire leurs applications en utilisant un paradigme différent. Dans de nombreux cas, cependant, cette réécriture peut réellement réduire la quantité de code requise pour une application particulière.
Exemples : AWS Lambda, Google Cloud Function, Fonctions Azure.
Les services sans serveur
Bien que servir de sites Web est actuellement le cas d’utilisation le plus important, le paradigme sans serveur s’étend bien au-delà de ce modèle courant. Les fournisseurs proposent déjà des entrepôts de données sans serveur, des bases de données sans serveur et des systèmes de traitement de flux sans serveur.
À l’avenir, nous pouvons nous attendre à ce que ce paradigme soit rapidement étendu à d’autres classes de produits, car les avantages pour les développeurs sont tellement évidents. Pour aider à déterminer si un produit ou un service est « sans serveur » – vous pouvez souvent consulter la page de tarification des propriétés suivantes :
- Pas de mise en service : s’il nécessite une mise en service de capacité explicite, il ne s’agit probablement pas d’une plate-forme sans serveur. Le produit ou service ne doit pas obliger le développeur à réserver un nombre explicite d’instances, de serveurs ou de conteneurs. Une plate-forme sans serveur augmente la capacité selon les besoins, en maintenant les détails transparents pour l’utilisateur.
- Facturation à l’utilisation : si un produit ou un service facture au moment où une application est maintenue disponible, plutôt que pour l’utilisation réelle de l’application, il ne s’agit probablement pas d’une plate-forme sans serveur. Un test décisif rapide permet de s’assurer qu’une application inactive produira une facture négligeable à la fin du mois.
TL ; DR – consultez le tableau récapitulatif
Le tableau suivant présente les catégories de produits en fonction de la quantité de pile gérée par le développeur. Chaque ligne représente une tranche de la pile – de la première ligne de code d’application en haut au centre de données physique qui héberge le serveur qui exécute finalement l’application.
