Les conteneurs et les modèles de déploiement et de développement sans serveur font partie de la culture d'avoir une architecture évolutive disponible en fonction de l'utilisation de l'application. Il est donc difficile de choisir entre les deux et c'est exactement ce dont nous allons discuter dans cet article.
What are containers?
Les conteneurs offrent non seulement la possibilité de dépasser certaines limites de la virtualisation traditionnelle mais posent les bases d'un changement radical dans la manière d'appréhender le développement et le cycle de vie des services.
L'idée derrière les conteneurs n'est pas née dans le monde Linux mais a ses racines dans une technologie connue sous le nom de jail FreeBSD, apparue en 2000, qui permet de partitionner un système FreeBSD en sous-systèmes (jail) isolés à la fois les uns des autres et les uns des autres pour le système sous-jacent en étendant le concept de chroot.
Cela a été introduit dans le monde Linux avec le projet Linux Vserver et a été intégré dans les années suivantes avec de nouvelles technologies, notamment cgroup, systemd et Linux Kernel Namespace, décrivant ainsi le projet Linux Container (LXC).
En 2008, avec l'arrivée de Docker, de nouveaux outils et de nouvelles idées ont été ajoutés, comme la possibilité de créer des images en couches (c'est-à-dire résultant de la fusion de plusieurs images) et l'introduction du registre d'images. Les projets de conteneurs dans le monde Linux ont donc reçu un nouvel élan qui a conduit à la naissance de l'Open Container Initiative, dont les membres, dont Docker et Red Hat, collaborent pour définir des standards ouverts et partagés pour les technologies de conteneurs.
Avec ces prémisses et ces outils disponibles, il est naturel de s'interroger pour comprendre s'il existe des alternatives à la virtualisation traditionnelle.
Au-delà des aspects plus strictement techniques, un conteneur Linux est l'ensemble d'un ou plusieurs processus isolés du reste du système, qui :
- Avoir une interface de gestion standard (démarrage, arrêt, variables d'environnement)
- Optimiser l'utilisation des ressources par rapport aux machines virtuelles
- Simplifiez la gestion des applications plus volumineuses (réparties sur plusieurs conteneurs)
La présence des standards proposés par les organismes de normalisation garantit également l'interopérabilité et la possibilité d'orchestrer des conteneurs même entre différents clouds.
Le concept d'images et la manière de les construire et de les agréger constituent l'aspect le plus significatif et le plus innovant, non pas tant du point de vue technologique que pour son impact sur le développement et la gestion opérationnelle, avec des conséquences qui affectent également la manière de comprendre les affaires.
Les images sont immuables, cela signifie que chaque conteneur exécuté à partir d'une même image est identique aux autres, il ne contient aucune information d'état ou donnée persistante. La persistance est confiée à d'autres outils tels que bases de données externes et les systèmes de fichiers. Cela détermine, tout d'abord, une distinction claire entre l'environnement d'exécution de l'application et les données sur lesquelles elle opère, introduisant des logiques de séparation fonctionnelle qui apportent des avantages en termes de nettoyage, de gestion des processus et de sécurité.
La véritable innovation dans le processus de développement et dans le cycle de vie de l'application réside dans le fait qu'une fois un environnement d'exploitation complet et cohérent créé sur une ou plusieurs images, distinct des données sur lesquelles il opère, il pourra passer par toutes les phases du développement à la production sans subir de modifications.
What is Serverless?
Les conteneurs, bien qu'ils permettent une meilleure allocation des ressources par rapport aux machines virtuelles, ne vous permettent pas vraiment de passer à zéro et de croître de manière linéaire : lorsqu'un conteneur ne fournit pas de services, il reste toujours actif en tant que processus. Une réponse à ce besoin peut provenir approches sans serveur.
Une allocation de ressources vraiment efficace nécessite que toute la puissance de calcul soit réellement instanciée uniquement à la demande et libérée immédiatement après utilisation.
Les premiers pas dans cette direction ont été faits par Google avec l'introduction de Google App Engine en 2008, mais le vrai coup de pouce est venu avec l'introduction par Amazon en 2014 de AWS Lambda, le premier véritable modèle FaaS. Par la suite, des solutions alternatives proposées par d'autres éditeurs ont été ajoutées : Microsoft avec Azure Functions, IBM et Google avec leurs propres Cloud Functions. Le monde de l'open source a également évolué dans cette direction avec la sortie de produits tels qu'Apache OpenWhisk, OpenLambda et IronFunctions.
- Source : epsagon.com
Informatique sans serveur est l'un des moyens de distribuer des services dans un contexte cloud qui implique l'exécution d'applications ou, plus exactement, de fonctions, sans nécessiter aucune visibilité sur l'infrastructure sous-jacente : le provisionnement, la mise à l'échelle et la gestion se font automatiquement et linéairement uniquement face à des demandes et besoins. Le terme sans serveur ne doit donc pas être compris comme "l'absence" de serveurs mais comme la transparence des systèmes impliqués du point de vue des développeurs et des utilisateurs.
Cette caractéristique signifie que le Paradigme DevOps, typique dans l'utilisation des technologies conteneurisées, est abandonnée pour revenir à une nouvelle distinction plus claire entre l'infrastructure et le composant applicatif, introduisant deux nouveaux concepts dans le monde du cloud :
- FaaS (Function as a Service) permet aux développeurs de disposer d'un environnement d'exécution pour leurs applications (qu'elles soient C#, Java, Node.js, Python, etc.) qui n'est instancié qu'en réponse à certains événements.
- BaaS (Backend as a Service) permet de déléguer à des tiers les fonctions typiques des applications sans avoir à les implémenter en personne (cas par exemple de services comme Auth0 qui propose des fonctions de gestion d'identité et d'authentification).
Il y a beaucoup de Framework sans serveur disponible sur le marché.
The main difference between serverless and containers
Les conteneurs sont très importants pour l'élan que l'architecture sans serveur a pris des heures supplémentaires, principalement pour intégrer des concepts et la culture de ne plus utiliser les anciennes machines virtuelles et les serveurs classiques. Tout peut être hébergé localement ou dans le cloud, sans complications ni complexité.
La grande différence entre une architecture Serverless utilisant FaaS et des conteneurs est le manque d'intérêt pour les processus qui s'exécutent au niveau du système d'exploitation. Même avec des services comme Docker offrant des capacités d'abstraction similaires à la technologie des conteneurs, en particulier lorsqu'ils sont utilisés conjointement avec Kubernetes, l'architecture sans serveur et le FaaS permettent un degré encore plus élevé de ce type d'abstraction dans le développement d'applications.
Dans une architecture Serverless qui utilise le FaaS, la scalabilité de l'application est gérée de manière automatique et transparente, et elle a également la capacité d'une grande granularité du service pour ses meilleures performances. Les plates-formes qui utilisent des conteneurs ont besoin que ce provisionnement soit géré manuellement, même avec des outils automatisés.
Au final, le style de l'application et l'infrastructure disponible détermineront laquelle des deux formes de déploiement sera la mieux utilisée. L'architecture sans serveur a un niveau élevé d'abstraction de traitement du système d'exploitation tandis que les conteneurs évoluent et développent des moyens d'automatiser l'évolutivité et la disponibilité.
How to choose between serverless and containers?
Dans ce tour d'horizon, nous avons essayé de mettre en évidence la radicalité de la transformation qui a secoué le monde des services informatiques ces dernières années, redéfinissant les infrastructures, les modèles de développement, voire les business models.
Cependant, ce qui peut sembler un processus évolutif dans lequel les nouvelles technologies sont destinées à remplacer les précédentes, est en réalité un chemin beaucoup moins linéaire : il existe et existera probablement encore pendant longtemps des scénarios dans lesquels chacune des trois technologies sera la un seul applicable, d'autres dans lesquels ils devront s'intégrer et chacun trouvera son espace.
Toutes les charges de travail ne sont pas portables dans des conteneurs : dans certains cas, il serait nécessaire de reconcevoir et de réécrire l'application. Il n'est pas certain que cela soit toujours possible, il existe donc encore des situations dans lesquelles les machines virtuelles permettent un contrôle ou une flexibilité du système qui les rend indispensables.
Containers and Serverless Use Cases
Conteneurs trouvent leur utilisation idéale dans des applications complexes, qui nécessitent un niveau élevé de contrôle de l'environnement d'exploitation, éventuellement avec des temps de traitement longs et qui se prêtent en même temps à une mise en œuvre dans un environnement conteneurisé.
Même si l'utilisation des ressources est moins efficace qu'une approche sans serveur, les performances sont en moyenne meilleures car au moins le premier conteneur est toujours actif et n'a pas à être instancié à partir de zéro.
La conception, le développement et la gestion peuvent être plus simples puisque la présence de cadres et de normes partagés permet l'orchestration entre les clouds de différents fournisseurs avec une mise à l'échelle beaucoup plus simple que les serveurs virtuels.
À l'inverse, dans les conteneurs, les modifications de fonctions individuelles nécessitent la création et le déploiement d'une nouvelle image, avec l'allongement des délais de publication et la possibilité d'erreur. La croissance du nombre d'instances en réponse à l'augmentation de la charge entraîne des difficultés de monitoring et d'éventuels problèmes de performances car la capacité de croissance est toujours limitée par la rapidité des composants qui garantissent la persistance des données.
Un exemple typique d'utilisation peut être un grand site de commerce électronique composé de nombreuses parties telles que la liste de prix, gestion d'entrepôt, et des paiements, chacun pouvant être conditionné dans un conteneur pour lequel le temps d'exécution et les limites de mémoire ne constituent pas un problème.
L'approche sans serveur peut être idéale dans un contexte de microservices et dans des scénarios tels que IdO, où certaines fonctions doivent être appelées uniquement lorsque des événements spécifiques se produisent et ne font pas partie d'un service permanent.
S'agissant d'un modèle strictement payant à l'usage, il permet une optimisation des coûts, notamment dans les cas où il est difficile de procéder à un dimensionnement a priori ou de prévoir la charge à laquelle il faudra faire face.
La difficulté de conception et l'absence de normes, qui dans de nombreux cas déterminent le problème de l'enfermement des fournisseurs, constituent toujours une forte limitation du domaine d'utilisation.
Mot de la fin
En résumé, aucune technologie n'est meilleure qu'une autre dans l'absolu : chacune répond à des besoins spécifiques. Ils peuvent coexister et être intégrés, selon les besoins, dans un même projet. La meilleure approche n'est donc pas de décider d'un cheminement préalable pour le développement de vos applications, mais de commencer par une analyse minutieuse des caractéristiques et des exigences afin de choisir l'architecture la plus appropriée.
