Phenquestions
Ordinateurs physiques
Nous avons parcouru un long chemin depuis les serveurs massifs de l'ère dotcom. À l'époque, l'infrastructure de serveur était principalement sur site. Une entreprise a exécuté ses solutions sur un serveur physique. Les gens utilisaient des serveurs entièrement séparés à des fins différentes (sauvegardes, serveur de messagerie, serveur Web, etc.). Lorsqu'un certain serveur ne parvenait pas à répondre aux besoins croissants de l'entreprise, il était remplacé par un serveur plus récent et plus rapide. Vous avez évolué en obtenant un meilleur matériel. Vous avez mis à l'échelle verticalement.
Hyperviseurs
Puis vint l'ère des hyperviseurs. Cela a pris de l'ampleur avec l'essor de VMWare et les gens ont réalisé qu'ils pouvaient avoir un seul rack pour les gouverner tous. Un rack pour exécuter tous les différents cas d'utilisation et fournir à chacun d'eux sa propre machine virtuelle distincte. Cela a également donné naissance au cloud computing et les entreprises ont cessé d'investir directement dans le matériel de serveur et ont plutôt choisi de « louer » des serveurs virtuels.
Des centres de données énormes et coûteux étaient gérés par des fournisseurs de cloud dans le monde entier. Les entreprises en ont profité en fournissant leurs services à l'échelle mondiale, en utilisant le plus large éventail possible de centres de données. Cela a été fait principalement pour réduire les latences, améliorer l'expérience client et cibler un plus grand marché.
Cela a également amené les auteurs de logiciels à penser en termes de systèmes distribués. Ils ont écrit des logiciels pour qu'ils fonctionnent non pas sur un seul ordinateur géant, mais sur de nombreux ordinateurs médiocres de manière cohérente et fiable. Vous avez mis à l'échelle horizontalement.
Vous pouvez toujours mettre à l'échelle verticalement. En fait, en raison de la virtualisation, le provisionnement de plus de ressources est devenu plus facile. Vous avez éteint la VM, ajusté ses ressources et payé un petit supplément à votre fournisseur de cloud. Part de gâteau.
Les serveurs physiques sous-jacents n'ont pas disparu. Les fournisseurs de cloud sont désormais chargés de gérer les complexités des interfaces réseau, la compatibilité des systèmes d'exploitation et d'autres pathologies terrifiantes.
Conteneurs
Puis vinrent les conteneurs. Les conteneurs étaient cette étonnante abstraction légère. Un environnement virtuel avec un système d'exploitation qui a permis d'emballer et de déployer le logiciel en une seule unité. À l'instar des machines virtuelles, chaque conteneur fonctionnait sans connaître les autres conteneurs, mais ils partageaient le même noyau de système d'exploitation.
Cela a permis aux gens de déployer des logiciels sur des serveurs (physiques ou virtuels peu importe) à un niveau d'abstraction encore plus élevé. Vous ne vous souciez pas du système d'exploitation de production. Tant qu'il prend en charge votre technologie de conteneurisation, il exécutera votre logiciel. De plus, les conteneurs sont plus faciles à lancer, ce qui a rendu les services plus évolutifs que jamais.
Cela a encore augmenté la flexibilité des systèmes distribués. Avec des technologies comme Kubernetes, vous pouvez avoir des légions de conteneurs exécutant une gamme complexe de services. Les systèmes distribués offrent de nombreux avantages haute disponibilité, robustesse et capacité à se guérir d'une défaillance de nœud.
En même temps, parce qu'ils sont si complexes, ils sont également plus difficiles à concevoir, déployer, maintenir, surveiller et déboguer. Cela va à l'encontre de la tendance initiale consistant à faire abstraction de la complexité de votre logiciel et à déléguer cette responsabilité à votre fournisseur de cloud. C'est là qu'intervient l'architecture sans serveur.
Sans serveur ou Function-as-a-Service (FaaS)
L'idée du sans serveur a gagné du terrain principalement grâce à AWS Lambda, et ici je vais l'utiliser comme modèle pour parler du sans serveur. Les principes sur lesquels le FaaS est basé sont :
- Vous payez pour ce que vous utilisez
- Vous n'avez pas à vous soucier de la mise à l'échelle
- Vous vous concentrez sur votre code, laissez la gestion de l'infrastructure à AWS
Lorsque personne n'accède à vos services, les services ne sont pas actifs. Ce n'était pas le cas dans les solutions d'hébergement traditionnelles où vous payez pour un VPS qui est toujours opérationnel, même s'il est resté inactif sans rien faire de plus utile que d'écouter une nouvelle demande.
Dans une architecture sans serveur, votre service ne fonctionne pas à moins que quelqu'un ne veuille réellement l'utiliser. Lorsqu'une demande arrive, un service est créé à la volée pour la traiter.
Comment ça marche?
Votre fonction (par exemple un programme Python, Go ou Java) se trouve sous forme de fichier sur AWS Lambda. Avec cette fonction, vous associez certains événements déclencheurs, comme une passerelle API ou un nouvel objet entrant dans votre compartiment S3. Et certaines ressources comme une base de données ou un autre magasin d'objets ou une instance EC2.
En réponse à l'un des événements déclencheurs associés, AWS Lambda crée un conteneur avec votre fonction à l'intérieur. La fonction s'exécute et donne une réponse. Par exemple, si une nouvelle image entre dans votre compartiment S3, AWS Lambda peut contenir un code d'apprentissage automatique, qui analyserait cette image et écrirait sa sortie dans une DynamoDB (l'un des services de magasin de données d'AWS).
Vous n'avez pas à payer pour un serveur entier, mais uniquement pour la quantité de mémoire que vous avez allouée à votre fonction, le nombre de requêtes que vous recevez et la durée d'exécution de votre fonction.
De plus, vous n'avez pas à vous soucier de la mise à l'échelle des conteneurs en réponse à une lourde charge de travail entrante. Si de nombreux événements déclencheurs se produisent simultanément, AWS se chargera de lancer de nouveaux conteneurs et de planifier les charges de travail entre eux et toutes les autres complexités.
Pas une solution complète
Lorsque les machines virtuelles sont arrivées, les serveurs physiques n'ont pas cessé d'exister. Lorsque les conteneurs sont arrivés, nous utilisions toujours des machines virtuelles. Le FaaS est une abstraction de niveau supérieur et il s'intègre très bien avec la conception moderne des API RESTful, des services sans état et des langages légers comme Node.js ou Python.
Cependant, s'exécute toujours sur un serveur physique (géré par AWS, par exemple), il écoute toujours les demandes entrantes (vous ne payez tout simplement pas pour cela directement) et vous devez toujours stocker les données de manière persistante, c'est pourquoi il a intégrations pour S3, EC2 et d'autres services. C'est quand même une abstraction utile.
