Transition vers le cloud natif —

Cet article est la partie 3 d’Ampere Computing Accélérer le Cloud série. Vous pouvez lire la partie 1 iciet Partie 2 ici.

Comme nous l’avons montré dans Partie 2 de cette série, le redéploiement d’applications sur une plate-forme de calcul cloud native est généralement un processus relativement simple. Par exemple, Momento a décrit son expérience de redéploiement comme «significativement moins de travail que prévu. Pelikan a travaillé instantanément sur le T2A (la plate-forme cloud native basée sur Ampere de Google) et nous avons utilisé nos processus de réglage existants pour l’optimiser. »

Bien sûr, les applications peuvent être complexes, avec de nombreux composants et dépendances. Plus la complexité est grande, plus les problèmes qui peuvent survenir sont nombreux. De ce point de vue, l’expérience de redéploiement de Momento des processeurs natifs du cloud Pelikan Cache vers Ampere offre de nombreuses informations. L’entreprise avait mis en place une architecture complexe et souhaitait automatiser tout ce qu’elle pouvait. Le processus de redéploiement leur a donné l’occasion d’y parvenir.

Applications adaptées au traitement cloud natif

La première considération consiste à déterminer comment votre application peut bénéficier d’un redéploiement sur une plate-forme de calcul cloud native. La plupart des applications cloud sont bien adaptées au traitement cloud natif. Pour comprendre quelles applications peuvent le plus bénéficier d’une approche native du cloud, nous examinons de plus près l’architecture du processeur natif du cloud Ampere.

Pour obtenir une efficacité de traitement plus élevée et une dissipation de puissance plus faible, Ampere a adopté une approche différente pour concevoir nos cœurs : nous nous sommes concentrés sur les besoins de calcul réels des applications cloud natives en termes de performances, de puissance et de fonctionnalités, et avons évité d’intégrer les fonctionnalités de processeur héritées qui avaient été ajouté pour les cas d’utilisation non liés au cloud. Par exemple, les extensions vectorielles évolutives sont utiles lorsqu’une application doit traiter de nombreux graphiques 3D ou des types spécifiques de traitement HPC, mais s’accompagnent d’un compromis entre puissance et densité de cœur. Pour les applications qui nécessitent SVE comme les jeux Android dans le cloud, un fournisseur de services cloud peut choisir de coupler des processeurs Ampere avec des GPU pour accélérer les performances 3D.

Pour les charges de travail natives du cloud, la consommation d’énergie réduite et l’augmentation de la densité des cœurs Ampere signifient que les applications s’exécutent avec des performances plus élevées tout en consommant moins d’énergie et en dissipant moins de chaleur. En bref, une plate-forme de calcul cloud native fournira probablement des performances supérieures, une plus grande efficacité énergétique et une densité de calcul plus élevée à un coût d’exploitation inférieur pour la plupart des applications.

Là où Ampère excelle, c’est avec des applications basées sur des microservices qui ont de nombreux composants indépendants. De telles applications peuvent bénéficier de manière significative de la disponibilité de plus de cœurs, et Ampere offre une densité de cœur élevée de 128 cœurs sur un seul circuit intégré et jusqu’à 256 cœurs dans un châssis 1U avec deux sockets.

En fait, vous pouvez vraiment voir les avantages d’Ampere lorsque vous effectuez une mise à l’échelle horizontale (c’est-à-dire, équilibrez la charge sur de nombreuses instances). Parce qu’Ampere évolue linéairement avec la charge, chaque cœur que vous ajoutez offre un avantage direct. Comparez cela aux architectures x86 où l’avantage de chaque nouveau cœur ajouté diminue rapidement (voir Figure 1).

Figure 1 : Étant donné que l’ampère évolue linéairement avec la charge, chaque cœur ajouté offre un avantage direct. Comparez cela aux architectures x86 où l’avantage de chaque cœur ajouté diminue rapidement.

Dépendances propriétaires

Une partie du défi du redéploiement des applications consiste à identifier les dépendances propriétaires. Toute partie de la chaîne d’approvisionnement logicielle où des fichiers binaires ou des packages x86 dédiés sont utilisés nécessitera une attention particulière. Beaucoup de ces dépendances peuvent être localisées en recherchant du code avec « x86 » dans le nom de fichier. Le processus de substitution est généralement facile à réaliser : remplacez le package x86 par la version appropriée basée sur Arm ISA ou recompilez le package disponible pour la plate-forme cloud native Ampere, si vous avez accès au code source.

Certaines dépendances présentent des problèmes de performances mais pas de problèmes fonctionnels. Envisagez un framework pour l’apprentissage automatique qui utilise un code optimisé pour une plate-forme x86. Le framework fonctionnera toujours sur une plate-forme cloud native, mais pas aussi efficacement qu’il le ferait sur une plate-forme x86. Le correctif est simple : identifiez une version équivalente du framework optimisé pour Arm ISA, comme celles incluses dans Amplis IA. Enfin, il existe des dépendances écosystémiques. Certains logiciels commerciaux dont dépend votre application, tels que la base de données Oracle, peuvent ne pas être disponibles en version basée sur Arm ISA. Si tel est le cas, il se peut qu’il ne s’agisse pas encore d’une application appropriée à redéployer jusqu’à ce que ces versions soient disponibles. Des solutions de contournement pour les dépendances de ce type, telles que leur remplacement par une alternative compatible avec le cloud natif, peuvent être possibles, mais peuvent nécessiter des modifications importantes de votre application.

Certaines dépendances sont en dehors du code d’application, telles que les scripts (par exemple, les playbooks dans Ansible, les recettes dans Chef, etc.). Si vos scripts supposent un nom de package ou une architecture particulière, vous devrez peut-être les modifier lors du déploiement sur une plate-forme informatique native cloud. La plupart des changements comme celui-ci sont simples, et un examen détaillé des scripts révélera la plupart de ces problèmes. Veillez à ajuster les hypothèses de nommage que l’équipe de développement peut avoir faites au fil des ans.

La réalité est que ces problèmes sont généralement faciles à gérer. Vous avez juste besoin d’être minutieux pour les identifier et les traiter. Cependant, avant d’évaluer le coût pour remédier à de telles dépendances, il est logique de considérer le concept de dette technique.

Dette technique

Dans l’article de Forbes, La dette technique : un obstacle difficilement mesurable à la transformation numérique, la dette technique est définie comme « l’accumulation de solutions relativement rapides aux systèmes, ou d’investissements lourds mais malavisés, qui peuvent être des puits d’argent à long terme ». Des solutions rapides permettent aux systèmes de continuer à fonctionner, mais la dette technique accumulée finit par devenir trop élevée pour être ignorée. Au fil du temps, la dette technique augmente le coût de changement d’un système logiciel, de la même manière que l’accumulation de calcaire dans une machine à café finira par dégrader ses performances.

Par exemple, lorsque Momento a redéployé Pelikan Cache sur le processeur natif du cloud Ampere, ils disposaient d’un code de journalisation et de surveillance qui s’appuyait sur un code open source vieux de 15 ans. Le code a fonctionné, il n’a donc jamais été mis à jour. Cependant, comme les outils ont changé au fil du temps, le code a dû être recompilé. Il y avait une certaine quantité de travail nécessaire pour maintenir la rétrocompatibilité, créant des dépendances sur l’ancien code. Au fil des ans, toutes ces dépendances s’additionnent. Et à un moment donné, lorsque la maintenance de ces dépendances devient trop complexe et trop coûteuse, vous devrez passer à un nouveau code. La dette technique est appelée, pour ainsi dire.

Lors du redéploiement d’applications sur une plate-forme de calcul cloud native, il est important de comprendre votre dette technique actuelle et comment elle oriente vos décisions. Des années de maintenance et d’adaptation du code hérité accumulent une dette technique qui rend le redéploiement plus complexe. Cependant, ce n’est pas un coût de redéploiement en soi. Même si vous décidez de ne pas redéployer sur une autre plate-forme, vous devrez un jour rattraper toutes ces solutions rapides et autres décisions pour retarder la mise à jour du code. Vous n’avez tout simplement pas encore eu à le faire.

Quelle est la réalité de la dette technique ? Selon une étude de McKinsey (voir article Forbes), 30% des DSI de l’étude estimaient que plus de 20% de leur budget technique pour les nouveaux produits étaient en fait détournés vers la résolution de problèmes liés à la dette technique.

Le redéploiement est une excellente occasion de prendre en charge certaines des applications de dette technique acquises au fil des ans. Imaginez récupérer une partie des « 20 % » que votre entreprise détourne pour résoudre la dette technique. Bien que cela puisse ajouter du temps au processus de redéploiement, la prise en charge de la dette technique a l’avantage à long terme de réduire la complexité de la gestion et de la maintenance du code. Par exemple, plutôt que de reporter les dépendances, vous pouvez « réinitialiser » nombre d’entre elles en transférant le code vers votre environnement de développement actuel. C’est un investissement qui peut rapporter des dividendes immédiats en simplifiant votre cycle de développement.

Anton Akhtyamov, chef de produit chez Plesk, décrit son expérience de redéploiement. « Nous avons eu quelques limitations juste après le portage. Plesk est une grande plate-forme sur laquelle de nombreux modules/extensions supplémentaires peuvent être installés. Certains n’étaient pas pris en charge par Arm, comme Dr. Web et Kaspersky Antivirus. Certaines extensions n’étaient pas disponibles non plus. Cependant, la majorité de nos extensions étaient déjà prises en charge à l’aide de packages reconstruits pour Arm par les fournisseurs. Nous avons également notre propre code backend (principalement C++), mais comme nous l’avons déjà adapté de x86 pour prendre en charge x86-64, nous avons simplement reconstruit nos packages sans aucun problème critique.

Pour deux autres exemples de redéploiement dans le monde réel vers une plate-forme cloud native, consultez Porter Takua au bras et OpenMandriva sur Ampere Altra.

Dans la partie 4 de cette série, nous nous pencherons sur le type de résultats auxquels vous pouvez vous attendre lors du redéploiement d’applications sur une plateforme de calcul cloud native.