Risque vs récompense : un guide pour comprendre les conteneurs logiciels

Ceux d'entre nous qui sont assez âgés se souviennent d'un jour où les logiciels étaient principalement livrés par des supports physiques. La diffusion de l'Internet haut débit et des smartphones nous a conduits à l'ère des services Web, c'est-à-dire des logiciels hébergés dans le cloud accessibles par des clients utilisateurs tels que des navigateurs et des applications.

Il n'y a pas si longtemps, les applications Web étaient exécutées directement sur des machines physiques dans des centres de données privés. Pour faciliter la gestion, ces applications étaient généralement monolithiques : un seul grand serveur contiendrait tout le code et la base de données back-end. Aujourd'hui, les services d'hébergement Web comme Amazon et la diffusion de la technologie de l'hyperviseur ont tout changé. Grâce à Amazon Web Services (AWS) et à des outils comme VirtualBox, il est devenu facile de regrouper un système d'exploitation complet dans un seul fichier.

À l'aide de services comme EC2, il est devenu facile de regrouper des images de machines et d'enchaîner des ensembles de serveurs virtuels. Vint ensuite le paradigme des microservices, une approche de l'architecture logicielle dans laquelle les grandes applications monolithiques sont divisées en services ciblés plus petits qui font bien une chose. En général, cette approche facilite la mise à l'échelle et le développement de fonctionnalités, car les goulots d'étranglement sont plus rapides à trouver et les modifications du système plus faciles à isoler.

Animaux de compagnie au bétail

Je suis devenu ingénieur en infrastructure au plus fort de cette tendance. Je me souviens avoir créé mon premier environnement de production sur Amazon à l'aide d'une série de scripts bash. Les serveurs étaient comme des animaux de compagnie pour moi. J'ai donné à chacun d'eux des noms mignons. Je les ai surveillés attentivement. J'ai répondu aux alertes rapidement et les ai gardés en bonne santé. J'ai traité ces cas avec amour et affection parce qu'il était douloureux d'essayer de les remplacer, un peu comme un animal de compagnie bien-aimé.

Puis vint Chef, un outil de gestion de configuration, et presque immédiatement ma vie est devenue plus facile. Avec des outils comme Chef et Puppet, vous pouvez supprimer la plupart des tâches manuelles associées à la gestion d'un système cloud. Vous pouvez utiliser sa construction "environnements" pour séparer les serveurs de développement, de préproduction et de production. Vous pouvez utiliser ses « sacs de données » et ses « rôles » pour définir les paramètres de configuration et pousser des ensembles de modifications. Maintenant, tous mes serveurs "animaux de compagnie" étaient diplômés de l'école d'obéissance.

Puis en 2013, Docker est arrivé, et une nouvelle ère a commencé : l'ère du logiciel comme bétail (excuses à tous les végétaliens dans le public). Le paradigme du conteneur est celui de l'orchestration, pas de la gestion de la configuration. Des outils tels que Kubernetes, Docker Compose et Marathon se concentrent sur le déplacement d'images prédéfinies au lieu d'ajuster les valeurs de configuration sur les instances en cours d'exécution. L'infrastructure est immuable ; lorsqu'un conteneur tombe en panne, nous n'essayons pas de le réparer, nous lui tirons une balle dans la tête et le remplaçons. Nous nous soucions plus de la santé du troupeau que des animaux individuels. Nous ne donnons plus de noms mignons à nos serveurs.

Les récompenses

Les conteneurs facilitent beaucoup de choses. Ils permettent aux entreprises de se concentrer davantage sur leur propre sauce spéciale. Les équipes techniques peuvent moins se soucier de l'infrastructure et de la gestion de la configuration et se soucier plutôt du code de l'application. Les entreprises peuvent aller plus loin et utiliser des services gérés pour des choses comme MySQL, Cassandra, Kafka ou Redis afin de ne pas avoir du tout à gérer la couche de données. Plusieurs startups proposent également des services d'apprentissage automatique "plug and play" pour permettre aux entreprises d'effectuer des analyses sophistiquées sans se soucier de l'infrastructure. Ces tendances ont abouti au modèle sans serveur, une approche d'architecture logicielle qui permet aux équipes de publier des logiciels sans gérer une seule machine virtuelle ou conteneur. Les services AWS tels que S3, Lambda, Kinesis et Dynamo rendent cela possible. Donc, pour étendre l'analogie, nous sommes passés des animaux de compagnie au bétail à une sorte de service animalier à la demande.

Tout cela est très cool. C'est fou que nous vivions à une époque où un enfant de douze ans peut faire tourner un système logiciel sophistiqué en quelques clics. Rappelons-nous qu'il n'y a pas si longtemps, c'était impossible. Il y a quelques présidents américains à peine, les supports physiques étaient la norme et seules les grandes entreprises avaient les moyens de fabriquer et de distribuer des logiciels. Les corrections de bugs étaient un luxe. Désormais, ce gamin de douze ans peut créer un compte AWS et mettre son logiciel à la disposition du monde entier. S'il y a un bogue, quelqu'un le boguera sur Slack et, en quelques minutes, un correctif est disponible pour tous les utilisateurs.

Les risques

Très, très cool, mais pas sans prix - la dépendance à l'égard des fournisseurs de cloud comme Amazon signifie la dépendance à l'égard des grandes entreprises et des technologies propriétaires. Si Richard Stallman et Edward Snowden ne vous ont pas fait vous inquiéter de telles choses, la récente débâcle avec Facebook aurait certainement dû le faire.

Une plus grande abstraction du matériel entraîne également le risque d'une transparence et d'un contrôle moindres. Lorsque quelque chose tombe en panne dans un système exécutant des centaines de conteneurs, nous devons espérer que la panne surgit quelque part que nous pouvons détecter. Si le problème vient du système d'exploitation hôte ou du matériel sous-jacent, il peut être difficile à déterminer. Une panne qui aurait pu être résolue en 20 minutes à l'aide de machines virtuelles peut prendre des heures ou des jours à résoudre avec des conteneurs si vous ne disposez pas de la bonne instrumentation.

Ce ne sont pas seulement les échecs dont nous devons nous soucier lorsqu'il s'agit de choses comme Docker. Il y a aussi le problème de la sécurité. Quelle que soit la plate-forme de conteneurs que nous utilisons, nous devons être sûrs qu'il n'y a pas de portes dérobées ou de vulnérabilités de sécurité non divulguées. L'utilisation de plates-formes open source n'est pas non plus une garantie de sécurité. Si nous nous appuyons sur des images de conteneurs tierces pour certaines parties de notre système, nous pouvons être vulnérables.

Emballer

Le paradigme de l'élevage est attrayant pour un certain nombre de raisons, mais il n'est pas sans inconvénients. Avant de se précipiter pour conteneuriser l'ensemble de la pile, les équipes techniques doivent se demander s'il s'agit ou non du bon choix et s'assurer qu'elles peuvent atténuer les effets négatifs.

Personnellement, j'aime travailler avec des conteneurs. J'ai hâte de voir où les choses iront dans les dix prochaines années à mesure que de nouvelles plates-formes et de nouveaux paradigmes apparaîtront. Cependant, en tant qu'ancien consultant en sécurité, je suis assez prudent pour savoir que tout a un prix. Il appartient aux ingénieurs de rester vigilants pour que nous ne renoncions pas à notre autonomie d'utilisateurs et de développeurs. Même le flux de travail CD/CI le plus simple au monde ne vaudrait pas le coût.