L'avenir de l'infrastructure sera conteneurisé

Alors que la plupart des entreprises et des start-up technologiques reposent aujourd'hui sur le cloud, nombre d'entre elles n'ont pas encore réalisé tous les avantages de cette technologie. Si vous êtes dans le cloud, mais pas sur Kubernetes, vous utilisez probablement des solutions propriétaires tout en créant et en gérant vos propres outils personnalisés supplémentaires. Vous laissez également de nombreuses options sur la table en termes d'efficacité, vous exécutez vos propres charges de travail sur des machines virtuelles (VM) sous-utilisées et vous limitez vos opportunités.

Combien d'outils utilisez-vous aujourd'hui pour gérer et corriger vos VM ? Comment mettez-vous à niveau vos applications ? Qu'en est-il de l'usage de vos VM ? Les solutions dont vous disposez ne sont peut-être pas aussi efficaces que prévu. Vous rencontrez des défaillances (indisponibilité, problèmes d'évolutivité, etc.) en raison des faiblesses présentes dans l'architecture de vos VM, les coûts deviennent incontrôlables ou votre infrastructure n'est pas configurée pour accepter les nombreuses opérations nécessaires à l'exploitation de votre entreprise telles que les suivantes :

• Refactorisation/transformation de l'architecture d'un produit minimum viable (MVP) en solution évolutive
• Intégration de fournisseurs de services cloud supplémentaires afin de répondre aux exigences réglementaires ou aux attentes des clients
• Expansion géographique pour réduire la latence et offrir une meilleure expérience à une large clientèle
• Amélioration de votre stratégie de sécurité de bout en bout
• Amélioration de l'expérience client (par exemple, la disponibilité du service)

Les systèmes hérités et la dette technique peuvent ralentir vos activités. C'est la raison pour laquelle nous pouvons observer cette tendance majeure à adopter Kubernetes. Une architecture moderne composée de conteneurs gérés vous donne accès à des modèles éprouvés pour exécuter une infrastructure fiable et sécurisée. Vous pouvez accélérer le délai de mise sur le marché et augmenter votre productivité sans compromettre la stabilité et la sécurité. De plus, vous bénéficiez d'autres avantages tels que l'attraction de meilleurs talents pour travailler sur l'innovation.

Vous devez également veiller à pouvoir tirer parti de la communauté Kubernetes et de son écosystème environnant, dont l'innovation constante définit les normes et les bonnes pratiques actuelles du secteur. Enfin, et ceci est encore plus important étant donné les défis actuels du recrutement, vous devez décider à quoi vos ingénieurs doivent consacrer leur temps : à la maintenance de l'infrastructure, à la création d'outils personnalisés et à leur maintenance, ou à votre liste de priorités opérationnelles qui permettront à votre entreprise de progresser ? Votre système fonctionne peut-être aujourd'hui, mais votre feuille de route inclut probablement des éléments que vous préféreriez ne pas avoir, comme rembourser la dette technique ou combler le manque de fonctionnalités de votre plate-forme dans les domaines suivants :

• Chiffrement de bout en bout
• Observabilité (journaux, métriques, journalisation automatique)
• Gestion et application des stratégies
• Haute disponibilité et basculement automatique
• Réduction des coûts

Kubernetes est une solution Open Source et indépendante de la plate-forme. Elle offre tous les outils courants permettant de sécuriser et d'accélérer chaque étape du cycle de compilation et de déploiement. C'est le fruit de tous les scripts Bash et bonnes pratiques concoctés par la plupart des administrateurs système au fil du temps et présentés comme un système sur lequel repose un ensemble d'API déclaratives. Dans cet environnement prêt à être utilisé, tout est automatisé et les détails sont masqués. Kubernetes peut éliminer la grande majorité de l'infrastructure en tant que code tout en faisant évoluer votre plateforme vers une infrastructure en tant que données. Vous n'avez pas besoin d'écrire ni de gérer du code. Vous indiquez à Kubernetes ce que vous voulez, et non pas ce qu'il faut faire. Vous réaliserez ainsi d'importants gains de temps pour la gestion.

Si vous souhaitez exécuter des charges de travail traditionnelles, vous pouvez le faire sur une plate-forme moderne avec Kubernetes en séparant les applications des VM et en les plaçant dans des conteneurs. L'adoption d'images de conteneur pour packager votre logiciel facilite la mise à niveau de vos VM. Vous pouvez à présent simplifier la gestion du cycle de vie des VM et celle des applications en simplifiant la VM par la suppression de tous les codes en Ruby, Python et Java. En outre, en déplaçant un conteneur là où il est nécessaire (à côté de l'application du développeur), vous pouvez le contrôler depuis un seul endroit et conserver vos machines bare metal.

Les plates-formes informatiques gérées transforment les services cloud en plates-formes en tant que service. Vous bénéficiez ainsi de la puissance et de la flexibilité des conteneurs d'une part, et de la commodité d'un modèle sans serveur d'autre part. Pas de serveur, pas de configuration de cluster, pas de maintenance : vous récoltez des avantages considérables tout en gardant le contrôle.

Pour les charges de travail qui ne nécessitent pas beaucoup de contrôle sur la configuration du cluster, vous pouvez laisser vos services provisionner et gérer l'infrastructure sous-jacente du cluster, y compris les nœuds et les pools de nœuds. Vous ne payez que la charge de travail et non le cluster. Ainsi, vous éliminez l'administration du cluster tout en optimisant la sécurité et vous pouvez économiser des sommes d'argent potentiellement importantes.

Si vous disposez davantage d'applications cloud natives, le modèle sans serveur accomplit les mêmes opérations avec moins de travail. Il élimine l'infrastructure sous-jacente et sert d'hôte de bout en bout pour vos applications, vos données et même vos analyses. Une plate-forme sans serveur vous permet d'exécuter des conteneurs dans un environnement entièrement géré avec un minimum de complexité et en intégrant la sécurité, les performances, l'évolutivité et les bonnes pratiques.

Passons en revue les implications potentielles pour votre activité et la manière dont vous pouvez aider votre entreprise à garder une longueur d'avance en termes d'efficacité.

Certaines entreprises considèrent qu'il est nécessaire de fonctionner sur plusieurs clouds. La gravité des données est réelle. Si vous disposez d'une clientèle internationale, vous vous retrouverez inévitablement à servir des clients qui veulent réduire leur latence et leurs frais de mise en réseau tout en conservant leurs ressources de calcul à proximité de l'emplacement où résident leurs données.

Dans de tels cas, le multicloud peut vous permettre de cibler un marché plus étendu. D'une manière ou d'une autre, vous continuerez de disposer des services gérés et des données d'autres fournisseurs. D'autres entreprises considèrent le multicloud comme une stratégie d'atténuation des risques. Dans les deux cas, l'essentiel consiste à adopter correctement le multicloud, et pour cela, les solutions standards de l'industrie peuvent vous aider.

Premièrement, assurez-vous de pouvoir continuer d'exploiter la majorité de vos workflows pour accomplir le plus de tâches possible. Les workflows vous permettent d'automatiser les tâches afin de créer l'architecture Dataflow entre la base de données et les ressources de calcul. C'est pourquoi l'Open Source est important : si vous sélectionnez une base de données qui n'est pas ouverte, vous aurez du mal à mettre en œuvre l'architecture et l'automatisation Dataflow. Il est préférable d'utiliser le protocole Postgres (par exemple,Cloud Spanner) ou une base de données Postgres gérée (par exemple,Cloud SQL) de n'importe quel fournisseur de services cloud.

Deuxièmement, en ce qui concerne les ressources de calcul, Kubernetes permet de gagner beaucoup de temps lors des déploiements et de l'automatisation. Par conséquent, lorsque vous choisissez un ensemble de technologies, assurez-vous qu'elles fonctionnent au-delà des limites définies par votre fournisseur. Les limites peuvent correspondre à différentes régions ou zones, à différents projets ou comptes, et même à un environnement sur site ou dans le cloud. Ne perdez pas de temps à créer et à gérer des infrastructures distinctes pour chaque fournisseur de services cloud (par exemple, une sur AWS, une sur Google et une autre sur Azure). Vos ingénieurs risquent de se retrouver submergés de travail en tentant de les maintenir toutes au même niveau. Si vous compilez une fois et déployez sur plusieurs clouds, vous pouvez effectuer des mises à jour de manière centralisée et cohérente. Les piles de calcul telles que Kubernetes offrent un avantage considérable aux clients qui souhaitent utiliser le multicloud d'une manière efficace et qui ne nécessite pas de réinventer la roue à chaque fois que vous souhaitez intégrer un nouveau fournisseur de services cloud.

Troisièmement : la gestion des risques. Le fait de pouvoir exécuter votre pile dans un autre environnement contribuera à limiter les risques liés aux interruptions chez votre fournisseur de services cloud ou empêchera ce dernier d'entrer en concurrence avec votre entreprise. Afin de se conformer aux réglementations, les entreprises choisissent des fournisseurs leur permettant d'assurer la continuité de leurs activités. Par exemple, si vous perdez des opérations dans une région, vous ne subirez aucun temps d'arrêt si vous disposez d'un fournisseur secondaire.

En général, les migrations multicloud efficaces sont celles qui utilisent des normes ouvertes. Prenons l'exemple de Kubernetes qui offre une API indépendante du fournisseur pour exécuter des applications, les configurer et les déployer, ou encore pour intégrer des règles telles que des règles de sécurité, la mise en réseau, etc. Considérez Kubernetes comme un système d'exploitation multicloud. Une fois qu'il constitue votre couche d'abstraction, vous pouvez généralement masquer les différences entre la plupart des principaux fournisseurs de services cloud.

Lorsque vous décidez d'utiliser Kubernetes, plusieurs possibilités s'offrent à vous. Vous pouvez l'exécuter vous-même, car Kubernetes est un projet Open Source. Vous pouvez donc le télécharger et passer des années à l'intégrer à votre fournisseur de services cloud ou à votre environnement préféré.

Toutefois, si vous estimez que cette option n'est pas la meilleure façon d'employer votre temps, vous pouvez opter pour une offre Kubernetes gérée. Si vous utilisez AWS, il s'agira d'EKS. Si vous utilisez Azure, ce sera AKS. Si vous utilisez Google Cloud, ce sera Google Kubernetes Engine (GKE). Toutes ces options fournissent une API Kubernetes commune. Ainsi, lorsque votre équipe compile ses outils et workflows, vous pouvez les réutiliser avec différents fournisseurs.

Cependant, toutes les offres de services gérés ne se valent pas. L'efficacité de Kubernetes dépend de la qualité de l'infrastructure sur laquelle il s'exécute. Quant à GKE, en tant que service d'orchestration mature et entièrement géré, il permet de combler les lacunes. Il propose des services IaaS entièrement intégrés, allant du provisionnement de VM à des VM Tau, offrant un rapport prix-performances 42 % supérieur à celui des offres comparables à usage général,¹ Autoscaling de plusieurs zones et des mises à niveau, la création et la gestion des GPU, des TPU pour le machine learning, des volumes de stockage et des identifiants de sécurité à la demande. Il vous suffit de placer votre application dans un conteneur et de choisir un système en fonction de vos besoins.

Que se passe-t-il si vous avez choisi AWS comme fournisseur de services cloud pour les VM ? Doit-on rester sur EKS ? En général, Kubernetes est équivalent pour tous les fournisseurs de services cloud. Vous vous retrouverez avec l'API Kubernetes. Mais sous cette API se trouvent un cluster, des nœuds de calcul, des règles de sécurité, et tout le reste. C'est en ce sens que GKE se distingue des autres environnements.

Par exemple, si vous avez encore besoin des autres clusters, vous pouvez les connecter à GKE Connect, ce qui vous permettra d'en centraliser la gestion, de les afficher, de les dépanner et de les déboguer tout en gérant de manière centralisée des éléments tels que les identifiants. GKE est la meilleure des plates-formes Kubernetes en raison de sa facilité de gestion de bout en bout et pas seulement en raison de son plan de contrôle ni de sa haute disponibilité multirégionale ou multirégionale. GKE peut également exploiter des équilibreurs de charge mondiaux grâce au service Multi C Ingressluster géré de manière centralisée sur plusieurs clusters et régions.

Vous souhaitez utiliser l'API Kubernetes sans avoir à payer le provisionnement, le scaling ou la mise à niveau des clusters ? Pour la majorité des charges de travail, GKE Autopilot élimine l'infrastructure sous-jacente du cluster, y compris les nœuds et les pools de nœuds, et vous ne payez que pour la charge de travail. Le but de GKE Autopilot est de fournir l'API Kubernetes standard avec tous les paramètres de sécurité par défaut pour vous permettre de vous concentrer sur vos charges de travail et non sur le cluster.

__________________________

¹ Les résultats sont basés sur une estimation de l'exécution de SPECrate®2017_int_base sur des VM de production de deux autres fournisseurs de services cloud leaders du marché et sur des VM Tau de préproduction Google Cloud, à l'aide de compilateurs recommandés par les fournisseurs. SPECrate est une marque de l'organisme Standard Performance Evaluation Corporation. Pour en savoir plus, consultez le site www.spec.org.

Kubernetes a permis aux entreprises de passer des VM à un nouvel ensemble d'abstractions qui vous permettent d'automatiser vos opérations et de vous concentrer sur vos applications. Toutefois, pour des charges de travail plus spécifiques (par exemple, les applications Web et mobiles, les API REST de backend, le traitement des données ou l'automatisation des workflows), vous pouvez simplifier encore davantage votre déploiement et l'optimiser en exploitant le modèle sans serveur.

Vous utilisez peut-être AWS Lambda, une plate-forme sans serveur couramment utilisée qui vous permet d'écrire des fonctions en tant que service et de les connecter à tous les types d'événements. Cependant, étant donné que vous vous connectez à une base de données et que vous gérez des problèmes de sécurité, ces fonctions ont tendance à devenir de plus en plus complexes, certaines étant même plus complexes que les applications normales. Que se passe-t-il lorsqu'une application dépasse la simplicité d'une fonction en tant que service ou si vous souhaitez exécuter une application existante en mode sans serveur ?

Contrairement à une plate-forme sans serveur traditionnelle qui nécessite de réécrire vos applications, Cloud Run vous permet de réutiliser vos applications existantes conteneurisées. Même si GKE est un service géré, vous devez tout de même prendre des décisions clés : les zones dans lesquelles exécuter les charges de travail, l'emplacement de stockage des journaux, comment gérer le trafic entre différentes versions d'applications, les noms de domaine enregistrés ou encore la gestion des certificats SSL.

Cloud Run élimine toutes ces décisions, ce qui vous permet d'exécuter des charges de travail plus traditionnelles et d'éviter les démarrages à froid en désactivant entièrement le scaling à zéro instances. Si vos applications doivent toujours s'exécuter, Cloud Run accepte également ce cas de figure, ainsi que d'autres exigences traditionnelles telles que les NFS, les WebSockets et les intégrations VPC. Toutefois, comme la plupart des plates-formes sans serveur traditionnelles, Cloud Run est avisé et offre des fonctionnalités telles que la gestion intégrée du trafic et l'autoscaling.

Supposons que vous n'utilisiez pas du tout les conteneurs et que vous vous demandiez par où commencer. Voici une approche pragmatique pour adopter la conteneurisation.

La première raison d'adopter les conteneurs est la résolution du problème de packaging. Aujourd'hui, on travaille beaucoup sur la production d'artefacts reproductibles et la compréhension de ce qui entre en jeu dans la création de nos logiciels ou, ce que l'on appelle la "chaîne d'approvisionnement logicielle sécurisée" dans notre secteur. Nous pensons que la méthode idéale consiste à exploiter des images de conteneurs qui contiennent le code d'application et les environnements d'exécution, ainsi que leurs dépendances. L'un des avantages de travailler avec des conteneurs, c'est que l'on peut les déployer sur des VM, ce qui réduit la complexité du déploiement et de la maintenance des logiciels sur vos machines.

La deuxième raison d'adopter les conteneurs est l'orchestration. La gestion des VM implique une multitude de tâches de gestion et de maintenance. Comme la plupart des entreprises, votre équipe passe par des dizaines, voire des centaines d'étapes pour gérer votre infrastructure. Même si ces étapes sont automatisées, ces outils d'automatisation nécessiteront tout de même une maintenance continue, même en supposant que vous utilisiez les outils d'automatisation standards du secteur tels que Terraform, Puppet, Chef ou Ansible. Pour les outils développés en interne ou personnalisés, la surcharge liée aux opérations de maintenance est encore plus importante.

La troisième raison d'adopter les conteneurs est l'efficacité. En plus du fardeau de la maintenance, la majorité des organisations n'atteignent que 5 à 10 % d'utilisation du processeur, sans oublier la mémoire et l'espace de stockage. Cela représente un important gaspillage de ressources. Pour combler ce fossé, de nombreuses équipes créent des outils encore plus personnalisés en mettant en œuvre des éléments comme l'autoscaling et le bin-packing, ce qui dilapide encore plus le temps d'exploitation. Il en résulte des dépenses excessives et une facture cloud étonnamment élevée.

Très peu d'entreprises parviennent à créer leur propre plate-forme d'orchestration. C'est pourquoi l'utilisation d'une plate-forme Open Source comme Kubernetes, Mesos ou Nomad est un choix répandu. Toutefois, si vous recherchez une plate-forme qui vous permet d'obtenir certains avantages tels qu'une maintenance réduite, les bonnes pratiques du secteur et une intégration approfondie avec les autres services de votre fournisseur cloud, vous devrez choisir un service géré comme GKE pour maximiser la valeur potentielle de vos conteneurs.

À ce stade, vous vous demandez peut-être si la migration vers des conteneurs ne génère pas d'importants temps d'arrêt sans apporter de valeur réelle. La dernière chose à faire, c'est de cliquer sur le bouton "Pause" en ce qui concerne les futurs projets de développement, n'est-ce-pas ?

Pour répondre à cette question, expliquons comment migrer de manière à optimiser votre expérience cloud.

Il peut paraître difficile de déplacer vos applications des VM vers des conteneurs en particulier si le transfert de vos ressources de calcul vers un nouveau fournisseur de services cloud est impossible. Mais en réalité, vous n'avez pas besoin de tout déplacer en bloc. Vous pouvez le faire une application à la fois, en commençant par les VM, puis en déplaçant une ou deux applications vers Kubernetes, où elles peuvent fonctionner côte à côte sur le même réseau et communiquer avec les VM. Inutile d'adopter une transition globale. Vous pouvez vous procéder progressivement d'une plate-forme à l'autre.

Laisser quelques applications sur les VM peut sembler judicieux, telles que les bases de données volumineuses qui ne bénéficieraient que très peu de Kubernetes. Cela ne pose aucun problème. Vous pouvez combiner les deux. Toutefois, nous avons constaté que la plupart des clients passent à la vitesse supérieure lorsqu'ils migrent leurs applications et leurs projets Open Source vers Kubernetes. Vous pouvez prioriser les applications qui produiront les meilleurs résultats en passant sur GKE. Vous n'avez pas besoin de tout déplacer en même temps.

Kubernetes s'exécute toujours sur les mêmes VM Linux que celles que vous utilisez probablement aujourd'hui. Ce que vous obtenez, en réalité, est un workflow simplifié et cohérent qui intègre de nombreux éléments qui figurent sans doute sur la feuille de route de votre infrastructure, au lieu d'un ensemble de scripts développés en interne et l'automatisation. L'intégration de nouveaux membres dans votre équipe devient également beaucoup plus simple lorsque vous utilisez un outil standard dans l'industrie comme Kubernetes, plutôt que d'avoir à leur apprendre toutes les méthodes personnalisées dont votre entreprise dispose.

À ce stade, vous avez préparé le terrain pour adopter progressivement les conteneurs, mais de manière pragmatique, permettant ainsi à votre équipe de gagner du temps en termes d'administration et à votre entreprise d'économiser des coûts de calcul.

Nous avons beaucoup parlé de conteneurs et migration vers le cloud. Que vous décidiez d'utiliser Kubernetes ou que vous recherchiez une meilleure offre ou une approche différente qui corresponde à vos applications et à votre feuille de route actuelle,

ou quel que soit votre parcours de développement d'applications, les conteneurs gérés minimisent les coûts de votre infrastructure tout en optimisant la capacité de votre équipe à se concentrer sur la création de produits de qualité. L'avenir de l'infrastructure est la conteneurisation. Il est temps d'équiper vos ingénieurs et votre entreprise de solutions aussi performantes que possible. 

De Kubernetes au cloud natif : lancez-vous dans le développement sur GKE

Des conteneurs dans le cloud : une meilleure façon de développer et de déployer des applications

Toute l'histoire de Kubernetes retracée par Eric Brewer

Modifier l'architecture pour un développement cloud natif : une approche évolutive qui accroît la productivité des développeurs à grande échelle