Google « cloud natif » et vous obtiendrez plus de 800 millions de visites. De toute évidence, le cloud natif est un terme important : ainsi que les gens ne savent pas vraiment ce que cela signifie réellement. Il y a quelque temps, lors d'une conversation avec quelqu'un d'autre « dans le secteur », j'ai dit : « Mais ce n'est pas cloud natif ! » » Elle acquiesça sagement. De toute évidence, cela signifie quelque chose, car nous pourrions nous mettre d’accord sur certaines constructions complexes en utilisant ce raccourci « cloud natif ». Creusons davantage.
Pour définir ce qu’est le cloud natif, nous devons commencer par une question plus simple :
Qu'est-ce que le nuage ?
Tout est question de désagrégation
Il y a près de 50 ans – avant la création de Microsoft – les étudiants de Harvard, Bill Gates et Paul Allen, ont écrit un interpréteur BASIC pour l'un des premiers micro-ordinateurs au monde, le MITS Altair 8080. Ils ont mis l'intégralité du programme sur bande papier (une des premières formes de stockage) et s'est envolé pour le Nouveau-Mexique pour montrer au MITS ce qu'ils avaient écrit.
Lors de la descente vers Albuquerque, Allen s'est rendu compte qu'il n'avait aucun moyen de lire la bande papier (nécessaire pour que l'interprète BASIC puisse la charger sur l'Altair 8080). Allen a rapidement écrit un programme pour lire la bande papier. Cela a fonctionné et le reste appartient à l'histoire.
Si vous voulez savoir ce que signifie « agrégé », c'est un excellent exemple. Tout ce qui était nécessaire pour exécuter l'interpréteur BASIC de Gates et Allen devait être écrit par Gates et Allen – y compris la routine permettant de lire le code de la bande papier dans la mémoire système !
Avance rapide vers le cloud computing, où l’objectif est de désagréger complètement. Désagréger quoi ? Bien - peut. Le calcul est séparé de tout le reste, vous pouvez donc acheter la quantité de calcul dont vous avez besoin indépendamment de tout le reste. Idem pour le stockage et le réseau.
Mais ce n'est qu'une question d'infrastructure. Le cloud désagrège également les logiciels. Alors que Gates et Allen devaient écrire chaque ligne de code pour leur application, les applications cloud exploitent aujourd'hui des « services » pour gérer des tâches spécifiques. Au lieu d'années de codage d'applications massives et monolithiques, les applications cloud d'aujourd'hui sont construites avec des centaines de lignes de code qui relient des dizaines (ou des centaines) de services cloud.
Cloud est l'extension logique de la philosophie Unix de composabilité mieux articulée par Doug McElroy, l'inventeur du tube Unix, « Écrivez des programmes qui font une chose et la font bien. Écrivez des programmes pour travailler ensemble.
C'est l'essence du cloud. Mais pourquoi désagréger ? Au niveau le plus simple, la désagrégation offre élasticité et agilité.
Élasticité
Les ressources requises par toute charge de travail varient au fil du temps. Par exemple, celui de James Cameron Avatar a repoussé les limites des effets spéciaux. Le rendu d’une seule image nécessitait l’équivalent de 3,000 48 vCPU dans le cloud pendant une heure. Depuis qu'Avatar a été tourné à 192 images par seconde et a duré 1.6 minutes, il y avait plus d'un demi-million d'images à restituer. Cela représente plus de XNUMX milliard d'heures de cycles de processeur virtuel.
Le film a été en production pendant 12 ans au total, mais comme pour tous les films, une grande partie du rendu final approchait de la sortie du film. Le cloud a fourni l'élasticité Les effets spéciaux d'Avatar le fournisseur avait besoin de faire le travail. Le producteur exécutif des effets visuels, David Conley, a souligné qu'ils n'auraient pas pu réaliser cela sans AWS.
L'élasticité s'applique au calcul, au stockage, à la mise en réseau et à presque toutes les ressources requises. Le cloud permet d'augmenter et de diminuer facilement et rapidement l'utilisation selon les besoins.
Agilité
L’autre avantage du cloud est l’agilité dans tous les sens du terme. Le cloud permet :
- Agilité de développement en raison de l'architecture de services susmentionnée. Les développeurs exploitent un large éventail de services et réduisent le codage d'années et de millions de lignes de code à des semaines et des milliers de lignes.
Par ailleurs, cette nouvelle « architecture de services » bénéficie de l’effet réseau. Plus les charges de travail utilisent des services, plus les tiers sont motivés à développer de nouveaux services. Et plus il y a de services, plus les développeurs sont motivés à utiliser des services tiers. Ce cercle vertueux a accéléré le passage des pratiques de codage monolithiques aux architectures de services.
- Agilité des infrastructures, car au lieu d’acheter, d’installer et de gérer l’infrastructure, les utilisateurs demandent simplement ce dont ils ont besoin – quand ils en ont besoin – par le biais de requêtes simples. Le terme « infrastructure-as-code » fait référence à l'utilisation d'un simple « code » pour provisionner toute l'infrastructure dont vous avez besoin en quelques minutes au lieu de semaines ou de mois.
- Agilité économique, parce que vous ne jouez que pour ce dont vous avez besoin, quand vous en avez besoin. Avatar n'a pas eu besoin de construire un énorme centre de données SFX et de le gérer pendant 12 ans. Au lieu de cela, ils ont simplement créé ce dont ils avaient besoin quand ils en avaient besoin.
Maintenant que nous comprenons ce qu’est le cloud, nous pouvons discuter de ce qu’il faut pour être véritablement cloud natif.
Qu'est-ce que le cloud natif ?
La réponse simple est qu'une application cloud native interagit avec le cloud en utilisant cloud-native primitifs. Par exemple, une application cloud native appellerait directement les services de stockage natifs d'Amazon AWS (S3, EBS, EFS, etc.). Ce principe s’applique à tous les services cloud – ordinateur, magasin, réseau, etc.
Pour les applications « nées dans le cloud » (c'est-à-dire conçues dès le premier jour pour fonctionner dans et uniquement dans le cloud), cela est assez simple. Mais pour les applications nées dans un monde sur site, un exercice de refactorisation douloureux doit être effectué. Notez que cela nécessite que l'application soit entièrement séparée de toute l'infrastructure : calcul, stockage et mise en réseau.
La deuxième exigence importante pour être véritablement cloud natif est d’être géré « en tant que code ». Cela signifie être capable de faire tourner l'application avec quelques lignes de code, par opposition au processus traditionnel sur site consistant à tout installer et configurer manuellement sur une période de plusieurs semaines.
Comme pour une femme enceinte, il n’y a pas de « partiellement cloud natif ». Une application est ou n'est pas native du cloud. Si une application n'est pas entièrement désagrégée et n'adopte pas la méthodologie « as-code », elle perd les avantages d'élasticité et d'agilité promis par le cloud.
Existe-t-il des solutions de stockage cloud natives ?
Avant de parler des solutions de stockage cloud natif, passons en revue les « primitives » du cloud en ce qui concerne le « stockage ».
C'est du stockage objet (Azure blob / AWS S3). Il s’agit d’une couche de persistance des données incroyablement abordable, évolutive, disponible et durable, offrant d’excellentes performances, mesurées par le débit. Son inconvénient est qu’il s’agit d’une nouvelle interface RESTful et finalement cohérente.
Ensuite, vous avez ce que j'appellerais le SAN d'une personne pauvre, c'est-à-dire EBS sur AWS et Managed Disk sur Azure. Ils se présentent comme un « disque local », sont résilients et se comportent généralement comme un disque ordinaire dans un ancien serveur de stockage. Ces primitives agissent comme l'équivalent d'un « disque local protégé » (sauf qu'il n'est pas attaché à l'instance de calcul locale). Ces primitives ont des performances modérées et peuvent prendre en charge des « lectures/écritures aléatoires » mais sont coûteuses.
Et enfin, vous avez des SSD NVMe attachés à l'instance, qui ressemblent plus à une extension de la DRAM dans la mesure où les données sur ces « disques » ne persistent pas lors des redémarrages de l'instance, et pourtant ils sont beaucoup moins chers que la DRAM ou le « disque local protégé » tout en ayant caractéristiques de performance entre ces deux.
Jusqu’à présent, le secteur du stockage a obstinément résisté au cloud. Les fournisseurs existants (Dell, NetApp) disposent de beaucoup trop de code spécifique au matériel (dépendance profonde à la NVRAM, couplage étroit des couches de résilience des données et de services de données) pour refactoriser leurs offres afin de tirer parti des primitives cloud natives.
Et puis sont arrivés VAST et Pure, qui ont également choisi une pile de stockage optimisée sur le plan matériel.
Pure's stockage en bloc dans le cloud L'offre est à la fois pertinente dans la mesure où elle utilise des primitives cloud natives pour fournir ces services de données en bloc tant souhaités par les clients de Pure ET au-delà de la tristesse ! Qui diable utilise un SAN dans le cloud ? C'est tout simplement ahurissant. Et pendant que nous abordons ce sujet, j'ai du mal à comprendre qui utilise VMWare dans le cloud. Cela aussi laisse perplexe !
Parmi les fournisseurs de stockage de nouvelle génération, c'est en fait Weka.io qui impressionne. Ils disposent d’une architecture « cloud native » et exploitent le stockage d’objets cloud comme couche de résilience. Maintenant, si seulement ils n’avaient pas la réputation d’être un acteur de niche du HPC et d’être une « Ferrari de verre »…
Alors, en tant que CTO de Qumulo, qu'ai-je à dire sur l'offre cloud de Qumulo ?
Restez à l'écoute.
Notez la date dans vos calendriers ; Jeudi 9 novembre 2023, et préparez-vous à être époustouflé 🙂
