Bienvenue dans le premier d'une série de quatre articles traitant de la conteneurisation et du mouvement cloud natif dirigé par Docker, Google et un écosystème en plein essor d'acteurs traditionnels et nouveaux. Dans cette série, nous nous aventurons à définir et à discuter de cet espace émergent et passionnant dans le but d'aider les organisations à mieux s'y retrouver. Alors que ce premier article se concentrera sur la définition du "cloud natif" et de certaines parties mobiles associées, dans les prochains articles, nous explorerons les couches importantes et les défis associés à la mise en réseau, au stockage et à l'orchestration des conteneurs pour vous donner une vue plus complète... mais commençons d'abord par le début.
Bienvenue dans le premier d'une série de quatre articles traitant de la conteneurisation et du mouvement cloud natif dirigé par Docker, Google et un écosystème en plein essor d'acteurs traditionnels et nouveaux. Dans cette série, nous nous aventurons à définir et à discuter de cet espace émergent et passionnant dans le but d'aider les organisations à mieux s'y retrouver. Alors que ce premier article se concentrera sur la définition du "cloud natif" et de certaines parties mobiles associées, dans les prochains articles, nous explorerons les couches importantes et les défis associés à la mise en réseau, au stockage et à l'orchestration des conteneurs pour vous donner une vue plus complète... mais commençons d'abord par le début.
Au début, il y avait FreeBSD et Solaris, qui ont jeté les bases de ce qui est maintenant considéré comme des technologies de conteneurisation modernes avec des capacités appelées respectivement FreeBSD Jails et Solaris Zones. Google a aidé à apporter des conteneurs à Linux en ajoutant des cgroups au noyau Linux. Combiné avec des espaces de noms et chroot, les bases techniques ont été posées. Docker a en outre rendu les conteneurs plus accessibles en créant un flux de travail simple autour des images de conteneur et en se concentrant sur une expérience de développeur simple.
La meilleure façon de définir l'espace est probablement de répondre à certaines questions fondamentales et de demander à des experts invités d'y répondre. (voyez comment je décharge le travail sur d'autres personnes plus qualifiées ! ?)
Qu'est-ce qu'un conteneur ?
Contributeur invité Cameron Brunner, architecte en chef Navops
Les conteneurs permettent aux applications d'être déplacées de manière fiable d'un environnement informatique à un autre. Cela peut aller de l'ordinateur portable d'un développeur à l'environnement QA en passant par la production sur site ou dans le cloud. Les dépendances de la pile logicielle de l'application exécutée dans le conteneur, telles que le système d'exploitation ou d'autres composants logiciels et bibliothèques, peuvent être en grande partie intégrées à l'intérieur d'un conteneur, ce qui lui permet de s'exécuter indépendamment des détails de l'environnement informatique sous-jacent. Les conteneurs ont été initialement conçus pour fournir une isolation entre les applications exécutées sur un système d'exploitation. Ils fournissent une combinaison de contrôles de ressources et de séparation des limites qui aide à isoler l'exécution du code dans le conteneur des autres activités et des autres conteneurs qui s'exécutent sur cette machine/système d'exploitation. Les conteneurs réalisent cette isolation en tirant parti des fonctions du système d'exploitation telles que les cgroups et les espaces de noms.
Qu'est-ce que Docker?
Docker est à la fois une entreprise et une implémentation commerciale/open source de conteneurs. Les conteneurs existent depuis longtemps avant Docker avec les premières implémentations telles que FreeBSD Jails (2000) et Solaris Zones (2004) et Docker a fait un travail fabuleux en rendant les conteneurs utiles pour les masses en simplifiant considérablement le processus de création et d'exécution. Alors que Docker devient rapidement le format de conteneur standard de facto, la société a fait de nouveaux pas vers l'ouverture et la collaboration en créant l'Open Container Initiative (OCI) sous la Linux Foundation. OCI implique un certain nombre de participants de l'industrie et travaille à l'élaboration de normes de l'industrie pour les formats de conteneurs et les durées d'exécution. (Voir www.opencontainers.org/)
Alors, qu'est-ce que le Cloud Native Computing ?
Contributeur invité Joe Beda, fondateur et contributeur à la fois de Google Compute Engine et de Kubernetes
Cloud Native est l'une des nombreuses nouvelles façons de penser à la création et à la gestion d'applications à grande échelle. À la base, Cloud Native structure les équipes, la culture et la technologie pour utiliser l'automatisation et les architectures pour gérer la complexité et débloquer la vitesse.
Alors que les conteneurs et la gestion des conteneurs font souvent partie de la pensée "Cloud Native", des organisations telles que Netflix ont appliqué cette pensée avec des VM et des images de VM. De plus, vous n'avez pas besoin d'exécuter dans le Cloud pour commencer à tirer parti de ce changement de mentalité. Les applications et les équipes peuvent être plus faciles à gérer lors du déploiement d'applications sur site.
Il n'y a pas de règles strictes pour ce qu'est Cloud Native. Cependant, certains thèmes émergent.
- Automatisation DevOps et Ops : les ingénieurs portant la casquette de développeur d'applications jouent un rôle actif en s'assurant que les applications peuvent s'exécuter de manière fiable en production. De même, ceux qui remplissent le rôle des opérations s'assurent que les expériences se répercutent sur le développement. L'automatisation est essentielle pour gérer de nombreuses pièces en mouvement.
- Conteneurs : les conteneurs offrent un moyen pratique de créer un artefact de build déployable qui peut être testé et validé. Cela garantit que les déploiements sont prévisibles.
- Clusters de calcul : un cluster de calcul piloté par API et un système de planification permettent à un petit nombre d'ingénieurs de gérer un grand nombre de charges de travail. Au-delà de cela, cela permet à ces charges de travail d'être efficacement regroupées sur les nœuds afin d'augmenter les taux d'utilisation. Enfin, un cluster bien géré réduit la charge des opérations pour les équipes d'application.
- Microservices : les microservices divisent les applications en unités déployables plus petites afin que les équipes de développement puissent être rapides et agiles. Ces idées ne sont pas nécessairement nouvelles, mais sont appliquées de concert avec des outils pour permettre une gestion évolutive. Nous en reparlerons plus bas.
- Visibilité approfondie : Cloud Native implique des informations plus approfondies sur le fonctionnement des services. Le traçage distribué, la collecte et l'indexation des journaux et la surveillance approfondie des applications aident à mettre en lumière ce qui se passe réellement à l'intérieur d'une application.
Qu'est-ce qu'une architecture basée sur des micro-services ?
Contributeur invité Joe Beda, fondateur et contributeur à la fois de Google Compute Engine et de Kubernetes
Les microservices sont un nouveau nom pour un concept qui existe depuis très longtemps. Fondamentalement, c'est un moyen de diviser une grande application en plus petits morceaux afin qu'ils puissent être développés et gérés indépendamment. Examinons ici certains des aspects clés :
- Interfaces solides et claires. Les couplages étroits entre les services doivent être évités. Des interfaces documentées et versionnées aident à solidifier ce contrat et à conserver un certain degré de liberté tant pour les consommateurs que pour les producteurs de ces services.
- Déployé et géré indépendamment. Il devrait être possible de mettre à jour un seul microservice sans se synchroniser avec tous les autres services. Il est également souhaitable de pouvoir restaurer facilement une version d'un microservice. Cela signifie que les fichiers binaires déployés doivent être compatibles en amont et en aval à la fois en termes d'API et de schémas de données. Cela peut tester les mécanismes de coopération et de communication entre les équipes opérationnelles et de développement appropriées.
- Résilience intégrée. Les microservices doivent être créés et testés pour être indépendamment résilients. Le code qui consomme un service doit s'efforcer de continuer à fonctionner et de faire quelque chose de raisonnable dans le cas où le service consommé est en panne ou se comporte mal. De même, tout service offert devrait avoir des défenses en ce qui concerne la charge imprévue et les mauvaises entrées.
- Les microservices concernent davantage les personnes que la technologie. Les petites équipes sont plus agiles. Jeff Bezos est célèbre pour avoir suggéré de garder les réunions et les équipes suffisamment petites pour qu'elles puissent être nourries avec 2 pizzas. En structurant un grand projet en une série d'équipes plus petites, puis en s'écartant, ces équipes peuvent fusionner et s'approprier cette partie du projet.
Nous attendons avec impatience les prochains articles où nous discuterons de certaines des couches importantes de la pile cloud native.
Rob Lalonde est vice-président et directeur général de Navops. Il participe activement à diverses fondations open source, notamment la Cloud Native Computing Foundation (CNCF), l'Open Container Initiative (OCI) et la Linux Foundation. Rob a occupé des postes de direction dans plusieurs entreprises de haute technologie et startups prospères. Il a terminé des études de MBA à la Schulich School of Business de l'Université York et est titulaire d'un diplôme en informatique de l'Université Laurentienne.
Inscrivez-vous à la newsletter StorageReview
