Accélérer le nuage: la transition vers le nuage natif

Cet article est la troisième partie de la série "Accelerating Cloud Computing" d'Ampere Computing. Vous pouvez lire les première et deuxième parties ici.

Comme nous l'avons démontré dans la deuxième partie de cette série, le redéployer les applications aux plates-formes informatiques natives dans le cloud est souvent un processus relativement simple. Par exemple, Momento a décrit son expérience de redéploiement comme «beaucoup moins de travail que ce à quoi nous nous attendions.

Bien sûr, l'application peut être complexe, avec de nombreux composants et dépendances. Plus vous avez de complexité, plus vous pourriez avoir de problèmes. De ce point de vue, l'expérience de Momento dans le redéploiement du cache Pelikan aux processeurs natifs d'Ampère Cloud fournit de nombreuses informations. La société a construit une architecture complexe qu'elle souhaite automatiser autant que possible. Le processus de redéploiement leur offre la possibilité d'y parvenir.

Applications adaptées au traitement des natifs cloud

La première chose à considérer est de déterminer comment votre application profite du redéploiement sur les plateformes informatiques natives du cloud. La plupart des applications cloud sont parfaites pour le traitement des natifs cloud. Pour comprendre quelles applications peuvent bénéficier le plus des approches natives dans le cloud, nous avons soigneusement examiné l'architecture du processeur natif du cloud Ampère.

Pour obtenir une efficacité de traitement plus élevée et une consommation d'énergie plus faible, Ampère a adopté différentes approches pour concevoir notre noyau - nous nous concentrons sur les besoins informatiques réels des applications natives en termes de performance, de puissance et de fonctionnalité. Fonctionnalités du processeur ajoutées aux cas d'utilisation non nuclé. Par exemple, la mise à l'échelle des vecteurs évolutive est utile lorsqu'une application doit gérer une grande quantité de graphiques 3D ou un type spécifique de traitement informatique haute performance, mais apporte un compromis en termes de consommation d'énergie et de densité centrale. Pour les applications qui nécessitent SVE, telles que les jeux Android dans le cloud, les fournisseurs de services cloud ont la possibilité d'associer les processeurs AMPERE avec des GPU pour accélérer les performances 3D.

Pour les charges de travail natives dans le nuage, la consommation d'énergie réduite et l'augmentation de la densité du noyau à des noyaux AMPERE signifient que les applications fonctionnent à des performances plus élevées tout en consommant moins de puissance et en dissipant moins de chaleur. En bref, pour la plupart des applications, les plates-formes informatiques natives dans le cloud peuvent fournir des performances supérieures, une efficacité énergétique plus élevée et une densité de calcul plus élevée tout en réduisant les coûts opérationnels.

ampère est spécialisé dans les applications basées sur le microservice avec de nombreux composants indépendants. Ces applications peuvent grandement bénéficier de la disponibilité de plus de cœurs, Ampère offre une densité de noyau élevée de 128 cœurs sur une seule puce et jusqu'à 256 cœurs dans un châssis 1U avec deux emplacements.

En fait, lorsque vous évoluez horizontalement (c'est-à-dire l'équilibrage de la charge dans de nombreuses instances), vous pouvez vraiment voir les avantages d'Ampère. Parce qu'Ampère évolue linéairement avec charge, chaque noyau que vous ajoutez apportera des avantages directs. Comparant cela avec l'architecture x86, dans laquelle les avantages de chaque nouveau noyau sont rapidement réduits (voir figure 1).

Figure 1: Parce qu'Ampère évolue linéairement avec charge, chaque noyau ajouté apporte des avantages directs. Comparant cela avec l'architecture x86, dans laquelle les avantages de chaque nouveau noyau sont rapidement réduits.

dépendances propriétaires

L'un des défis confrontés au redéploiement des applications est d'identifier les dépendances propriétaires. Partout dans la chaîne d'approvisionnement logicielle qui utilise des fichiers binaires ou des packages logiciels dédiés à X86, il faut en prendre note. Beaucoup de ces dépendances peuvent être trouvées en recherchant du code contenant "x86" dans le nom du fichier. Le processus de remplacement est généralement facile à compléter: remplacer le package x86 par la version appropriée basée sur ARM ISA, ou recompiler les packages disponibles pour la plate-forme native Ampère Cloud si vous avez accès au code source.

Certaines dépendances entraîneront des problèmes de performance, mais pas de problèmes. Considérez un cadre d'apprentissage automatique qui utilise le code optimisé pour la plate-forme x86. Le framework peut toujours fonctionner sur des plates-formes natives cloud, mais elle n'est pas aussi efficace que sur les plates-formes basées sur x86. La solution est simple: identifier les versions équivalentes des cadres optimisés pour ARM ISA, tels que ceux inclus dans AMPERE AI. Enfin, il existe des dépendances écosystèmes. Certains logiciels commerciaux sur lesquels votre application s'appuie, comme Oracle Database, peut ne pas être disponible en version basée sur ARM ISA. Si tel est le cas, ce n'est peut-être pas une application appropriée pour le redéploiement tant qu'une telle version n'est disponible. Des solutions de contournement pour de telles dépendances, telles que les remplacer par des alternatives conviviales natives dans le cloud, peuvent être possibles, mais cela peut nécessiter des modifications importantes de votre application.

Certaines dépendances sont en dehors du code d'application, telles que les scripts (c'est-à-dire les livres de jeu dans ANSIBLE, les recettes de chef, etc.). Si votre script suppose un nom ou un schéma de package spécifique, ils peuvent devoir être modifiés lors du déploiement sur une plate-forme informatique native dans le cloud. La plupart de ces changements sont simples et une revue détaillée du script révèlera la plupart de ces problèmes. Faites attention à l'ajustement des hypothèses de dénomination que l'équipe de développement peut avoir faite au fil des ans.

La réalité est que ces problèmes sont généralement faciles à gérer. Il vous suffit de les identifier et de les traiter soigneusement. Cependant, avant d'évaluer le coût de la lutte contre ces dépendances, il est nécessaire de considérer le concept de dette technique.

dette technique

Dans l'article de Forbes "Dette technique: obstacles difficiles à mesurables dans la transformation numérique", la dette technique est définie comme "l'accumulation de réparations relativement rapides dans le système, ou des investissements lourds mais à tort, peut être financier à long terme, À long terme. Au fil du temps, la dette technique augmente le coût du changement dans les systèmes logiciels, tout comme l'accumulation d'échelle dans les machines à café finira par réduire ses performances.

Par exemple, lorsque Momento a redémarré le cache Pelikan sur les processeurs natifs Ampère Cloud, ils avaient installé le code de journalisation et de surveillance qui s'est appuyé sur le code open source d'il y a 15 ans. Le code fonctionne, il n'est donc jamais mis à jour. Cependant, à mesure que l'outil change avec le temps, le code doit être recompilé. Certains travaux sont nécessaires pour maintenir la compatibilité en arrière, créant des dépendances sur l'ancien code. Toutes ces dépendances se sont accumulées au fil des ans. À un moment donné, lorsque le maintien de ces dépendances devient trop complexe et coûteux, vous devrez simplement passer à un nouveau code. On peut dire que la dette technique est considérée.

Lors du redéployage de votre application sur une plate-forme informatique native du cloud, il est important de comprendre votre dette technique actuelle et comment elle pilote vos décisions. Le maintien et l'adaptation du code hérité au fil des ans peuvent accumuler une dette technique, ce qui rend le redéploiement encore plus compliqué. Cependant, ce n'est pas le coût du redéploiement. Même si vous décidez de ne pas redéployer sur une autre plate-forme, un jour vous devrez compenser toutes ces corrections rapides et autres décisions pour reporter la mise à jour de votre code. Vous ne l'avez pas encore fait.

Quelle est la réalité de la dette technique? Selon une étude McKinsey (voir l'article de Forbes), 30% des DSI dans l'étude ont estimé que plus de 20% de leur budget technique pour les nouveaux produits a été utilisé pour résoudre les problèmes liés à la dette technique.

Le déploiement rouge est une excellente occasion de traiter une partie de la dette technique accumulée par la demande au fil des ans. Imaginez reprendre une partie des «20%» de la dette technologique que votre entreprise utilise pour aborder. Bien que cela puisse augmenter le temps du processus de redéploiement, la gestion de la dette technique a les avantages de simplifier la complexité de la gestion et du maintien du code à long terme. Par exemple, vous pouvez "réinitialiser" de nombreuses dépendances en migrant votre code vers votre environnement de développement actuel au lieu de continuer à compter sur eux. Il s'agit d'un investissement qui peut instantanément payer en simplifiant votre cycle de développement.

Anton Akhtyamov, chef de produit chez Plesk, a décrit son expérience dans le redéploiement. "Après le portage, nous avons rencontré certaines limites. Plesk est une grande plate-forme qui peut installer de nombreux modules / extensions complémentaires. Certains ne sont pas pris en charge par ARM, comme le Dr Web et l'antivirus Kaspersky. Certaines extensions ne sont pas non plus disponibles. Cependant, cependant, La plupart de nos extensions sont déjà prises en charge à l'aide de packages reconstruits par les fournisseurs pour ARM. Problèmes critiques.

Pour des exemples plus pratiques de redéploiement des applications aux plates-formes natives dans le cloud, voir le portage de Takua à OpenMandriva sur ARM et AMPERE Altra.

Dans la quatrième partie de cette série, nous plongerons dans les résultats auxquels vous pouvez vous attendre lors du redéploiement de vos applications à une plate-forme informatique native du cloud.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!