Infrastructure multilingue en tant que code – Bien choisir son serveur d impression

Transcription

Duffy: Je suis très heureux de parler de notre approche de l'infrastructure en tant que code et de certaines des choses que nous avons apprises au cours des deux dernières années. Je vais essayer de vous convaincre tous que l’infrastructure n’est pas aussi ennuyeuse que l’on pourrait le penser. En fait, apprendre à programmer une infrastructure est l’une des choses les plus stimulantes et les plus stimulantes en tant que développeur que nous puissions apprendre à faire, en particulier à l’ère du cloud moderne. Je vais commencer par vous parler un peu de mon parcours, de la raison pour laquelle je suis devenu un code d'infrastructure, pourquoi je suis si enthousiaste à ce sujet. Je vais parler un peu de la situation actuelle et du travail que nous avons fait pour essayer d'améliorer la situation.

Premièrement, pourquoi l'infrastructure en tant que code? Quand je verrai l'expression «infrastructure en tant que code», j'admettrai que cela ne m'excite pas, même s'il s'agit d'une technologie importante à avoir dans votre ceinture d'outils. La raison pour laquelle, lorsque je le sépare, mon expérience est en tant que développeur. Je suis arrivé dans le cloud en empruntant des itinéraires très différents de ceux d'ingénieurs en infrastructure, ce qui m'a donné une perspective différente de l'espace. J’ai commencé ma carrière et j’ai fait quelques choses avant d’aller chez Microsoft, mais je pense que la période la plus excitante de ma carrière a été celle de Microsoft, où j’étais un ingénieur débutant du framework .NET et du langage de programmation C #. Années 2000

J'ai beaucoup travaillé sur la programmation multicœur et la concurrence, j'ai créé l'équipe chargée de la structure des tâches et d'Async, qui a finalement conduit à Await. Ensuite, j'ai travaillé sur un système d'exploitation distribué, ce qui m'a ouvert les yeux lorsque je suis passé au cloud, car une grande partie de ce que nous avons fait prévoyait des maillages de surface et des conteneurs, ainsi que la façon de gérer ces systèmes à grande échelle et de les programmer. Puis, avant de quitter Microsoft, je gérais l’équipe des langages, donc les services de langage C #, C ++, F # et l’EDI. Ce qui m’a vraiment fait entrer dans le cloud, c’était la prise de .NET open source et multiplate-forme. C’est pourquoi Microsoft a fait cela pour faire d’Azure un lieu plus accueillant pour les clients .NET souhaitant exécuter des charges de travail sous Linux dans des charges de travail conteneurisées en particulier.

Cela n’était peut-être pas évident de l’extérieur, c’était la motivation, mais aujourd’hui, cela fonctionne vraiment bien avec .NET Core et Azure. Quoi qu’il en soit, cela m’a apporté l’utilisation pratique des listes de serveurs et des conteneurs et je me suis vraiment excité. Je savais depuis un moment que je voulais faire une startup et chaque année, je me demandais: "Est-ce l'année?" J'ai vu que tout avec le cloud modifiait notre façon de faire le développement de logiciels et j'ai donc vu une énorme opportunité. Je ne savais pas qu'il s'agirait d'une infrastructure sous forme de code avant de m'y mettre à fond, mais le principe de départ était que tous les développeurs sont ou vont bientôt devenir des développeurs cloud.

Quand on pense aux processeurs de Word dans les années 90, on ne construit plus ce logiciel. Même s'il s'agit d'un traitement de texte, il se connecte au cloud d'une manière ou d'une autre pour effectuer une vérification orthographique ou une intelligence artificielle, l'apprentissage automatique, le stockage, le stockage dans le cloud. Fondamentalement, si vous êtes un développeur aujourd'hui, vous devez comprendre comment tirer parti du cloud, quel que soit le contexte. Même si vous êtes principalement sur site, beaucoup de gens cherchent à utiliser les technologies de cloud computing sur site pour innover plus rapidement.

En tant que développeur, si je viens dans le cloud, pourquoi je me soucie de cette infrastructure? Si je remontais 15 ans en arrière, j'irais classer un ticket et mon équipe informatique s'en chargerait et je n'aurais pas à penser au fonctionnement des machines virtuelles ni au fonctionnement du réseau ou autre chose du genre. C'était pratique, mais ce sont des temps plus simples.

L'architecture en nuage moderne de Google dans AWS à gauche et dans Azure à droite; vous remarquerez qu'il y a beaucoup de blocs de construction. Tous ces blocs de construction sont des ressources programmables dans le cloud. Si vous pouvez savoir comment relier ces éléments entre eux et comprendre réellement comment construire des systèmes à partir de ceux-ci, vous pouvez réellement renforcer votre capacité à fournir des logiciels innovants dans un environnement cloud moderne.

Architectures Cloud modernes

Je vais parler un peu de la situation actuelle. J'ai passé beaucoup de temps à réfléchir, "Comment pouvons-nous arriver là où nous sommes aujourd'hui, où nous sommes à mi-chemin dans YAML?" Pour chaque fonction sans serveur que vous écrivez, vous avez un nombre équivalent de lignes de YAML à écrire qui sont si difficiles à retenir que vous devez toujours les copier et les coller quelque part ou que vous devez compter sur quelqu'un d'autre pour le faire. Si nous avançons rapidement dans les années 2000 et que la virtualisation était un gros problème, nous avons commencé à virtualiser des applications, nous avons pris nos applications de niveau final, nous les avons généralement virtualisées en demandant à nos responsables informatiques et opérationnels de les configurer. des choses. C'était une boîte noire, vous n'aviez pas à y penser. C'était correct car ils étaient trop nombreux. Peut-être que vous aviez une application dans un back-end MySQL ou peut-être que vous aviez un front-end, un mid-tier et une base de données.

Les choses sont généralement fixes, elles sont assez statiques, alors vous diriez: "Je pense que j'ai besoin de trois serveurs pour les cinq prochaines années", puis vous achetez ces serveurs, vous payez 2 500 dollars amortis sur trois ans pour chacun de ces serveurs. et c'est comme ça que ça fonctionnait. Je dirais que le Cloud 2.0, pour moi, est vraiment le changement d'état d'esprit qui consiste à passer de charges de travail statiques à des charges de travail dynamiques, où au lieu de provisionner des éléments et de penser qu'ils resteront fixes pendant cinq ans – les choses changent -, tout à coup, vos applications beaucoup plus populaire que vous ne le pensiez ou peut-être moins populaire. Peut-être qu’avec une initiative informatique majeure pour un nouveau système de ressources humaines, puis tout à coup, ils ont décidé d’utiliser Google Hire ou quelque chose qui n’était plus nécessaire, à présent trois ordinateurs virtuels coûtent de l’argent inutilisé.

Nous avons adopté ce modèle de services plus hébergés, d’infrastructure plus dynamique et plus flexible. Nous passons de 1 à 10 ressources dans le monde du Cloud 1.0 à une vingtaine peut-être dans le monde 2.0. Désormais, lorsque vous pensez à une application AWS moderne, vous gérez des rôles de messagerie instantanée, vous gérez des ressources de données, qu'il s'agisse de bases de données NoSQL hébergées ou de bases de données RDS. Vous exécutez des fonctions sans serveur, des conteneurs, des orchestrateurs de conteneurs si vous utilisez Kubernetes, des diagnostics, une surveillance. Il y a beaucoup de choses à penser et chacune de ces choses doit être gérée et a une vie propre et, idéalement, elle n'est pas figée dans son ampleur.

Vous souhaitez pouvoir évoluer de manière essentiellement dynamique à mesure que vos charges de travail évoluent. Je pense que l'ancienne approche consistant à jeter les choses par-dessus le mur et à les configurer, nous avons essayé de l'appliquer à ce nouveau monde et cela a simplement conduit à cette explosion de YAML qui rend tout le monde dingue.

Nous avions l'habitude de penser au cloud comme une réflexion après coup: "Nous allons développer notre logiciel, puis nous allons voir comment l'utiliser plus tard." De nos jours, le cloud est simplement intégré à tous les aspects de l'architecture de votre application. Vous allez utiliser une passerelle API, vous devez réfléchir à la manière dont fonctionnent les itinéraires, au middleware et à l'authentification. De nombreux aspects sont profondément ancrés dans votre application et vous souhaitez rester un peu flexibles, en particulier si vous envisagez des solutions multi-cloud ou si vous envisagez de modifier votre architecture à l'avenir. Vous ne voulez pas forcément prendre des dépendances difficiles, mais honnêtement, pour bon nombre de personnes qui essaient simplement d’agir rapidement et de proposer des innovations, la bonne approche consiste simplement à adopter le cloud et à l’utiliser dans toute l’application.

Le système d'exploitation en nuage

Il y a un autre domaine dans lequel je suis peut-être fou, je pense aux choses un peu différemment par rapport à la plupart des gens, mais je pense au cloud car c'est vraiment un nouveau système d'exploitation.

Il y a plus de 10 ans, lorsqu'ils ont lancé l'opération Azure chez Microsoft, l'entreprise s'appelait alors Red-Dog. Dave Cutler, qui était l’architecte en chef de Windows NT, décrivait cela comme un système d’exploitation en nuage et tout le monde pensait qu’il était fou, personne ne savait ce qu’il voulait dire. Je pense qu'il l'a vraiment vu en réfléchissant à ce que fait un système d'exploitation. Il gère les ressources matérielles, qu’il s’agisse du réseau de la CPU ou du disque mémoire. Il gère de nombreuses demandes concurrentes et détermine comment les planifier. Il sécurise l'accès à ces ressources et, surtout, pour les développeurs d'applications, il vous donne les primitives dont vous avez besoin pour créer vos applications.

Il s'avère que si vous remplacez simplement l'expression système d'exploitation par cette expression, dans tout cela, avec le nuage, c'est essentiellement ce que le nuage fait. Il fonctionne juste à une granularité différente. La granularité d'un système d'exploitation traditionnel est une machine unique. Bien sûr, il existe des systèmes d'exploitation distribués, mais la plupart d'entre eux ne se sont jamais vraiment arrêtés dans la recherche, ils sont fascinants, mais la plupart des systèmes d'exploitation auxquels nous pensons, qu'il s'agisse de Linux, de Mac ou de Windows, sont en réalité une seule machine. déménageons vers plusieurs machines. Au lieu que le noyau appelle tous les plans. Si vous vous souvenez du programme de contrôle principal de «Tron», il s’agissait du noyau, eh bien, c’est maintenant le plan de contrôle du cloud.

Le périmètre est différent, vous songez maintenant à un cloud privé virtuel plutôt qu’à un seul ordinateur doté d’un pare-feu. Il continue, processeurs et threads, ou processus et threads contre conteneurs et fonctions VM. C’était une autre perspective lorsque vous abordiez l’espace en arrière-plan des langages. Vous examinez la programmation asynchrone et tout ce que nous pouvons faire avec les pools de threads, puis les fonctions sans serveur. Il existe certainement une analogie intéressante: "Ne serait-il pas formidable que les fonctions sans serveur soient aussi faciles à programmer que les threads et les pools de threads en Async dans votre langue préférée?"

Gestion de l'infrastructure

Cela commence à me faire parler d’infrastructure en tant que code. Fondamentalement, vous passez d'un monde de pensées dans vos programmes d'allocation d'objets du noyau. Peut-être que vous allouez un fichier ou un fil de discussion ou quels que soient les objets que vous utilisez dans votre langage de programmation. À présent, vous vous demandez comment associer de nombreuses ressources d'infrastructure pour créer des applications. Vous songez maintenant aux réseaux et aux machines virtuelles, aux clusters et aux conteneurs Docker, ainsi qu’à tous les stockages de données nécessaires pour alimenter votre application.

Je pense que lorsque vous arrivez ici, lorsque vous vous dites: "Je veux créer une application cloud", l'approche initiale pour la plupart des gens est la suivante: "Je vais entrer dans AWS, Azure, Google Cloud, DigitalOcean", quel que soit votre choix. fournisseur de cloud est, allez dans la console, pointez et cliquez pour dire: "Donnez-moi un cluster Kubernetes, donnez-moi des fonctions sans serveur", tout ce dont vous avez besoin. Tout d’abord, il est très facile de se mettre en marche. Si vous ne savez pas à l'avance ce que vous voulez, vous pouvez cliquer, il existe une bonne documentation et des visualisations qui vous guident dans la bonne direction, mais le problème, c'est que ce n'est pas répétable. Si vous construisez toute votre infrastructure en pointant et en cliquant dans l'interface utilisateur, que se passe-t-il lorsque vous souhaitez mettre en service une instance intermédiaire de celle-ci? Ou peut-être souhaitez-vous opter pour la réplication géographique, vous devez maintenant disposer de plusieurs instances de votre environnement de production. Ou que se passe-t-il si quelque chose est détruit?

Quelqu'un entre par inadvertance dans l'interface utilisateur et pense que le compte de test contient des données. Il dit «Supprimer tout», puis se rend compte que «c'était en cours de production». Cela se produit plus souvent que vous ne le pensez. Ce n'est pas non plus révisable. Vous ne pouvez pas entrer dans une équipe et revoir le code, vous ne pouvez pas dire: "Est-ce que je le fais correctement?" à moins que quelqu'un se place sur votre épaule. Ce n'est pas versionable, donc si vous avez besoin d'évoluer, vous allez faire des changements d'état non répétables d'un état inconnu à un autre état inconnu.

La prochaine étape consiste à adapter les scripts à la plupart des utilisateurs. Tous ces fournisseurs de cloud ont des kits de développement logiciel (SDK), ils ont une interface de ligne de commande (CLI), de sorte que vous pouvez toujours utiliser le script Bash comme moyen de sortir de tout, ce qui est légèrement plus reproductible. Vous avez maintenant un script – et je montrerai dans quelques diapositives la différence, mais ce n’est pas aussi fiable. Si vous êtes une infrastructure de provisioning et que vous avez 30 commandes différentes à exécuter pour ne pas avoir une infrastructure configurée pour avoir un environnement complet, réfléchissez à tous les points de défaillance possibles et à la récupération. ? Si elle échoue à l'étape 33, est-ce la même chose que si elle échouait à l'étape 17? Est-ce automatisable? Pouvez-vous récupérer de cela? Les réseaux ont des problèmes de temps en temps, les fournisseurs de cloud computing de temps en temps, ce n'est donc pas une manière résiliente de faire les choses.

En règle générale, le cycle de vie d'une organisation commence par un point et par un clic, se transforme en scripts, puis aboutit éventuellement sur une infrastructure sous forme de code. Dans l'infrastructure en tant que code, vous connaissez probablement certaines technologies, comme AWS. La plupart des fournisseurs de cloud disposent de leurs propres ressources. AWS dispose donc d'une formation sur le cloud, Azure propose des modèles de Resource Manager, Google de Deployment Manager et HashiCorp de Terraform, un outil polyvalent qui couvre tous ces domaines. Je vais parler un peu de Kubernetes, ce n’est pas un discours de Kubernetes, mais je mentionnerai quelques points.

Kubernetes lui-même utilise également une infrastructure en tant que modèle de code dans la manière dont elle applique la configuration. L'infrastructure en tant que code est donc en gros le moyen convenu de créer une infrastructure robuste pour les applications.

Qu'est-ce qu'une infrastructure en tant que code? Infrastructure en tant que code vous permet de déclarer en substance vos ressources cloud – toutes les ressources cloud (clusters, bases de données) – dont votre application a besoin en utilisant du code. L'infrastructure en tant que code n'est pas une nouveauté, elle existe depuis un moment. Chef et Puppet ont utilisé l'infrastructure comme code pour la configuration de machines virtuelles, ce qui ressemble davantage à la période de cloud 1.0, 2.0 si vous revenez à mes diapositives précédentes.

L’infrastructure déclarative en tant que code, que tous ceux que je viens de mentionner, appartiennent à cette catégorie, et non à Chef et Puppet, à la Formation Cloud, à Terraform, etc. L’idée est de prendre ces déclarations et de les utiliser pour dire: "C’est un objectif état, il s'agit d'un état dans lequel le développeur souhaite exister dans le cloud. " Ils veulent une machine virtuelle, un cluster Kubernetes, 10 services sur ce cluster Kubernetes, une base de données hébergée et peut-être des enregistrements DNS. C’est une configuration que vous appliquerez ensuite. Vous devez donc attribuer cette valeur à votre infrastructure en tant que moteur de code. Elle dit: «OK, c’est ce que veut le développeur. se produire." C'est essentiellement une approche déclarative pour énoncer ce que vous souhaitez.

La bonne chose à propos de cela est que si cela dérive, si quelque chose change jamais, vous avez toujours une trace de ce que vous pensiez exister dans votre nuage et ce sera beaucoup plus clair si nous entrons dans quelques exemples supplémentaires.

Supposons que nous voulions faire tourner une machine virtuelle dans Amazon, puis en sécuriser l'accès, afin de permettre uniquement l'accès sur le port 80, l'accès HTTP. Le côté gauche est un script très simple. Si nous voulions simplement écrire quelque chose à l'aide de la CLI d'Amazon, cela fonctionnerait. Vous remarquez que nous devons prendre l'ID qui est retourné d'une unité et le transmettre à une autre commande. Encore une fois, il ne s'agit que de trois commandes individuelles. Ce n'est donc pas terriblement compliqué, c'est une chose raisonnable à faire.

Au fur et à mesure que votre équipe grandit, au fur et à mesure que de plus en plus de personnes contribuent, avec 100 ressources au lieu de 3, vous pouvez imaginer comment cela se résorbe, vous obtenez une multitude de scripts bash. Pour ce qui est de mon point précédent, si quelque chose échoue, il n’est pas toujours évident de savoir comment reprendre là où vous vous êtes arrêté. Sur le côté droit, c'est Terraform, qui accomplit pratiquement la même chose, mais vous remarquerez que c'est déclaratif. Au lieu de passer la région pour chaque commande, nous disons: "Pour AWS, utilisons la région USA Est 1." Pour le serveur Web, voici le nom de l'image, je veux vous apprendre le micro qui est très bon marché et petit. Je vais utiliser ce script à partir d'ici.

Remarquez ici que nous commençons à entrer un peu dans les langages de programmation, mais ce n'est pas vraiment un langage de programmation complet, car nous disons en gros "Déclarez que nous lisons dans ce fichier". Vous pouvez le lire, c'est raisonnable. Ensuite, vous prenez ceci et vous le donnez à Terraform et Terraform s'en va et fournit toutes les ressources pour vous.

Chaud ça marche

Je le mentionnerai car tous les outils que j'ai mentionnés pour l'infrastructure déclarative en tant que code fonctionnent de la même manière. En fait, les contrôleurs Kubernetes fonctionnent de la même manière en ce qui concerne l’application de la configuration. L'idée est que vous preniez un programme écrit dans du code, qu'il s'agisse de YAML, de JSON, de Terraform HCl ou que nous verrons plus tard ce que Pulumi apporte à la table, c'est la possibilité d'utiliser n'importe quel langage de programmation.

Vous transmettez ce code à une infrastructure en tant que moteur de code et vous obtiendrez tout ce que j'ai mentionné plus tôt, ce qui signifie: "Que pensez-vous de l'état actuel du cloud et quel est l'état souhaité que le code nous indique? immediatement?" Peut-être que l'état est vide parce que nous ne l'avons jamais déployé auparavant et que tout ce que le code veut devenir sera une nouvelle ressource. Ce n’est peut-être pas la première fois. Nous n’ajoutons donc qu’un seul serveur. Le message «Toutes les autres ressources exécutées ont changé et nous allons simplement mettre en service un nouveau serveur».

Ensuite, il présente un plan et le plan est en réalité une séquence d'opérations qui seront effectuées pour que votre état souhaité se réalise: "Nous allons créer un serveur, nous allons le configurer, "toutes les choses qui doivent aller dans les coulisses pour faire de cette réalité. Si vous pensez à la façon dont vous allouez les objets du système d'exploitation, pour vous rattacher à certains des points précédents, vous ne pensez généralement pas au fait qu'il existe une table de descripteurs de noyau qui doit être mise à jour par le noyau lorsque vous allouez un nouveau descripteur de fichier. Vous êtes généralement juste dans Node, js disant "Donnez-moi un fichier", et puis il y a quelque chose de magique qui rend cela possible.

Ici, c'est une idée similaire, c'est juste étiré sur une plus longue période. Dans un modèle de système d'exploitation traditionnel, vous exécutez un programme, il s'exécute puis il se ferme. Dans ce modèle, vous exécutez un programme et il ne se termine jamais vraiment, il déclare l'état. Certaines choses amusantes, si vous regardez jamais certains projets – Brendan Burns a ce projet de métaparticule qui pousse cette idée à l'extrême: "Et si nous considérions l'infrastructure comme un programme de code, ce ne sont en réalité que des programmes qui utilisent le cloud pour s'exécuter et juste couru pendant très longtemps? " C'est un exercice qui fait réfléchir.

Parce que nous déclarons ceci et que cela passe au scripting versus infrastructure sous forme de code, nous avons un plan, donc en fait, nous pouvons voir ce qui va se passer avant que cela ne se produise réellement et cela nous donne confiance pour nous permettre de réviser les choses. Si nous formons une équipe, nous pouvons inclure cela dans une demande d'extraction et dire en fait: "Cela semble entraîner des temps d'arrêt" ou "Cela supprimera la base de données, est-ce que vous vouliez faire ? " Vous avez en fait un plan qui est très utile. Une fois que nous avons un plan, alors généralement les développeurs disent: "Ouais, c'est ce que je veux, réalisons-le." Ensuite, à partir de ce moment, l’infrastructure en tant que moteur de code génère de nombreuses mises à jour pour créer, lire, mettre à jour et supprimer les ressources. Voilà comment cela fonctionne dans les coulisses. En général, il n'est pas nécessaire de savoir que c'est exactement ce qui se passe, mais c'est en gros le fonctionnement de Cloud Formation, celui de Terraform, celui de Pulumi. Tous ces systèmes fonctionnent efficacement de la même manière.

Jours 1, 2 et plus

Cela fonctionne pour le premier jour, mais un autre domaine dans lequel il est important de pouvoir comparer les états et effectuer le nombre minimal de modifications nécessaires au déploiement de vos modifications est un autre domaine dans lequel il est important de le comparer à un pointage et de cliquer et de créer un script là où il est important. Cela prend plusieurs formes. Déploiement d'applications, déploiement permanent de modifications telles que les nouveaux hachages Docker SHA que vous souhaitez déployer dans votre cluster, peut-être à partir de Kubernetes ou de l'orchestrateur de conteneurs de votre choix. Mettre à jour vers de nouvelles versions de choses, comme les nouvelles versions de MySQL, les nouvelles versions de Kubernetes lui-même. C’est une autre évolution que vous allez probablement faire.

Ajout de nouveaux microservices ou mise à l'échelle des services existants. En exploitant de nouveaux services de données, vous voudrez peut-être utiliser le service d'apprentissage automatique le plus récent et le plus complet fourni par Google. Chaque fois que vous souhaitez tirer parti de quelque chose comme cela, vous devez réellement provisionner une ressource dans le cloud. Vous devez provisionner un lac de données d'apprentissage automatique ou la ressource. Ensuite, évoluer également pour adopter les meilleures pratiques. Parfois, tout ce que vous avez fait, à un moment donné, vous pourriez vous rendre compte que tout était faux et que vous deviez changer les choses. Par exemple, vous configurez peut-être votre serveur et votre cluster Kubernetes dans leur intégralité, puis vous réalisez: «Nous devons tout authentifier correctement». Il est désormais ouvert à Internet et tout le monde peut jouer avec notre serveur Kubernetes. Ce n'est probablement pas une bonne chose, mais cela arrive à beaucoup de gens. Au fur et à mesure que vous modifiez et corrigez ce type de problème, vous avez besoin de quelque chose qui puisse appliquer progressivement des deltas.

J'ai mentionné plus tôt, la mise à l'échelle d'un nouvel environnement. Si vous êtes dans un autre environnement de production, nous constatons souvent que chaque développeur de l'équipe dispose d'une copie complète de l'infrastructure de cloud pour son service, ce qui facilite grandement l'essai de nouvelles modifications, ainsi que de tests. . Nous avons même des personnes qui créent des environnements entièrement éphémères dans des demandes d'attraction. Peut-être que vous allez modifier votre application, vous soumettez une demande d'extraction, une copie complète est générée, une batterie de tests est exécutée, puis elle est réduite comme si elle n'avait jamais existé et, ce faisant, vous obtenez une beaucoup plus de confiance que si vous essayez de simuler ces environnements sur votre bureau.

Bien sûr, parfois vous voulez faire cela, exécuter Docker sur votre bureau est un excellent moyen de vraiment vérifier les choses, mais à un moment donné, avant de procéder à votre intégration, vous voudrez exécuter ces tests plus sérieux.

Juste un problème

En tout état de cause, le seul problème avec tout cela est l’infrastructure car le code n’est souvent pas réellement un code, c’est comme le gros mensonge ici. C'est très décevant une fois que vous réalisez cela et ce que cela signifie, souvent, ce que nous appelons le code est en fait YAML ou souvent YAML avec des modèles Go incorporés dans ceux-ci, ou vous regardez Cloud Formation, Cloud Formation est comme YAML ou JSON. avec un mini DSL intégré dans les chaînes, vous pouvez donc y insérer des références. Plus notre infrastructure cloud devient complexe, plus elle commence à s'effondrer de manière fondamentale.

Ce qui est si décevant pour moi quand je suis arrivé dans cet espace, c'est que j'avais entendu parler de toutes ces technologies, je ne les utilisais jamais réellement pendant des mois à la fois. C’est la première chose que j’ai faite lorsque j’ai créé Pulumi: c’est «OK, pour les trois prochains mois, je vais simplement créer des applications cloud modernes utilisant les meilleures technologies», et c’est très vite que j’étais juste nager dans YEML. Ce n'est pas seulement YAML, je pense que YAML va bien, YAML est doué pour ce pour quoi il a été conçu. Je pense que le problème est que nous l'utilisons pour ce pour quoi il n'a pas été conçu. Nous essayons en fait d'intégrer l'architecture d'application dans YAML et, pour cela, je choisirai un langage de programmation tous les jours. Vous obtenez des abstractions et des réutilisations, des fonctions et des classes, des constructions expressives telles que des boucles, une compréhension de liste, un outillage, des IDE, un refactoring, une analyse statique et surtout la productivité, tout ce sur quoi j'ai passé mes 15 dernières années.

Ce serait formidable si nous pouvions réellement utiliser ces éléments et je pense que lorsque nous collaborons avec des organisations pour adopter de nouvelles technologies, il existe toujours un fossé entre les développeurs et les ingénieurs d'infrastructure, mais en même temps, il y a cette volonté de supprimer ces obstacles et de mieux travailler. ensemble. Je pense que cela ne veut pas dire que tous les développeurs vont devenir des experts en réseaux, certainement pas, mais nous devrions disposer des outils et des techniques nécessaires pour collaborer au-delà de ces frontières. Ainsi, si je veux utiliser une fonction sans serveur, je être capable de le faire.

Tant que mon équipe d'infrastructure est convaincue que je le fais conformément aux directives appropriées et si je veux créer une nouvelle application basée sur une passerelle API au lieu de faire Express.js, qui sera plus difficile à mettre à l'échelle et à sécuriser, je devrait être habilité à le faire. Nous pensions que c'était la voie à suivre. Voici un exemple tiré de mon tableau des cas où la chose la plus folle à propos de tout cela est que vous devez réellement insérer des clauses d'indentation ici parce que c'est le YAM. Ceci est imbriqué, vous devez donc mettre en retrait huit espaces à droite, sinon ce n'est pas un YAML bien formé. Vous avez ce mélange d'inquiétudes folles ici que personne n'aime.

Rappelez-vous cette diapositive que j'ai dit, "Le nuage ne devrait pas être une réflexion après coup?" C'est encore une réflexion après coup pour beaucoup d'entre nous. Pour les applications, nous écrivons en Go, JavaScript, Rust, TypeScript, etc., pour l’infrastructure, nous utilisons Bash, YAML, JSON. HCL est la meilleure technologie disponible qui ne soit pas un langage de programmation complet, mais se rapproche mais reste différente. Ensuite, pour l'infrastructure d'application dans le domaine Kubernetes, tout est YAML à l'extrême. Ces petites choses Bash parce que souvent, nous utilisons différents outils, différents langages pour les applications, plusieurs éléments d’infrastructure, de sorte que, souvent, nous devons créer une infrastructure dans AWS, mais nous utilisons ensuite l’infrastructure Kubernetes et en utilisant différents outils, nous utilisons différentes langues, en les frappant ensemble avec Bash. Hepdio a cette phrase, "Les murs de YAML et les montagnes de Bash." Je pense que c'est la situation actuelle.

Pourquoi l'infrastructure en tant que code?

Cela m'amène à la section suivante, intitulée "Et si nous utilisions également des langages réels pour l'infrastructure?" Cela nous aiderait-il à brouiller les limites et à rendre le cloud plus programmable et à permettre aux développeurs d'être plus autonomes, tout en permettant aux ingénieurs en infrastructure de donner à leurs équipes et à elles-mêmes la capacité de devenir plus productives et de se tenir réellement sur les épaules de géants? J'aime cette phrase parce que nous travaillons dans les langues depuis plus de cinq ans. Ne serait-il pas formidable de profiter de toute l'évolution que nous avons constatée là-bas?

C'est ce qui nous a conduit à l'idée de Pulumi, qui consistait à utiliser de vrais langages, nous obtiendrons tout ce que nous savons sur les langues. J'en ai mentionné beaucoup plus tôt, nous allons éliminer beaucoup de copier-coller et ce modèle de brouillage dans les langues de YAML. En même temps, cela doit être fait avec délicatesse car il faut associer cette idée d’infrastructure en tant que code. Je pense que lorsque je suis arrivé dans l’espace, mon idée initiale était: "Nous devrions écrire du code, pourquoi écrivons-nous sur CYAML?" J'ai vite vite compris pourquoi l'infrastructure en tant que code était tellement essentielle à la façon dont nous gérons et faisons évoluer ces environnements.

Je pense que Terraform a très bien réussi, à savoir adopter une approche unique auprès de plusieurs fournisseurs de cloud, nous avons parlé de beaucoup de gens qui essaient de faire AWS et Azure et sur site et Kubernetes et qui doivent clairement utiliser différents outils et langages. n'échelle pas.

Démo

Cela dit, je vais lancer une brève démonstration du code et nous verrons à quoi cela ressemble. Tout d’abord, c’est un exemple assez basique de Getting Started ici. C'est un programme très simple de Pulumi. Ce qu'il va faire, c'est créer un compartiment S3, puis le peupler avec un tas de fichiers sur le disque. Laissez-moi voir si je peux le remonter.

Si je passe par ici, je verrai que c'est en fait un simple projet Node.js et, bien sûr, il pourrait s'agir de Python, de Go, et la première chose que nous verrons, c'est que nous utilisons simplement Node. Forfaits .js. Dans beaucoup d'autres systèmes, le modèle d'extensibilité n'est pas clair. En fait, la plupart d’entre eux sont des jardins murés car ils sont spécifiques au fournisseur de cloud, mais ici, nous n’utilisons que des paquets Node. Notez que nous avons des packages Pulumi. Il s’agit donc d’AWS et d’Azure et de Kubernetes. Nous utilisons également des paquets de nœuds normaux. Nous utilisons des bibliothèques typiques que nous connaissons. Nous pourrions utiliser notre propre registre privé JFrog si notre entreprise utilise JFrog, par exemple.

Une autre chose qui est si facile à prendre pour acquis est que je reçois une documentation comme des exemples. Je profite de tout ce que nous savons sur les IDE. Si je me trompe, cela signifie: «Voulez-vous dire« seau »? Vous semblez avoir mal tapé cela. Souvent, dans ces dialectes YAML, vous ne le découvrez pas avant qu'il ne soit trop tard. Vous avez essayé de l'appliquer. Vous êtes maintenant peut-être à mi-chemin d'un déploiement de production et vous trouvez une erreur. En fait, vous apportez beaucoup de cette perspicacité dans la boucle intérieure.

En gros, nous disons: "Donnez-nous un seau S3, nous le configurons pour servir une page statique." Ensuite, voici où cela devient un peu intéressant, car nous utilisons simplement une API de nœud, donc fs.readdir, et nous disons en gros pour chaque fichier, créez un objet S3 et envoyez-le dans le cloud. Ensuite, nous définissons la stratégie pour activer l'accès public, puis nous imprimons l'URL. Habituellement, si vous faites cela dans Cloud Formation, vous parlez de 500 lignes de YAML ou quelque chose comme ça. Ce que nous allons faire ici, c'est que nous allons simplement lancer pulumi. Tu te souviens de ce diagramme que j'ai montré plus tôt? Cela correspond à ce que dit le diagramme, dans lequel il exécutait le programme et disait: "Si vous deviez déployer cela, vous allez créer ces quatre objets."

Si je le souhaite, je peux obtenir beaucoup de détails à ce sujet, mais des éléments assez classiques. Si je dis oui, maintenant, il s’adresse à Amazon et déploie mon compartiment S3. Il a téléchargé ces deux objets, remarquez ici qu'il est en train d'être téléchargé depuis le répertoire www. Il s'agit en fait de télécharger ceci dans un Favicon, mais cela pourrait être n'importe quelle chose arbitraire. C’est un moyen extrêmement économique d’héberger tout contenu statique sur S3, mais remarquez à la fin, il indique l’URL. Si je veux une URL personnalisée, tous les fournisseurs de cloud sont incroyables avec tous les blocs de construction qu’ils fournissent, alors si je veux y aller et ajouter une belle URL personnalisée comme duffyscontent.com ou quelque chose du genre, il ne reste plus que 10 lignes de code à parcourir. configurez le DNS pour cela. Vous pouvez commencer simplement et devenir complexe quand vous en avez besoin. Ici, remarquez que l'adresse URL a été imprimée. Je vais donc simplement l'ouvrir, puis nous verrons qu'elle est déployée.

Remarquez ici, chose intéressante, je n'ai pas mis à jour l'infrastructure. J'ai mis à jour certains fichiers mais cela va le détecter, il va dire: "Cet objet a changé, voulez-vous le mettre à jour?" Oui, je veux le mettre à jour. Le flux est le même si j'ajoute ou supprime des ressources. Maintenant, je peux aller ouvrir cela et nous verrons "Nouveau contenu". C'est une démo assez simple.

If I want to get rid of everything and just clean up everything that I just did so Amazon doesn't bill me for the miniscule amount of storage there, probably one cent a year or something like that, I can go ahead and delete it and it's done. I should mention also, I talked earlier about standing up lots of different environments. We have this notion of a stack and so if you wanted to create your own private dev instance, you can just go create a new stack and then start deploying into it, so pretty straightforward.

This is a more interesting example, where this is building and deploying a Docker container to Amazon Fargate, which is their hosted clustering service. It's not Kubernetes but it's pretty close. What we did here was we took the Docker getting started guide, so if we go to Docker and download Docker, it walks you through how to stand up a load balancer service using Docker Compose, this is the moral equivalent but using Fargate. It’s got an elastic load balancer on it, listening on port 80. It's actually going to build our Docker image automatically. If I look here, we've got just a normal Docker file. What this is going to do is, it's going to actually do everything. It’s going to stand up the ECS resources, it's going to build and publish the Docker container to a private registry within Docker itself. It's also creating a virtual private cloud, so it's secure.

Notice this is doing a fair bit more than our previous example and I'm going to say, "Yes." This is the power of abstraction and reuse, we can actually have components that hide a lot of the messy details that frankly, none of us want to be experts in. If you were to write this out by hand, look, here this is almost 30 lines of code. Each one of these resources, if you're doing Cloud Formation or some of the other tech that I mentioned earlier, you'd have to manually configure every single one in excruciating detail down to the property level whereas here, we can benefit from reuse what you know and love about application programming and know that in doing so, we're benefiting from well-known best practices.

This may not be obvious, that's actually the Docker build and push. Depending on the bandwidth here, the push may take a little bit longer, so I'm going to jump back to the slides and then we'll come back in just a minute.

I mentioned multiple languages, so this is basically accomplishing the same thing infrastructure as code gives you just with any language. We have others on the roadmap like .NET and actually, there's somebody who's working on Rust right now which will be super cool or somebody who did F# as a prototype which is really actually a cool fit for infrastructure as code because it feels more declarative and pipeline-y. More language is on the way but right now, these are some great options.

I mentioned lots of different cloud providers, so every single cloud provider is available as a package. This is a stretched picture of turtles because it turtles all the way down. The magic of languages, you can build abstractions. Then, Kubernetes – I hinted at Kubernetes along the way, but what we see is to actually do Kubernetes, you you have to think about security so you have to think about IAM roles, you have to think about the network perimeter, you have to set up virtual private clouds. You think about, "If I'm in Amazon, I want to this CloudWatch, I don't want to do this Prometheus thing maybe."

You really have to think holistically about how you're integrating with the infrastructure in whatever cloud providers going to. It's not as simple as, "Give me an EKS cluster or GKE or AKS," all those things are really important. Also, if you're starting with Kubernetes, did you do that because you just wanted to deploy containers and scale up container-based workloads? Probably. You probably didn't do it because you wanted to manage your own Mongo database with persistent volumes and think about the backups and all that or MySQL when you're coming from a world of hosted databases. Most customers we talk with are actually using RDS databases, S3 buckets, Cosmos database if you're an Azure, but not managing the data services inside of the cluster itself but actually leveraging the cloud services that are hosted and managed.

What this shows is, you can actually say in this example, the one on the left is basic provisioning a new GKE cluster like an entire cluster, and then deploying a canary deployment in Kubernetes to that cluster. Then it exports the config so you can go and access your new cluster, all in one program that fits on a page. The one on the right is showing ladder thing I was just talking about where Azure Cosmos DB has a MongoDB compatibility mode, so rather than host your own MongoDB instance, you can spin up some containers and just leverage that. Here, we're basically creating new Cosmos DB instance, sending up some geo-replication capabilities of it, then here's where it starts to get interesting, we're actually taking the authentication information for that instance and putting it in a Kubernetes secret in this program.

Usually, you'd have to take that, export it, store it somewhere secure, fetch it later on, whereas here, we can actually just take it, put it in a secret, and then consume it from a home chart. Now the home chart is going to spin up some application that accesses that database.

If I go back, my application here should be done, this is the Fargate example. If I do this, saying, "Hello, world," so it's just the application up and running which is, again, just our application here. I should mention, just like I showed updating the file for the S3 bucket, if I want to deploy a new version of the container, I just go and change the Docker file, run pulimi up, it'll deployed the dif and now I've got the new image up and running.

This is the Kubernetes example, which is effectively just a very basic NGINX deployment object followed by a service, so it's a standard Kubernetes thing. If I go and deploy it, it's going to look very much like I had shown before with the caveat. This is neat, it's actually going to show me the status of the deployment as it's happening. I don't know if people have ever experienced deploying something with cubectrl in the Kubernetes. You're often found tailing logs and trying to figure out, "Why is this thing coming up? It turns out I mistyped the container image name," or any number of other things. Whereas here we're actually saying, "Why are we sitting here waiting? Well, it turns out GCP is now allocating the IP address because we use the load balance service," and so we can see those rich status updates.

Even cooler than that is if we go back here, we can actually just delete all that code and replace it with something like this. Again, the magic of abstraction here. This is, "I encountered this pattern hundreds of times in my applications, I'm sick of typing it out manually by hand, so I'm going to create a class and abstraction for it." It turns out services and deployments often go hand in hand and they have a lot of duplicative information in each of them, so why not create a class to encapsulate all that and give it a nice little interface to say, "An image, replicas, ports." That's just showing you a little bit of a taste of what having a language gives you, instead of copy and pasting the YAML and then editing the slight edits everywhere, you can use abstraction.

Obviously, it's easy to go overboard with abstraction but what we find is there's a level of abstraction that makes sense. Some people use abstraction to make multi-cloud easier, some people just do it to make some common task in whatever cloud you're going to itself much easier.

Automated Delivery

I should mention in terms of that maturity lifecycle of going from scripting to infrastructure as code, usually, the next step is continuous delivery, so using something like GitOps where you want to actually trigger deployments anytime you check in a change. That allows you to use pull requests and all of the typical code review practices you would use for your applications, you can now use it for infrastructure and it's just code so it's similar, you can apply the same style guide, you can apply the same pre-commit checks that you would use for your application code.

That includes testing – it's actually one of the things I actually did not envision this to be as popular as it has become. A lot of people are adopting this approach because now they can actually test their infrastructure. It seems so obvious in hindsight but until people started doing it, it wasn't obvious. For example, "What if you want to make sure that your servers are tagged appropriately or aren't open to the internet by accident or endless possibilities?" Now, you can use your favorite test framework, so in this case, I'm just using Mocha. If you're in Go, you can use the built-in Go test framework or Python, the built-in Python framework.

Doing this with YAML is possible but, definitely, you have to learn a set of new tools and it's just not the same and, by the way, if these things integrate with your IDEs, you just benefit from that as well.

Cloud Engineering – Test Your Infrastructure

This level of testing spans lots of different domains. There's unit testing like the kind I just mentioned, integration testing, so actually running tests after a deployment happens to make sure that the application is functioning. There is even more exotic testing like injecting faults, fuzz testing, scale testing. The idea here is, "Let's apply all the engineering best practices we know and love to all aspects of how we're doing cloud engineering," and, of course, testing has to be one of those.

The Future of Cloud Architectures

That’s it in a nutshell. I'll say if I look to the future, some of the things I'm really excited about, I think Kubernetes is a platform-level abstraction that definitely seems to be the right level of abstraction that we can start building on top of. That allows us to basically abstract away a lot of the underlying details of how compute runs in all the different cloud providers, there seems to be almost universal agreement. Too early to call it but we'll see in three years, it seems like a safe bet at this point.

Serverless is really exciting because you really do focus a lot more in application code. The thing I'll say is, after having been in the trenches for a while on this, I think the key thing with serverless is it works in certain places and serverless means different things to different people. I think if you look at AWS Lambda or Azure Functions or Google Functions, for event-driven workloads, it's wonderful. You don't need to spend money on compute that's just sitting there idle and you only pay for what you use. It's incredibly powerful and things like Amazon API gateway, just really bring that into the application domain for doing things like RESTful API servers. Definitely worth checking out if you haven't already but I would caution everything is not going to be serverless. I think state for workloads have a place on this earth, they're not going anywhere anytime soon.

I think there's a lot of folks focusing on NoCode solution. I think we'll see a lot more of those and the thing I'm excited about is as we raised the level of abstraction, infrastructure does fade into the distance. The reason why it's so exciting to me is because it's the thing that powers everything on top and so if you're actually able to program at the level of the infrastructure and build new architectures. I mentioned super charging, I really do think it's supercharged just what you can do with the amazing cloud resources that are around us. We're trying to enable this virtuous cycle of building new things and I think the builders who are figuring that aspect out are really going to enable all of us to focus on higher and higher level application-level patterns.

In summary, I think the power of real programming languages and the safety and robustness of infrastructure as code, really for the next wave of cloud innovation, I think you're going to see this happening a lot more. We already see other folks – Amazon has their project that they're gearing up to make a bit more noise about later this year called the CDK. We've been working with them and talking with them, it shares a lot of heritage there. Some of the Helm work that's going on for Helm 3 is going to incorporate more general purpose programming languages. HashiCorp just launched Terraform 0.12 almost a month ago, and that incorporates four loops and some basic rudimentary programming language features. My guess is they'll constantly be moving that in the direction of general purpose languages as well, so if you're into infrastructure, this is where it's at. It's a lot more fun, which is probably the most important part.

Questions and Answers

Participant 1: You showed that policy enforcement through the unit tests but if we think about the code, wouldn't be the static code analysis a better place for policy enforcement? For security issues, you need to write unit test to enforce it, but it would be nice if a compiler or something else can tell you, "By the way, you're provisioning the infrastructure and you have some issues that you might want to fix," and showed it as a warning when you compile it.

Duffy: Yes, I 100% agree. We're actually working on a new policy as code framework that we're going to launch in the next couple of months, which we'll basically bring that into the IDE so you get red squiggles, you get little light bulbs for auto fixing. There's some things you can't do statically, unfortunately, they require a little bit of dynamic analysis but for those that you can, I completely agree, it's better than having to write tests for them.

Participant 2: I think one of those ideas is really cool and I really think, "Why didn't I come up with it?" because it's really simple but it makes so much sense. I have one question to the demo that you showed, I think the answer will be yes, but do you have a way of defining dependencies? For example, there was no Async/Await because it showed up that it's tested right, but I think the first two jobs were running in parallel and the rest of the three were waiting for the first two – at least it looked like that – at the finish. Do you have a way to actually Async/Await or something else to say, "I need this thing to finish," and then I can, for example, pipe the URL into the job?

Duffy: That was probably one of the more difficult parts of building the system. At the heart of it, all resources have properties on them, and the properties are like fancy promises, except the promises carry dependency information along with them. If you're programming it, the system automatically tracks all the dependencies so that it can parallelize things and then destroy things in the right order. In the event that it gets it wrong or you have like an external dependency that's not obvious in the program, there's a way to just basically say, "Depends on," and then you can pass an array of other resources that things depend on. You can control the DAG if you need to but in general, it tends to get it right by default.

Participant 3: I have two questions, the first one is, does it support C# right now?

Duffy: I was showing TypeScript and there's no C# yet, but that's on the roadmap. Right now it's TypeScript, JavaScript, Go, and Python.

Participant 3: Also, they support the transaction, which means that if one middle step failed, would it have us automatically roll back and then clean the resource inside cloud?

Duffy: We don't automatically rollback but you can roll back explicitly and the reason why we wanted to leave that to the end-user to decide is that the right thing to do because sometimes it's not the right thing to do and so we decided, "Making that decision on behalf of the end-user could get us into trouble," but you can easily roll back in the face of failure.

Participant 4: Can you describe how this would be applied for on-prem infrastructure?

Duffy: We have a lot of different providers, we have VM vSphere provider, OpenStack, F5 BIG-IP if you're going to manage firewall rules using code. All of it works for on-prem, we have people using it for Kubernetes on-prem in addition to just VM orchestration. There's a lot of different on-prem technologies, so we definitely don't support everything. We have a Terraform adapter layer so if there's ever a Terraform provider that exists already, we can easily adapt it into the system and project it into all the languages. That's like an hour of work, so it's pretty straightforward.

See more presentations with transcripts