Mise à jour 25/10/2019
Sommaire :
Que fait Amazon avec AWS ?
Comment mettre le cloud public d’Amazon à profit ?
Par où commencer avec AWS ?
Où pouvez-vous apprendre à utiliser la AWS ?
Dans quelle mesure AWS est-il vraiment abordable ?
Que font les services Web d’Amazon ?
L’entreprise la plus associée au “cloud public”, dans l’esprit du grand public, est Amazon, qui se trouve être le plus grand e-commerçant du monde. Certes, d’autres acteurs, et non des moindres, sont présents sur le segment. Mais aujourd’hui, Amazon demeure le plus grand fournisseur mondial de cloud public, en dépit d’une légère méforme ces derniers mois. Fournisseur de cloud public ? services informatiques accessibles sur le Web à partir de serveurs répartis dans le monde entier dans des centres de données hautement automatisés.
Voici ce que nous entendons par là : Lorsqu’un service informatique est mis à votre disposition n’importe où dans le monde via le Web, sur des serveurs dont les fonctions ont été louées par un éditeur, un fabricant de logiciels ou un autre client privé, il y a 34 % de chances (selon le cabinet d’analystes Synergy Research Group) que ce service soit hébergé sur le cloud public d’Amazon. Il n’y a que 15% de chances qu’il soit hébergé sur le cloud Azure de Microsoft.
Ce que fait Amazon avec AWS
Avant de lancer une cascade de termes fabuleux et mystérieux tels que “infrastructure cloud” et “machine virtuelle”, essayons d’expliquer ce que fait AWS en des termes que même un PDG pourrait comprendre.
Jusqu’au milieu des années 2000, les logiciels étaient installés sur votre disque dur. C’est la propriété intellectuelle qui vous était concédée via la licence d’utilisation. Et soit la totalité de cette licence était payée d’avance, soit elle était souscrite sur une base annuelle “par poste” ou “par utilisateur”.
Ensuite, le réseau d’entreprise (un réseau local de type LAN) a permis l’étonnante innovation technique qui a consisté à déplacer ce disque dur dans une pièce pleine d’autres disques durs. Bref, sur un serveur. Et du point de vue des logiciels et de leurs Sinon, l’idée principale n’était pas très différente. (Et Microsoft a prospéré sur ce marché avec Windows Server.)
La première idée vraiment brillante issue des réseau locaux d’entreprise a été la suivante : un ordinateur entier, y compris son processeur et les périphériques installés, pourrait être rendu sous forme de logiciel. Bien sûr, ce logiciel fonctionnerait toujours sur du matériel, mais le fait d’être rendu en tant que logiciel le rendait très utile si quelque chose tournait mal de façon irrémédiable. Vous auriez simplement à restaurer une copie de sauvegarde du logiciel. Oui, il s’agissait de fait de la première machine virtuelle (VM).
Ensuite, vous avez pu installer les applications dont vous avez besoin sur une machine virtuelle plutôt que sur une machine physique. Le fait d’être virtuel signifiait que l’application pouvait s’exécuter n’importe où. Et rapidement. Et il est devenu possible de déplacer une machine virtuelle entre processeurs sans affecter sensiblement le fonctionnement de l’application sur la machine virtuelle.
Si une entreprise pouvait installer un serveur Web sur une machine virtuelle, elle pourrait avoir la liberté d’exécuter ces serveurs Web n’importe où, plutôt que depuis le sous-sol du siège social de l’entreprise. Les premiers grands fournisseurs de services cloud computing public – dont Amazon – ont construit leurs modèles d’affaires autour de l’hébergement des machines virtuelles qui faisaient tourner leurs serveurs web, et de la vente de cet hébergement pour un prix basé sur le temps plutôt que sur une licence coûteuse.
Les clients ne payaient que ce qu’ils utilisaient, ce qui permettait pour la première fois aux petites et moyennes entreprises de bénéficier d’un service de qualité.
Qu’entend-on par “infrastructure” et “service” dans le contexte de l’informatique dans les clouds publics ?
Dans tout système économique global, le terme infrastructure désigne les couches de services et les systèmes de support sur lesquels reposent les composantes les plus visibles de l’économie. Amazon Web Services, comme l’indique le nom original de la division, permet d’héberger des sites Web à distance.
Depuis sa création, cependant, AWS est devenu le principal fournisseur mondial d’infrastructures virtuelles – systèmes d’exploitation, hyperviseurs, orchestrateurs de services, fonctions de surveillance et systèmes de support sur lesquels l’économie du cloud public est basée.
Nous utilisons beaucoup le mot “service” dans cet article. AWS fournit les principaux services suivants :
L’Infrastructure-as-a-Service (IaaS) d’AWS
AWS vend l’accès à des machines virtuelles qui sont configurées comme de vrais ordinateurs, mais qui ne sont rendues que sous forme de logiciels. Vous les gérez via le Web, et vous pouvez voir ce que leurs écrans produiraient s’ils étaient de vrais ordinateurs physiques avec des moniteurs.
Mais les serveurs web n’ont pas vraiment besoin de moniteurs. Ils peuvent envoyer le code HTML, CSS et JavaScript dont les navigateurs Web ont besoin pour assembler les pages Web et pour reproduire les programmes que vous exécutez à partir des navigateurs (par exemple, Google Docs). Outre la flexibilité, ce qui fait du IaaS un service lucratif et commercialisable, les clients ne paient que pour les ressources (bande passante, stockage, traitement) qu’ils utilisent, lorsqu’ils les utilisent.
Le Software-as-a-Service (SaaS) d’AWS
Sur votre PC, votre navigateur Web est devenu un véhicule de rendu pour les applications qui vous sont fournies par un fournisseur de cloud computing. Sur votre smartphone, son système d’exploitation peut jouer le même rôle, et le résultat peut être une application dont les fonctionnalités de base existent dans le cloud, plutôt que d’être installée sur l’appareil.
Dans les deux cas, le logiciel est exécuté sur le serveur et livré à votre appareil (le client). Certaines parties de cette application sont exécutées aux deux endroits, Internet servant de moyen de livraison.
Le Platform-as-a-Service (PaaS) d’AWS
Lorsque votre intention est de fournir des logiciels à vos clients via le cloud public, il devient plus pratique d’utiliser des outils situés dans le cloud pour construire ces logiciels efficacement sur site (“applications natives du cloud” – ou cloud native). Il devient également possible d’optimiser le modèle de facturation pour ce logiciel – par exemple, en facturant uniquement l’utilisation par les clients de fonctions spécifiques construites sur la plate-forme cloud public.
Le stockage des données en mode objet d’AWS
Bien qu’il soit juste de dire qu’Amazon n’a pas créé le cloud public, il est tout aussi juste de dire qu’il a créé le marché du stockage et de la livraison de données en vrac. Par là, nous entendons non seulement les fichiers, mais aussi les montagnes de données structurées et non structurées qui peuvent constituer une base de données, ou qui peuvent ne pas encore s’y être regroupées.
Cette partie de la révolution du cloud a été motivée par le fait que AWS facturait l’espace que les données consommaient réellement, plutôt que les volumes ou les disques durs qui les contenaient. Désormais, AWS offre une variété d’options de services de données mieux adaptées aux différentes façons dont les clients ont l’intention d’utiliser les données en mode cloud.
Mettre le cloud public d’Amazon à profit
Soyons tout d’abord très clair sur ce qu’est une plate-forme de cloud public. Vous avez déjà lu de nombreuses définitions du “cloud”. Mais ici, il s’agit du système d’exploitation qui reformule plusieurs serveurs en une unité cohérente. Pour qu’un groupe d’ordinateurs n’importe où dans le monde soit un cloud, les choses suivantes doivent être réalisables :
Ils doivent être capables d’utiliser la virtualisation (la capacité des logiciels à fonctionner comme du matériel) pour mettre en commun la capacité de calcul de plusieurs processeurs et de plusieurs dispositifs de stockage, ainsi que la connectivité réseau de ces composants, en unités contiguës. En d’autres termes, ils doivent collecter leurs ressources afin d’être perçus comme un seul gros ordinateur plutôt que plusieurs petits.
Les charges de travail exécutées sur ces pools de ressources ne doivent être ancrées dans aucun emplacement physique. En d’autres termes, leur mémoire, leurs bases de données et leurs processus, quel que soit leur contenu, doivent être entièrement portables dans le cloud.
Les pools de ressources qui exécutent ces charges de travail doivent pouvoir être approvisionnés via un portail libre-service. De cette façon, tout client qui a besoin d’exécuter un processus sur un serveur peut fournir l’infrastructure virtuelle (les ressources mises en commun pour le traitement et d’autres fonctions) nécessaire pour héberger et soutenir ce processus, en le commandant sur le Web.
Tous les services doivent être mis à disposition sur la base d’une utilisation à l’unité, généralement à des intervalles de temps consommés dans le fonctionnement réel du service, par opposition à une licence unique ou renouvelable.
Le National Institute of Standards and Technology (NIST) des États-Unis a déclaré que tout fournisseur de services dans les clouds (CSP) auquel le gouvernement américain souscrirait, doit au minimum fournir ces quatre capacités.
Si le NIST avait l’occasion d’ajouter une cinquième composante, compte tenu de la vaste histoire qui s’est déroulée au cours des quelques courtes années où le cloud public a pris de l’importance, ce serait probablement le support. Car AWS est un cloud public, mais c’est aussi un service managé. Cela signifie qu’il est administré pour fournir des niveaux de service particuliers qui sont explicitement énoncés dans les accords de niveau de service (SLA – service-level agreements) de l’entreprise.
Par où commencer avec AWS ?
Cela surprend certains d’apprendre qu’un compte AWS n’est pas un compte Amazon avec des privilèges supplémentaires. Il s’agit d’un compte de sécurité qui centralise l’accès aux services AWS (et associés) avec une adresse facturable. Pas une adresse d’expédition, comme sur Amazon.com, mais plutôt un login comme celui que vous pouvez utiliser pour Windows.
Il existe des moyens d’utiliser ce compte AWS pour vous lancer dans l’espace AWS sans beaucoup, ou très probablement sans aucun investissement financier. Pour la première année de chaque compte, AWS met de côté 750 heures d’utilisation gratuite par mois (aussi appelé “le mois entier”) d’une instance de machine virtuelle t2.micro basée sur Linux ou Windows, qui est configurée comme un PC à processeur unique avec 1 Go de RAM.
En utilisant cette instance comme serveur virtuel, vous êtes libre de configurer une instance d’une base de données relationnelle Amazon RDS avec jusqu’à 20 Go de stockage, plus 5 Go de stockage objets S3 standard. (Vous en saurez plus sur ces services de base dans quelques instants.)
Où pouvez-vous apprendre à utiliser la AWS ?
De temps à autre, AWS organise une conférence en ligne d’une demi-journée pour enseigner aux nouveaux arrivants comment fonctionnent ces services.
Cette vidéoconférence peut vous donner un coup de pouce sur ce que vous pourriez avoir besoin de savoir au sujet d’AWS. Si vous avez un objectif commercial particulier en tête et que vous recherchez une formation professionnelle, AWS parraine des cours dans le monde entier qui sont dispensés dans des centres de formation avec des instructeurs professionnels. Par exemple :
Migrer vers AWS enseigne les principes que les organisations devraient connaître pour développer une migration progressive de leurs applications et logiciels existants vers leurs homologues en mode cloud.
AWS Security Fundamentals présente les meilleures pratiques, méthodologies et protocoles qu’AWS utilise pour sécuriser ses services. Et ce afin que les organisations qui suivent des régimes de sécurité spécifiques puissent intégrer ces pratiques dans leurs propres méthodes.
AWS Technical Essentials permet à un professionnel de l’informatique au sein d’une organisation de se familiariser avec les services Amazon et les pratiques de sécurité, dans le but d’aider l’administrateur ou le responsable informatique à développer et déployer les services les mieux adaptés pour atteindre les objectifs commerciaux.
Dans quelle mesure AWS est-il vraiment abordable ?
Le modèle d’affaires d’AWS a été conçu pour faire passer les dépenses en informatique des dépenses en immobilisations (Capex) aux dépenses d’exploitation (Opex). Théoriquement, un produit pour lequel les coûts sont engagés mensuellement, ou du moins plus progressivement, est plus durable.
Mais contrairement à une dépense régulière comme l’électricité ou l’assurance, l’utilisation des services de cloud public ont tendance à faire des petits. Bien qu’AWS divise clairement les dépenses en catégories relatives au stockage, à l’utilisation de la bande passante et au temps de cycle de calcul, ces catégories ne sont pas les services eux-mêmes.
Ils sont plutôt le produit des services que vous choisissez, et en choisissant davantage et en intégrant davantage de ces composants dans les actifs en mode cloud que vous construisez sur la plate-forme AWS, vous “consommez” ces produits à un rythme plus rapide.
AWS a un plan clair en tête. Il vous permet d’accéder à un compte avec un niveau de service gratuit avec lequel vous pouvez confortablement expérimenter la construction d’un serveur Web ou le lancement d’une base de données, avant de mettre ces services en ligne. Ironiquement, c’est grâce à cette stratégie qui consiste à commencer petit à petit et à bâtir graduellement que de nombreuses organisations découvrent qu’elles n’ont pas tenu compte de l’ampleur des dépenses d’exploitation. Particulièrement en ce qui concerne la consommation de données.
Le contrôle des coûts est toutefois possible si vous prenez le temps de vous former de manière approfondie sur l’utilisation appropriée et stratégique des composants de la plate-forme AWS, avant de commencer à fournir des services sur cette plate-forme.
Et les ressources pour cette formation au contrôle des coûts existent, même sur la plate-forme elle-même.
Que font les services Web d’Amazon ?
Vendre les services qu’un ordinateur fournit est presque aussi ancien qu’une entreprise de vente d’ordinateurs elle-même. Amazon n’a certainement pas inventé cela non plus. Les systèmes de multipropriété en temps partagé des années 1960 ont permis aux universités de diminuer les coûts énormes d’acquisition des systèmes, et ce à une époque où les montants des frais de scolarité n’auraient pu compenser cela à eux seuls.
Mais au bon moment, Amazon a repéré avec beaucoup d’attention le seul type de service que presque toutes les entreprises pouvaient utiliser : la capacité d’exécuter un serveur virtuel qui exécute des sites Web.
Elastic Compute Cloud (EC2)
Le nom du premier service automatisé qu’AWS offre à ses clients est Amazon Elastic Compute Cloud (EC2). C’est l’endroit où AWS regroupe ses ressources virtuelles en instances de machines virtuelles, et les pousse dans des endroits choisis par le client pour mieux convenir à ses applications.
A l’origine, les configurations des instances EC2 imitaient celles des serveurs physiques du monde réel. Vous choisissiez donc l’instance qui correspondait le mieux aux caractéristiques du serveur que vous auriez normalement acheté, installé et entretenu dans vos propres locaux, pour exécuter l’application que vous lui aviez destiné.
Aujourd’hui, une instance EC2 peut être totalement exotique, configurée comme aucun serveur ne sera jamais fabriqué dans le monde. Étant donné que les serveurs virtuels englobent aujourd’hui l’ensemble de l’industrie des services Web, il importe peu qu’il n’y ait pas de correspondance avec la réalité.
Vous parcourez le catalogue très complet d’AWS et choisissez le nombre de processeurs, le stockage local, la mémoire locale, la connectivité et la bande passante dont vos applications ont besoin. Et si c’est plus que dans n’importe quel vrai serveur jamais fabriqué, so what ?
Vous payez ensuite les ressources que l’instance utilise, littéralement à la seconde. Si l’application que vous avez prévu est très étendue, comme un jeu multi-joueurs, alors vous pouvez raisonnablement estimer les coûts d’AWS pour la livraison de ce jeu à chaque joueur, et calculer les frais d’abonnement que vous pouvez facturer au joueur pour que cela vous rapporte un profit respectable.
Elastic Container Service (ECS)
Les machines virtuelles ont permis aux entreprises d’offrir des fonctionnalités via Internet sans avoir à modifier la façon dont leurs applications étaient architecturées. Les applications “croient” toujours qu’elles fonctionnent dans un serveur physique.
Au cours des dernières années, un nouveau véhicule pour la fonctionnalité de packaging a vu le jour, beaucoup mieux adapté à la diffusion dans le Cloud Computing. Il s’appelle “Docker container”, du nom de l’entreprise qui a développé un mécanisme automatisé pour le déployer sur une plate-forme de cloud computing (son nom à l’époque était dotCloud). Aujourd’hui, ce package est simplement appelé un conteneur.
La façon qu’à AWS de livrer des applications par conteneurs plutôt que par machines virtuelles se nomme Elastic Container Service (ECS). Ici, le modèle économique est complètement différent de celui d’EC2.
Parce qu’une application conteneurisée (désolé, il n’y a pas d’autre terme pour cela) peut utiliser une quantité variable de ressources à un moment donné, vous pouvez choisir de payer uniquement pour les ressources que l’application utilise, au moment où elle les demande.
Par analogie, voyez les choses de la façon suivante : Au lieu de louer une voiture, vous louez la route, vous payez l’essence consommée à chaque tour minute du moteur, l’oxygène brûlé à chaque combustion et la quantité de dioxyde de carbone produite par le catalyseur.
Avec ECS, vous louez la bande passante et payez pour le volume précis de données consommées et les cycles nécessaires au traitement, pour chaque seconde de fonctionnement de votre application. Amazon appelle ce modèle de prix Fargate, se référant au point le plus éloigné possible de la chaîne de livraison où le “tourniquet” est tourné et où des frais peuvent être comptabilisés, et engagés.
Amazon Lambda
Un service très important qui émerge du système qui rend ECS possible s’appelle Lambda, et pour de nombreuses industries et le monde universitaire, il est déjà en train de changer considérablement la façon dont les applications sont conçues. Lambda propose un principe appelé le modèle sans serveur (serverless model), dans lequel le serveur cloud fournit les fonctions dont une application peut avoir besoin sur la base d’une utilisation à l’unité, sans avoir besoin d’un pré-provisionnement.
Par exemple, si vous avez une fonction qui analyse une photographie et en isole la partie susceptible de contenir l’image d’un visage humain, vous pouvez utiliser cette fonction dans le cloud d’Amazon en utilisant le modèle sans serveur (serverless). Vous n’êtes pas facturé pour la VM ou le conteneur hébergeant la fonction, ni pour aucune des ressources dont elle a besoin ; AWS place plutôt son “tourniquet” au point où la fonction rend son résultat et prend fin. On vous facture donc des frais fixes pour la transaction.
Bien qu’Amazon n’ait peut-être pas eu l’idée du modèle sans serveur, Lambda a considérablement amélioré ce modèle. Aujourd’hui, les développeurs reconsidèrent la nature même de l’architecture des applications, avec pour résultat final qu’une toute nouvelle économie peut émerger autour de composants fluides de la fonctionnalité, par opposition à des monolithes rigides et indéchiffrables.
Simple Cloud Storage Service (S3)
Comme nous l’avons déjà mentionné, l’une des véritables percées d’Amazon a été la création de S3, son Simple Storage Service (le mot “Cloud” a depuis été calé au milieu de son nom). Pour ce modèle d’affaires, Amazon place des “tourniquets”, si vous voulez, à deux points du processus d’échange de données : quand les données sont téléchargées, et quand elles sont traitées au moyen d’un appel de récupération ou d’une requête de base de données. Les entrées et les sorties sont donc soumises à des frais.
AWS ne facture pas les clients en fonction du volume de stockage ou d’une fraction d’un dispositif physique consommée par les données. Au lieu de cela, il crée une construction virtuelle appelée un bucket, et l’affecte à un compte. De fait, ce bucket est sans fond ; il fournit des outils de base de données et d’autres services avec un moyen de traiter les données qu’il contient. Par défaut, chaque compte peut fonctionner jusqu’à 100 bucket, mais cette limite peut être augmentée sur demande.
Une fois les données stockées dans l’un de ces bucket, la façon dont la AWS monétise sa production à partir du bucket dépend de la façon dont ces données sont utilisées. Si une petite quantité de données n’est pas stockée et récupérée très souvent, AWS ne facture rien du tout. Mais si vous avez déjà déployé une application web qui a plusieurs utilisateurs, et que au cours de l’utilisation de cette application, ces utilisateurs accèdent tous aux données stockées dans un bucket S3, il est probable que cela entraîne des frais.
Et les requêtes de base de données, telles que la récupération d’informations de facturation ou de statistiques, seront facturées très différemment du téléchargement d’une vidéo ou d’un fichier multimédia.
Si AWS imposait des frais fixes pour l’extraction des données – disons, par mégaoctet téléchargé – alors, compte tenu de l’énorme différence d’échelle entre la valeur des données tabulaires d’une feuille de calcul et une vidéo 1080p, personne ne voudrait utiliser AWS pour faire du médias. Ainsi, utiliser S3 suppose que les types d’objets que vous stockerez dans des bucket détermineront la façon dont ces objets seront utilisés (“consommés”) par d’autres, et AWS établit un tarif pour la méthode d’utilisation.
Les services de base de données AWS
C’est là qu’Amazon ajoute un troisième tourniquet au modèle de données, en proposant des moteurs de bases de données capables d’utiliser les données stockées dans des bucket S3. Un moteur de base de données AWS est un type d’instance spécialisé : une image VM dans laquelle le système de gestion de base de données est déjà installé.
Pour les données relationnelles — celles qui sont stockées dans des tables et interrogées en langage SQL — AWS offre MariaDB (open source), Microsoft SQL Server, MySQL (open source), Oracle DB, PostgreSQL (open source), et Aurora d’Amazon.
Toute application qui peut s’interfacer avec une base de données dans l’un de ces formats, même si elle n’a pas été écrite pour le cloud au départ, peut être exécutée avec un de ces services. Alternativement, AWS propose DynamoDB pour une utilisation avec des magasins de clés/valeurs moins structurés, DocumentDB pour travailler avec des données textuelles longues comme dans un système de gestion de contenu, et ElastiCache pour traiter des volumes élevés de données en mémoire.
La mise en place d’un système de “Big Data”, tel que celui basé sur le framework Apache Hadoop ou Apache Spark, est généralement un effort important a effectuer de la part de toute organisation. Bien qu’ils s’abstiennent tous les deux d’invoquer l’expression, Spark et Hadoop sont tous deux des systèmes d’exploitation.
Ils permettent aux serveurs de prendre en charge des clusters de fournisseurs de données. Ainsi, tout effort visant à exploiter le cloud comme une grande plate-forme pour les données doit impliquer la configuration des applications s’exécutant sur ces plates-formes pour reconnaître le cloud comme leur centre de stockage.
AWS aborde ce problème en permettant à S3 de servir de ce que les ingénieurs de Hadoop et Spark appellent un lac de données (datalake) – un réservoir massif de données non structurées, non traitées et non raffinées. À l’origine, les lacs de données étaient “formatés” en utilisant le système de fichiers HDFS de Hadoop.
Certains ingénieurs ont depuis constaté que S3 est en fait préférable au HDFS, et certains vont jusqu’à dire que S3 est plus rentable. Apache Hadoop est désormais livré avec son propre connecteur S3, ce qui permet aux entreprises qui utilisent Hadoop sur site d’exploiter S3 en mode cloud au lieu de leur propre stockage sur site.
Dans un framework Big Data, le système d’exploitation regroupe les serveurs, avec leur traitement et leur stockage local, en une seule unité. Par conséquent, la mise à l’échelle de la puissance des processeurs implique une augmentation du stockage ; de même, le besoin d’espace supplémentaire pour les données implique l’ajout d’unités centrales de traitement.
L’approche d’AWS pour stationner l’ensemble du framework big data dans le cloud ne consiste pas à corréler les nœuds Spark ou Hadoop comme des machines virtuelles. Mais plutôt à déployer une infrastructure quelque peu différente qui gère les applications Hadoop ou Spark, et permet aux lacs de données S3 de devenir évolutifs de façon indépendante. AWS appelle ce système EMR, et il a fait des percées considérables, capitalisant sur le succès d’Amazon dans la substitution du HDFS.
Amazon Kinesis pour l’analyse de données
Kinesis s’appuie sur les composants des lacs de données d’AWS pour créer un service d’analyse – un service qui évalue les tendances sous-jacentes d’un flux de données ou d’une série temporelle, fait des prévisions et établit des corrélations aussi près que possible du temps réel.
Ainsi, si vous disposez d’une source de données telle qu’un journal de serveur avec des logs, des machines sur une chaîne de fabrication ou d’assemblage, un système de trading financier, ou dans l’exemple le plus complet, un flux vidéo, Kinesis peut être programmé pour générer des alertes et des messages analytiques en réponse aux conditions que vous spécifiez.
En utilisant des composants tels que Kinesis Streams, vous écrivez du code logique personnalisé pour spécifier les conditions qui méritent l’attention ou l’examen. Kinesis Data Firehose peut être configuré avec des filtres qui peuvent détourner certaines données du flux principal, en fonction des conditions ou des paramètres, vers un emplacement tel qu’un autre bucket S3 pour une analyse ultérieure.
Amazon Elastic Container Service pour Kubernetes
Comme Microsoft l’a si souvent démontré pendant son règne en tant que roi du système d’exploitation, si vous possédez la plate-forme sous-jacente, vous pouvez alors concéder des parties du territoire, en sachant que vous possédez le royaume auquel ces ilots appartiennent.
En créant le marché de la virtualisation, VMware a décidé de déplacer le siège du pouvoir dans le royaume des centres de données au niveau de l’hyperviseur. Et côté cloud public, Amazon a essayé de déplacer ce pouvoir vers l’instance EC2. Ces deux efforts ont été couronnés de succès.
Mais Kubernetes, en tant qu’orchestrateur open source d’applications basées sur des conteneurs, a cherché à placer une bombe sous ces acteurs, en démocratisant efficacement la manière dont de nouvelles classes d’applications étaient créées et déployées. C’était l’idée de Google, Docker sortirait du jeu, et même Microsoft contribuerait au plan.
Le service Kubernetes géré par AWS, appelé EKS et lancé en juillet 2018, représente la concession d’Amazon à cette tendance. Le mois de juillet précédent, Amazon rejoignait la Cloud Native Computing Foundation – la branche de la Linux Foundation qui supervise le développement de l’orchestrateur Kubernetes.
De cette façon, EKS peut fournir des services de gestion sur l’infrastructure supportant le déploiement Kubernetes d’un client de manière comparable à ce que proposent Google Cloud et Azure. Le provisioning des clusters peut se faire automatiquement. Mais cette dernière phrase n’a pas beaucoup de sens à moins que vous n’ayez lu des dizaines de milliers de pages de la documentation de Kubernetes.
La phrase la plus importante est la suivante : Vous pouvez choisir une application conteneurisée, dire à EKS de l’exécuter, puis EKS configurera les ressources dont l’application a besoin, et il exécutera l’application.
Donc, si vous avez, par exemple, un système de gestion de contenu open source compilé pour fonctionner dans des conteneurs, il vous suffit de pointer EKS vers le référentiel où se trouvent ces conteneurs et de dire “Go”. Si toutes les applications du monde pouvaient être automatisées exactement de cette façon, nous vivrions dans un monde très différent.
VMware Cloud on AWS
La façon dont VMware gère l’infrastructure virtualisée pour ses clients vSphere et la façon dont Amazon gère son infrastructure cloud pour AWS sont fondamentalement différentes. Cependant, la beauté de la virtualisation est qu’il est possible de configurer une plate-forme pour en exécuter une autre (comme Windows 10 exécute les applications Linux).
Il a fallu plusieurs années de collaboration entre les ingénieurs d’Amazon et de VMware avant qu’ils ne puissent mettre au point un système permettant à la couche de virtualisation NSX (qui permet de considérer les ressources sous-jacentes de tous les serveurs d’entreprise comme une infrastructure unique) d’être prises en charge par l’infrastructure cloud propriétaire AWS. Nous ne savons pas exactement comment cela fonctionne, mais pour l’instant, il semble que cela fonctionne.
Ainsi, avec un produit que VMware appelle VMware Cloud sur AWS, un environnement vSphere existant peut fournir des ressources à partir du cloud public d’Amazon, y compris dans le cadre de règles d’automatisation basées sur des règles. De cette façon, la puissance de calcul, le stockage et, dans une certaine mesure, les fonctionnalités de base de données, peuvent être intégrés dans un réseau d’entreprise comme des fluides. Et ces ressources dynamiques peuvent alors être déprovisionnées lorsqu’elles ne sont plus nécessaires.
Ces derniers mois, Amazon a étendu ses relations de travail avec VMware, permettant pour la première fois à AWS de proposer le déploiement de son propre matériel serveur chez les clients. C’est certainement une façon de rapprocher le cloud de l’entreprise.
AWS avait besoin d’un moyen de concurrencer Azure Stack de Microsoft, qui donne aux clients d’Azure les moyens d’exécuter les services Microsoft dans leurs propres centres de données comme Azure le ferait. C’est assez facile pour Microsoft, car une grande partie d’Azure Stack est déjà basée sur Windows Server.
Les serveurs d’Amazon, en revanche, sont regroupés par fonctionnalité tout à fait unique. AWS Outposts, comme Amazon l’appelle, donne aux grandes entreprises un moyen de laisser entrer cette fonctionnalité par la porte de service, au moins partiellement, en leur louant des serveurs Amazon exclusivement pour leur propre usage.