L’investissement pour passer au Cloud Native —

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

Profitant de la Plate-forme de calcul native dans le cloud Ampère implique beaucoup moins de temps et d’efforts qu’on ne le pense. En effet, la majorité du travail de redéploiement d’une application sur un serveur basé sur Arm a déjà été effectuée pour vous ou est simplement une recompilation.

En bref, étant donné que les processeurs cloud natifs d’Ampere utilisent l’architecture de jeu d’instructions Arm (ISA), le logiciel qui s’exécute sur Arm s’exécute sur Ampere. Au cours des cinq dernières années, la prise en charge d’Arm par la communauté open source a connu une croissance exponentielle, avec une énorme variété de nouveaux logiciels et services disponibles. Par exemple, des applications telles que Redis, NGINX, Memcached, MySQL et Cassandra disposent déjà de versions validées basées sur ARM.

Voici ce que cela signifie pour les développeurs : la majorité des logiciels utilisés par une entreprise s’exécutent déjà dans le cloud ou sont probablement déjà prêts pour le cloud.

Système d’exploitation (SE): Presque tous les systèmes d’exploitation disponibles ont été portés sur Arm ISA et fonctionnent sur des cœurs basés sur Arm. Par conséquent, les processeurs cloud natifs d’Ampere prennent en charge les versions publiées des principaux systèmes d’exploitation utilisés dans le cloud.

Pour garantir davantage la fiabilité et les performances, Ampere teste et valide les images publiques des systèmes d’exploitation et des applications prépackagées sur ses processeurs natifs du cloud Ampere. De cette façon, les développeurs peuvent être sûrs que leurs applications fonctionneront de manière transparente sur Ampere.

Code préemballé: Souvent, une partie substantielle d’une application est construite à l’aide de composants d’application prépackagés. Les images publiques basées sur Arm pour la majorité de ces applications – tout de MYSQL, PostgreSQL, Cassandra, NGINX et Squid – ont déjà été testées et validées pour les processeurs natifs du cloud Ampere. Ainsi, la préparation de cette partie de l’application pour une plateforme de calcul cloud native est relativement simple : il suffit d’utiliser l’image basée sur Arm déjà disponible. Aucun portage ou réécriture complexe de logiciel n’est nécessaire.

Langages compilés: En général, la plupart des problèmes critiques liés au redéploiement des serveurs Web proviennent du code qui nécessite une compilation pour s’exécuter sur Ampere. Le processus de redéploiement nécessite une étape supplémentaire pour le code écrit dans des langages tels que Go, C et C++, car les fichiers binaires existants ont été créés pour un environnement x86. Étant donné que la grande majorité des langages de programmation sont disponibles sur Arm ainsi que sur x86, la plupart des problèmes de redéploiement impliquent simplement l’exécution de scripts de construction sur un nœud de construction Ampere pour générer les bons fichiers binaires.

En interne/sur mesure: Les applications personnalisées peuvent être divisées en quatre types : interprétatives, de haut niveau, binaires et spécifiques au matériel.

• Code interprétatif : le code écrit dans un langage interprétatif tel que Java ou Python qui n’est pas compilé est facile à redéployer sur une plate-forme cloud native. Étant donné que le code est interprété, il n’est pas nécessaire de modifier le code pour qu’il s’exécute sur une plate-forme de calcul cloud native. Au lieu de cela, le code s’exécute sur un interpréteur compilé pour Arm au lieu de x86. En général, le redéploiement de l’interpréteur pour les processeurs cloud natifs est un processus simple qui peut être effectué en quelques minutes si une image n’est pas déjà disponible.
• Code de haut niveau : la préparation de code écrit dans un langage de haut niveau comme C/C++ pour une plate-forme cloud native peut également être relativement simple. Dans la plupart des cas, l’application n’a besoin d’être recompilée que pour Arm ISA. Généralement, cela est géré en reconfigurant simplement le compilateur pour Arm plutôt que x86. S’il y a des avertissements ou des erreurs lors de la compilation, il s’agit généralement d’un processus simple pour les résoudre ou pour confirmer qu’ils ne sont pas un problème.
• Fichiers binaires : pour de nombreuses applications, le problème de redéploiement le plus courant qui se pose est l’utilisation de fichiers binaires. Les binaires sont du code (souvent des bibliothèques) qui sont inclus dans une application. Cela peut inclure des produits disponibles uniquement sous forme binaire qui sont des dépendances de votre application. Avant de créer l’application, vérifiez simplement les dépendances de votre code et assurez-vous que les fichiers binaires utilisés sont basés sur Arm et non sur x86.
• Code spécifique au matériel : le code écrit pour un processeur spécifique ou utilisant des fonctionnalités spécifiques du processeur à des fins de performances, telles que les bibliothèques graphiques, peut nécessiter un portage limité. Ce n’est le cas que lorsqu’aucune version spécifique à Arm n’est déjà disponible. Dans tous les cas, le processus de portage est souvent simple et prend tout au plus quelques heures.

Redéploiement dans le monde réel

Voyons ce qu’il faut pour redéployer une application sur le processeur natif du cloud Ampere. Considérez Momento, dédié à offrir des services qui gèrent les caches à grande échelle afin que les développeurs n’aient pas à le faire. Momento Serverless Cache est construit sur Pelikan, un moteur de mise en cache open source, conçu à l’origine pour les besoins de mise en cache particuliers de Twitter. Pelikan a récemment été entièrement réécrit en Rust. Momento souhaitait redéployer Pelikan sur des machines virtuelles Tau T2A basées sur Ampere et hébergées par Google.

Le redéploiement a été rapide et transparent, sans aucun changement de code nécessaire pour que Pelikan et Momento Serverless Cache soient opérationnels. De plus, l’équipe Momento a pu mettre en œuvre quelques optimisations simples – sans ajustements de code – pour tripler rapidement le débit. Nous entrerons dans les détails du type d’avantages en termes de performances auxquels vous pouvez vous attendre dans la partie 4 de cette série.

Plesk est un autre exemple de redéploiement. Le logiciel de Plesk permet aux utilisateurs de gérer l’infrastructure Web via un panneau de contrôle central. Lukas Hertig, SVP Business Development and Strategic Alliances chez Plesk, décrit sa propre expérience du processus de redéploiement. « C’était au départ une idée folle de ma part d’avoir une version Arm. Quelques semaines plus tard, mon équipe d’ingénieurs est revenue et a dit : « Oh, ça marche maintenant. Beaucoup plus rapide que d’habitude ! »

Plesk sert l’espace SMB, où l’option de devenir natif du cloud n’est pas évidente. Mais peu de temps après le redéploiement, Hertig déclare : « Nous avons déjà dépassé 1 000 instances Arm en production. » L’essentiel : Arm et la communauté open source ont fait un excellent travail en développant et en développant l’écosystème cloud Arm. Bien entendu, la complexité du redéploiement de votre application sur une plate-forme de calcul cloud native dépend de l’origine de votre code. En général, cependant, l’investissement pour redéployer la plupart des applications sur un processeur cloud natif est minime, puisque 80 à 90 % des applications ont juste besoin d’être recompilées.

Dans la partie 3 de cette série, nous explorerons plus en détail le processus de redéploiement cloud natif.