Les migrations de charges de travail infonuagiques d’une plateforme à une autre exigent un examen minutieux de multiples aspects des plateformes actuelles et cibles. Ces considérations lors de la migration vers le cloud incluent les différences de configurations, de services, de capacités, de technologies et de soutien. Les responsables de la transformation doivent équilibrer et jongler avec de nombreux facteurs tout en établissant un dossier commercial solide avant de passer de l’infrastructure sur site à l’infonuagique. Dans cet article de blogue, nous aborderons certains des enjeux auxquels ils font face lorsqu'ils envisagent la migration d’OpenShift sur site vers le cloud.
Mais avant d’entrer dans les aspects, les dirigeants d'entreprise devront répondre à la question principale : quelles sont les raisons de migrer de l’infrastructure sur site vers le cloud public ? Il peut s’agir de plusieurs facteurs, tels que la fermeture de centres de données, l’utilisation de services infonuagiques, et la performance. Peu importe la raison, le déplacement de votre plateforme de conteneurs du cloud sur site vers le cloud public impliquera de comprendre les complexités en jeu et les moyens de les résoudre.
Voici 15 points à considérer pour migrer avec succès OpenShift sur site vers le cloud
Voici une liste de vérification des facteurs clés à examiner avant de faire cette transition cruciale :
Dépendances envers l’infrastructure matérielle
Le premier facteur à examiner avant une migration vers le cloud est de comprendre s’il existe des dépendances à la plateforme matérielle sous-jacente ou non. C’est là que les nœuds de travail Red Hat OpenShift sont installés. Les dépendances peuvent aller de dispositifs de stockage haute performance, GPU, SR-IOV, et TPU à un déploiement bare metal de la plateforme OpenShift. À cause de cela, certaines des fonctionnalités et capacités matérielles peuvent ne pas être disponibles sur le cloud public, ce qui pourrait compromettre la migration. Il est donc recommandé de vérifier certaines dépendances applicatives avant d’envisager la migration vers le cloud.
Soutien des applications commerciales prêtes à l’emploi (COTS) fonctionnant sur la plateforme de conteneurs
Red Hat OpenShift Container Platform (OCP) est le chef de file du marché des plateformes de conteneurs d’entreprise. Elle détient plus de 44 % des parts de marché avec plus de 3000 clients actifs à l’échelle mondiale qui exécutent leurs applications sur la plateforme de production. C’est pourquoi un grand nombre de fabricants (OEM) de produits COTS ont certifié leurs applications sur OpenShift. Cependant, il n’est pas nécessaire que ces OEM certifient et prennent en charge leurs applications conteneurisées sur une offre Kubernetes infonuagique publique. Par conséquent, si vous possédez un nombre significatif de telles solutions OEM, il convient de vérifier leur support avant de procéder à la migration.
Soutien pour les environnements d’exécution, le middleware et les technologies d’intégration
De même, il existe un grand nombre d’environnements d’exécution, de middleware et de piles d’intégration sur lesquels les applications s’appuient. Les fournisseurs de ces environnements définissent la plateforme Kubernetes sur laquelle ils soutiennent leurs offres. Si l’organisation choisit une offre Kubernetes sur le cloud public qui n’est pas incluse dans les plateformes supportées par ces environnements, elle pourrait rencontrer des problèmes de support sur le cloud public.
Outils d’écosystème intégrés à la plateforme Kubernetes
Outre les éléments déjà évoqués, les outils d’écosystème sont un autre pilier essentiel de la solution PaaS. Vu la popularité de la plateforme OCP, de nombreux outils d’écosystème pour la surveillance, la journalisation, la sécurité, la sauvegarde, l’alerte, etc. sont disponibles avec OCP. Le même riche écosystème d’outils pourrait ne pas être offert avec les plateformes de cloud public. Il serait donc avisé de vérifier auprès de votre fournisseur d’outils d’écosystème la compatibilité de l’offre Kubernetes sur le cloud public. De plus, tous les hyperscalers du cloud public offrent et promeuvent leur propre gamme d’outils pour fidéliser leur clientèle à leurs services.
Soutien pour les images de base utilisées pour les images de conteneur – images de conteneurs certifiées
Red Hat OpenShift comprend l’Universal Base Image (UBI), que les clients peuvent utiliser avec leur plateforme OCP. L’UBI sert à créer des images de base certifiées, testées, soutenues et sécurisées. Lorsque vous passez à une plateforme de conteneurs alternative, telle qu’une offre Kubernetes sur le cloud public, la nouvelle plateforme pourrait ne pas prendre en charge les images de base sous-jacentes. Il serait alors nécessaire de reconstruire toutes les images de conteneur sur la plateforme cloud, ce qui remettrait en question l’universalité des images de base certifiées et sécurisées. Il est donc primordial de considérer le coût lié à la reconstruction de toutes les images et au choix d’une nouvelle image de base.
Soutien des solutions OEM comme CloudPaks
Un nombre important d’offres ou bouquets OEM, tels que les CloudPaks d’IBM, sont livrés avec la plateforme de conteneurs Red Hat OpenShift. Si vous utilisez ces solutions, il conviendrait de demeurer avec Red Hat OCP comme plateforme sous-jacente. Ces bouquets ne sont pas disponibles avec les plateformes Kubernetes du cloud public (du moins, pour le moment). Il faudrait donc exploiter une combinaison de plateformes Kubernetes, ce qui ajouterait de la complexité et une charge au niveau de la gestion de plusieurs solutions.
Considérations pour les PVs dans le cas de charges de travail avec état
La migration d’applications sans état est généralement plus facile. Dans le cas d’applications avec état, il y a un surcroît de gestion des volumes persistants et de leurs demandes. Votre application utilise peut-être actuellement certaines charges de travail avec état qui devront être migrées vers le service Kubernetes sur le cloud public. Il existe des complexités reliées à la migration de ces volumes de stockage et à l’assurance de leur compatibilité. Cela inclut les volumes de stockage disponibles sur site et ceux compatibles avec les solutions Kubernetes sur le cloud public. Par ailleurs, vous pourriez devoir recourir à une solution tierce de migration pour assurer la cohérence des données transférées vers le cloud public.
Incompatibilités de versions Kubernetes et indisponibilité de fonctionnalités
Les développeurs Kubernetes modernisent fréquemment le logiciel, ce qui rend difficile le contrôle de la version lors de la migration vers le cloud public. Votre application pourrait ne pas être compatible avec la dernière version de Kubernetes alors que vous utilisez peut-être une version plus ancienne d’OCP sur site.
Puisque la technologie évolue rapidement, de nouvelles fonctionnalités sont continuellement introduites et d’anciennes deviennent désuètes. Certaines fonctionnalités utilisées sur site pourraient ne pas exister dans la version sur le cloud public. C’est pourquoi la compatibilité des versions et des fonctionnalités est essentielle pour garantir que vos applications ne subissent pas d’impacts lors de leur migration dans l’environnement Kubernetes du cloud public.
Interfaces (intra-cluster ou externes) et dépendances associées
Il existe des applications héritées, de grandes bases de données, des services d’authentification et d’autres applications sur site qui s’intègrent aux applications conteneurisées. Pourtant, toutes les intégrations auxquelles votre application recourt ne sont pas conteneurisées. Cela pourrait ne pas sembler problématique actuellement, mais au départ du milieu actuel, ces intégrations pourraient échouer et causer des problèmes de performance. Il est important de tenir compte de ces intégrations et dépendances externes dans votre stratégie de migration du site vers le cloud.
Soutien des configurations hybrides et multi-cloud
Les plateformes de conteneurs d’entreprise comme OpenShift soutiennent plusieurs configurations de déploiement : sur site, en mode hybride, sur cloud public, sur bare metal, en multi-cloud, etc. Cependant, la plupart des offres sur cloud public ne proposent que des services PaaS cloud publics, ce qui limite la capacité d’étendre et de migrer d’une plateforme à une autre.
Différences technologiques
Même si Kubernetes est le cœur d’OpenShift, il ne s’agit que d’un des nombreux composants du produit OpenShift. Disposer uniquement de Kubernetes pour exécuter une charge de travail critique de production n’est pas suffisant. D’autres composants sont nécessaires : authentification, réseautique, sécurité, surveillance, gestion des journaux, etc. Red Hat regroupe toutes ces capacités dans un seul produit et assure leur cohésion en fournissant les mises à jour, les améliorations et les correctifs appropriés pour l’ensemble du produit, et pas seulement Kubernetes. De plus, certaines capacités sont gérées différemment dans OpenShift comparativement au Kubernetes source. Voici quelques apports de valeur ajoutée par Red Hat, comme RHEL, UBI, SCC et d’autres optimisations. Il faut tenir compte de ces aspects lors de la migration d’OpenShift sur site vers le cloud public.
Méthodologie de migration recommandée par les hyperscalers
L’approche recommandée par les fournisseurs de services Kubernetes sur le cloud public comprend la reconstruction du conteneur et une phase de test approfondie de ces applications dans l’environnement de test du cloud public. Cette approche retarde non seulement la migration mais ajoute également un fardeau en matière d’effort de test et d’application de correctifs en cas d’échec. Évidemment, si la plateforme cible est OpenShift, la reconstruction n’est pas nécessaire et les tests rigoureux sont moindres, ce qui accélère et simplifie la migration.
Dépendance à l’égard d’un fournisseur
Lorsqu’on déplace des charges de travail vers un service Kubernetes d’un fournisseur hyperscaler du cloud public, on souhaite souvent intégrer les services PaaS du cloud public, ce qui crée implicitement une dépendance forte. Ensuite, si l’entreprise souhaite changer de fournisseur, elle est prisonnière de cet écosystème. Il faudra alors recommencer à zéro pour intégrer les services PaaS du nouveau fournisseur. Il est donc judicieux d’utiliser des outils indépendants des fournisseurs pour l’intégration des écosystèmes lors de la migration vers le cloud public. Peu importe si OpenShift est impliqué ou non.
Interface ou perspective du développeur
La plateforme Red Hat OpenShift Container offre des interfaces intuitives pour les développeurs et les administrateurs. Cette interface fournit des informations basées sur une interface graphique (GUI) à propos des applications en cours d’exécution et de leurs intégrations. Cet aspect est fort utile pour les développeurs dans la gestion de leurs applications, et il n’est généralement pas offert dans le cloud public.
Capacités PaaS intégrées et sécurisées par défaut et gestion des permissions simplifiée dans OpenShift
Comme mentionné précédemment, Red Hat OpenShift intègre des fonctionnalités supplémentaires et offre un soutien pour ces intégrations. De plus, lors de la mise à jour, la cohésion des intégrations est maintenue, évitant ainsi la gestion séparée des outils et des intégrations. Voici quelques-unes des fonctionnalités d’OCP :
- Registre de conteneurs interne
- Pile de journalisation basée sur EFK
- Surveillance basée sur Prometheus
- Jenkins
Toutefois, dans les services K8s sur cloud public, tous ces éléments ne sont pas toujours intégrés, et vous devrez les gérer séparément. Cela représente un fardeau supplémentaire pour les grands déploiements.
Comment le déploiement d’OpenShift sur IaaS dans un cloud public peut-il résoudre ces préoccupations ?
Comme nous le savons, Red Hat OpenShift est pleinement compatible et soutenu non seulement dans les environnements sur site, mais également auprès de tous les grands fournisseurs IaaS cloud public. Il n’est donc plus nécessaire de s’inquiéter du soutien du middleware, des runtimes, des intégrations, des applications COTS, de l’UBI, etc. lors de la migration vers le cloud public. De plus, vous pouvez continuer à profiter de capacités techniques avancées telles que les projets OpenShift, les configurations de déploiement, les flux d’images, etc. L’une des capacités majeures d’OpenShift demeure la sécurité par défaut. Il est possible de continuer à en bénéficier, notamment en n’autorisant pas les conteneurs à fonctionner avec les privilèges root, avec SELinux, SCC, la maturité de RHEL, etc.
Nous recommandons soit un déploiement géré d’OpenShift Container Platform, soit un déploiement cloud public basé sur IaaS avec Red Hat OpenShift (initialement en mode hybride et éventuellement entièrement dans le cloud public). Il s’agit de la solution la plus rapide, simple et abordable pour transformer ou migrer vos charges de travail conteneurisées vers le cloud public dans un climat de confiance, sans se soucier de la compatibilité applicative. Chez HCLTech, nous pouvons vous aider à analyser en détail votre environnement actuel et vous suggérer la meilleure voie à suivre en tenant compte de votre contexte actuel.
