Vous migrez des applications vers le cloud ? Lisez ceci d’abord.
Introduction
Les environnements de cloud computing occupent désormais une place prépondérante dans le paysage informatique, les entreprises migrant de plus en plus régulièrement leurs applications existantes sur site vers le cloud. Toutefois, migrer une application vers le cloud ne consiste pas simplement à la transférer vers une machine virtuelle chez un fournisseur de services cloud. Les motivations varient d’une entreprise à l’autre, mais toutes doivent tenir compte de certains facteurs clés et suivre les bonnes pratiques afin de garantir la réussite de leur migration vers le cloud. Pour tirer pleinement parti de cette migration, il est essentiel de la planifier en amont, tant au niveau de l’architecture de l’application que de la transition de l’environnement sur site vers le cloud.
Vue d’ensemble
Cloud ou sur site : les principales différences
Un environnement cloud fonctionne différemment d’un environnement sur site. Certaines différences entre ces deux environnements sont évidentes, notamment le fait que les ressources informatiques sont détenues et gérées par une autre entreprise plutôt qu’en interne. Toutefois, plusieurs des différences les plus importantes ne sont pas liées à la technologie. En règle générale, toute technologie proposée par un fournisseur de services cloud est également disponible sur site. Le cloud offre un autre modèle de consommation, et non une autre technologie. Autrement dit, les avantages d’une migration vers un fournisseur de services cloud résident dans la manière dont les ressources informatiques sont consommées, et non dans les ressources informatiques elles-mêmes.
Les fournisseurs de services cloud ne peuvent pas nécessairement reproduire toutes les fonctionnalités disponibles sur site, telles que les politiques de conformité en matière d’audit des données conçues pour le matériel sur site. Les composants cloud étant dispersés géographiquement, la latence est généralement plus élevée dans les déploiements cloud. Les fournisseurs de services cloud sont également confrontés à d’autres contraintes. Comme ils appliquent des normes communes à l’ensemble de leurs clients, les possibilités de personnalisation des environnements informatiques sont réellement limitées. Par exemple, rares sont les fournisseurs de services cloud qui proposent des équipements informatiques rares et atypiques.
Mais si une entreprise est en mesure de fonctionner dans ces limites, un fournisseur de services cloud peut lui offrir des capacités de consommation hors de portée de la plupart des sociétés. Un fournisseur de services cloud peut exploiter des centres de données dans le monde entier, ce qui permet aux organisations de choisir celui dans lequel héberger leurs ressources informatiques. Il peut également prendre en charge les coûts fixes, permettant ainsi à une entreprise de ne payer que les ressources réellement utilisées. Grâce à des économies d’échelle inégalées par la plupart des entreprises, il peut investir massivement dans des systèmes de gestion et d’automatisation des déploiements. Il convient de noter qu’aucun de ces avantages n’est de nature technique ; les atouts d’un fournisseur de services cloud résident plutôt dans les choix et la structure de coûts proposés au client.
Afin d’atténuer les limites et de tirer parti des avantages d’un fournisseur de services cloud, un service informatique doit modifier sa façon de déployer les applications et adapter ses flux de travail afin d’exploiter au mieux les atouts relatifs de ce fournisseur, tout en évitant de dépendre de caractéristiques pour lesquelles un environnement cloud est désavantagé, telles que la latence.
Motivations de la migration vers le cloud
Les économies de coûts sont souvent citées comme l’un des principaux moteurs de la migration vers le cloud, mais les véritables raisons sont généralement plus nuancées. La plupart des motivations se répartissent en trois catégories : prévisibilité, productivité et agilité.
Les fournisseurs de cloud public renforcent la prévisibilité en proposant des technologies sous forme de solutions prêtes à l’emploi, et prennent ainsi en charge une partie des risques opérationnels liés à l’informatique. Comme ils assurent la maintenance de l’infrastructure et en assument la responsabilité, les entreprises n’ont plus à se préoccuper de ces aspects. De même, les fournisseurs de cloud mettent généralement à disposition des outils permettant de mieux comprendre les opérations informatiques et d’en accroître la visibilité. Les coûts du cloud public étant généralement fonction de la consommation, une entreprise peut établir un lien plus étroit entre les bénéfices d’une application, tels que les revenus générés, et ses coûts d’exploitation. Plus l’application est utilisée, plus les coûts augmentent, mais les bénéfices aussi. Le passage des dépenses d’investissement aux dépenses d’exploitation réduit la nécessité d’anticiper la croissance future dans les décisions d’achat. La gestion de ces incertitudes par le fournisseur de cloud apporte des bénéfices mesurables.
Une autre raison d’adopter le cloud public est le gain de productivité. Les outils de collaboration et d’automatisation proposés par les fournisseurs comptent parmi les plus avancés du marché. En outre, le fait de ne pas avoir à gérer l’infrastructure permet au personnel informatique de se concentrer sur des initiatives stratégiques pour l’entreprise, tandis que la rationalisation des opérations, qui peuvent être gérées depuis n’importe où, accroît sa productivité.
La dernière raison d’adopter le cloud public est peut-être la plus convaincante : l’agilité. Comme le fournisseur de services cloud donne l’illusion de ressources infinies disponibles à tout moment, la rapidité et l’orientation des initiatives de l’entreprise ne sont plus tributaires des contraintes de mise à disposition des ressources informatiques. Les ressources peuvent être déployées en quelques secondes ou quelques minutes. Un projet peut utiliser un environnement informatique complexe pendant une courte période sans avoir à se soucier de la mise hors service du matériel à la fin du projet. Les applications peuvent être déployées, mises à l’échelle et supprimées rapidement, sans considération pour les ressources matérielles.
Obstacles à la migration vers le cloud
Bien que la migration vers le cloud présente de nombreux avantages, elle comporte également plusieurs défis. Les obstacles et les risques varient selon l’étape du processus à laquelle ils surviennent : avant, pendant ou après la migration. Anticiper ces obstacles et ces risques augmente les chances de réussite de la migration.
La planification en amont est sans doute l’étape la plus critique du processus de migration. Une migration peut échouer si l’application n’est pas repensée pour tirer parti des fonctionnalités du cloud. C’est également le bon moment pour faire le point sur la complexité de l’application et commencer à la maîtriser. La formation des équipes informatiques doit elle aussi intervenir dès le début du projet. Les déploiements dans le cloud ont tendance à s’effectuer en silos et à entraîner une prolifération des outils ; une planification dès les premières phases peut donc contribuer à fluidifier le processus de migration.
La migration d’applications vers le cloud a tendance à prendre plus de temps et à être plus complexe que prévu initialement. Pour limiter les problèmes, commencez par une application de petite taille et relativement indépendante, afin que les éventuelles difficultés rencontrées aient un impact minimal. Les enseignements tirés de cette première migration pourront être appliqués aux migrations futures.
Les problèmes à long terme liés aux migrations apparaissent une fois la migration terminée. Des préoccupations en matière de sécurité et de conformité peuvent survenir, notamment parce que le périmètre de sécurité est plus difficile à définir dans un environnement cloud. La prise en charge des systèmes existants peut s’avérer plus complexe lorsque les anciens et les nouveaux systèmes se trouvent non seulement dans des environnements différents, mais ont également été développés selon des cultures différentes. Certaines organisations se sont inquiétées de leur dépendance vis-à-vis d’un fournisseur cloud, en particulier avec l’essor des conteneurs. Enfin, les contraintes budgétaires peuvent poser problème, car les coûts variables du cloud peuvent être difficiles à prévoir chaque trimestre.
Comment choisir les applications à migrer
Une technique d’évaluation des applications consiste à utiliser la matrice maturité/localisation. Examinez vos applications afin de déterminer le niveau de maturité dont vous avez besoin. Il peut être préférable d’héberger sur site les applications qui offrent un avantage concurrentiel ou répondent à des besoins de niche. À l’autre extrémité du spectre, les applications à faible coût ou axées sur la maîtrise des coûts, notamment des coûts liés aux changements, sont souvent bien adaptées à un environnement cloud. L’évolutivité fait également partie des facteurs à prendre en compte. Supposons qu’une nouvelle application ait été déployée et que sa charge puisse à terme être multipliée par 100. Pour anticiper cette croissance dans le cadre d’un déploiement sur site, il faudrait largement surdimensionner l’infrastructure, ce qui entraînerait des dépenses d’investissement supplémentaires pour des ressources inutilisées. En revanche, si cette même application était déployée dans un environnement cloud, les coûts évolueraient en fonction de la croissance et aucun surdimensionnement ne serait nécessaire.
Les problématiques réseau peuvent également influer sur le choix des applications à migrer vers un environnement cloud. Si une application compte une forte proportion d’utilisateurs répartis géographiquement, par exemple un vaste réseau de revendeurs, ou un nombre important d’utilisateurs accédant à leur messagerie à distance, un déploiement sur site achemine alors l’ensemble de ce trafic vers le centre de données. Comme le trafic transite déjà par Internet, ces applications sont peu sensibles à la latence. Lorsque de telles applications sont placées dans un environnement cloud, la latence réseau ne change pas, mais cela libère de la bande passante dans les centres de données sur site, qui serait autrement utilisée par les utilisateurs répartis géographiquement.
Dans le même temps, certaines raisons peuvent justifier de conserver des applications sur site. Pour les applications dont la durée de vie prévue est courte, les risques et les coûts liés à une migration peuvent ne pas en valoir la peine. Certaines applications dépendent d’une faible latence réseau et de vitesses de stockage élevées, et pourraient être nettement moins performantes dans un environnement cloud. Les exigences de conformité et de sécurité sont également souvent invoquées pour conserver des applications sur site. Certaines procédures d’audit supposent un accès physique aux systèmes et aux données afin de vérifier ces dernières, tandis que d’autres exigent que l’application et le système d’exploitation s’exécutent directement sur du matériel physique (c’est-à-dire qu’ils ne peuvent pas fonctionner sur une machine virtuelle). Avec le temps, les procédures de conformité s’adapteront à l’environnement cloud, mais, dans de nombreux cas, ce n’est pas encore le cas. Plutôt que de risquer un échec aux audits de conformité en plaçant des applications dans le cloud, il peut être plus judicieux de conserver pour l’instant ces applications sensibles sur site. Certaines applications doivent prendre en charge des systèmes et des processus hérités et ne peuvent donc pas, de manière réaliste, être réarchitecturées pour fonctionner dans le cloud. Il peut également être préférable de conserver ces applications sur site. Pour toutes ces raisons, la migration de certaines applications doit être moins prioritaire que celle d’applications mieux adaptées à un environnement cloud.
Applications qu’il vaut mieux conserver sur site
- Applications à courte durée de vie
- Applications nécessitant une faible latence
- Applications présentant des enjeux de conformité
- Applications prenant en charge les systèmes existants
Considérations relatives à la transition
De nombreuses organisations doivent surmonter des difficultés au cours du processus de migration. Une question majeure à résoudre est de savoir comment effectuer la bascule proprement dite. Une approche consiste à utiliser le DNS pour diriger les requêtes vers l’application sur site jusqu’à ce que l’application cloud ait été testée de manière approfondie, puis à modifier les enregistrements DNS afin de les diriger vers l’application cloud. Le DNS contient une valeur de durée de vie (TTL) qui permet aux clients de mettre en cache la réponse DNS pendant un certain temps. Avant la transition, il peut être judicieux de définir une TTL faible, de quelques secondes seulement par exemple, afin qu’après la bascule, les clients soient rapidement dirigés vers les nouvelles applications. Cette approche comporte toutefois certains risques. La réduction de la TTL peut considérablement augmenter le trafic DNS ainsi que la charge pesant sur les serveurs. Une organisation peut ignorer la TTL et conserver les données en cache plus longtemps que la durée spécifiée, de sorte que certains utilisateurs continuent d’être dirigés vers l’application sur site bien après la bascule. Envisagez de tester la robustesse de votre infrastructure DNS avant d’adopter cette approche.
Le processus de transition peut également révéler des problèmes liés à la nouvelle application qui n’avaient pas été détectés lors des tests. Pour se prémunir contre les défaillances éventuelles de l’application, il est possible de prévoir un plan de repli permettant de revenir à l’application sur site en cas de problème. Malheureusement, une transition bidirectionnelle complique la synchronisation des données et nécessite donc beaucoup plus de planification et de tests en amont. Une approche plus sophistiquée consiste à effectuer une transition partielle, appelée test canari, qui permet de faire migrer une partie des utilisateurs vers l’application cloud tout en surveillant son fonctionnement. À mesure que la confiance dans l’application augmente, davantage d’utilisateurs, puis à terme la totalité d’entre eux, peuvent être migrés. À l’inverse, si un problème survient, les utilisateurs ayant migré peuvent revenir à l’application sur site. Le test canari peut être réalisé par un contrôleur de mise à disposition d’applications (ADC) programmable au moyen de F5® iRules®, ce qui réduit les risques tout en offrant davantage d’options à l’équipe d’exploitation pendant la période de transition.
Recommandations
Concevez les applications différemment pour le cloud
L’une des principales erreurs commises par les organisations lors de la migration d’applications consiste à ne pas repenser leur architecture pour le cloud. Consacrer le temps nécessaire à la modification de la structure de l’application afin de tirer parti des spécificités d’un environnement cloud peut apporter des avantages considérables.
Par exemple, la mise à l’échelle dans un environnement cloud est très simple par rapport à une infrastructure sur site. Au lieu de concevoir l’application et de la tester pour une charge maximale, concevez-la de manière à ce qu’elle soit légère, mais évolutive. Il est inutile de supporter les coûts supplémentaires liés à une infrastructure surdimensionnée lorsque l’utilisation de l’application est susceptible de varier considérablement. Privilégiez plutôt une infrastructure réduite, prête à évoluer. De même, certaines défaillances, telles que les coupures de courant, sont moins probables dans un environnement cloud ; il est donc moins nécessaire de concevoir l’architecture en fonction de celles-ci.
En revanche, les environnements cloud introduisent de nouvelles contraintes rarement rencontrées sur site. Les architectes cloud soulignent que la conception doit prévoir la défaillance de n’importe quelle instance de machine virtuelle à tout moment dans le cadre du fonctionnement normal. Le stockage diffère également dans un environnement cloud. Les architectures sur site utilisent couramment un stockage local par blocs. Cette même option est disponible dans les environnements cloud, mais elle ne peut pas être partagée. La combinaison d’un état local non partagé et de la défaillance d’une instance pourrait conduire à une catastrophe. Il existe d’autres modèles de stockage, tels que le stockage d’objets ou les services de stockage clé-valeur. Il est possible de pallier les contraintes d’un environnement cloud en repensant l’architecture de l’application.
Déterminez ce qu’il convient de conserver sur site
Il est judicieux de conserver certaines applications ou certains systèmes de contrôle sur site. De nombreuses organisations conserveront Active Directory sur site tout en utilisant la fédération pour étendre la gestion des identités à un environnement cloud. De même, un contrôleur de mise à disposition d’applications (ADC) fournit de nombreux services de sécurité pour assurer la mise à disposition des applications, notamment des pare-feu, des pare-feu d’applications web, une protection contre les attaques DDoS et l’interception SSL/TLS, ainsi que le chaînage de services. Un ADC offre également une gestion avancée du trafic et un proxy programmable, ainsi que la gestion des identités et des accès.
Les organisations ont généralement regroupé ces services applicatifs en dehors de l’application, car ils ne relèvent pas de la logique métier, mais de considérations opérationnelles. Afin de permettre des changements opérationnels indépendamment des calendriers de publication des applications, de nombreuses entreprises centralisent l’expertise métier pouvant être appliquée à toutes les applications en utilisant un ADC comme point de contrôle stratégique. Toutefois, les environnements cloud remettent ce modèle en question.
L’une des premières approches adoptées pour la mise à disposition d’applications dans les environnements cloud consistait à reproduire les services ADC à l’aide des outils natifs de chaque environnement cloud. Il est rapidement apparu que les fournisseurs de services cloud n’offraient pas tous le même niveau de fonctionnalités natives, ce qui obligeait les entreprises à choisir entre le maintien de normes hétérogènes de mise à disposition des applications dans les environnements cloud et sur site, ou la refonte de toutes les applications selon le plus petit dénominateur commun.
À mesure que les entreprises se sont développées dans plusieurs environnements cloud, ces deux options sont devenues moins attrayantes. Prenons l’exemple d’une organisation qui fait appel à trois fournisseurs de services cloud tout en exploitant un centre de données sur site. Elle devait soit maintenir quatre ensembles de compétences en matière de SSL/TLS, quatre autres en matière de protection contre les attaques DDoS, et ainsi de suite, soit se standardiser sur un ensemble de services de base de plus en plus disparate (et limité). Le simple déploiement d’une nouvelle application dans un environnement cloud supplémentaire entraînait un coût marginal important, lié soit à la mobilisation d’une nouvelle équipe d’experts du domaine, soit à la définition de nouvelles normes à appliquer à toutes les applications existantes.
Mais il existe une troisième option pour fournir des services cohérents dans tous les environnements. F5 Application Connector permet à une seule équipe d’experts du domaine de gérer toutes les applications, quel que soit l’endroit où elles sont hébergées. En utilisant des appliances matérielles ou logicielles BIG-IP® existantes, une entreprise peut déployer des services applicatifs avancés complets en amont de n’importe quelle application, où qu’elle se trouve, offrant ainsi à toutes les applications un point de contrôle stratégique géré par une seule équipe d’experts du domaine. En outre, Application Connector renforce la sécurité en supprimant toute adresse IP publique visible, ce qui réduit les surfaces d’attaque. En conservant les clés de chiffrement dans un emplacement centralisé plutôt que dans les instances cloud, les entreprises ont l’assurance que leurs informations cryptographiques critiques restent confidentielles. Enfin, Application Connector améliore l’efficacité de votre déploiement cloud en permettant à l’instance de proxy de détecter automatiquement les nouveaux nœuds de charge de travail.
Évaluez soigneusement vos besoins en matière de stockage
L’une des principales différences entre les applications sur site et les applications cloud réside dans le stockage de l’état de l’application. Dans leur immense majorité, les architectures sur site utilisent un stockage local par blocs, tel qu’un disque dur ou un disque SSD. Une application cloud peut également utiliser un stockage par blocs, mais celui-ci est local à l’instance et l’architecture doit prévoir la défaillance éventuelle des instances. Si les entreprises ne doivent revoir qu’un seul aspect de la conception de leurs applications lors de leur migration vers le cloud, ce doit être la gestion de l’état.
Un type courant de stockage dans le cloud est le stockage d’objets, dans lequel chaque objet est essentiellement un fichier auquel on accède par un nom. En général, ce type de stockage ne comporte au maximum qu’un seul niveau hiérarchique (c’est-à-dire un dossier ou un répertoire) ; il peut donc être difficile de transposer un système de fichiers traditionnel en objets. Comme les objets ne peuvent pas être modifiés, mais uniquement créés, lus et supprimés, le stockage d’objets convient bien au contenu statique, tel que les images, mais pas au stockage de l’état. De nombreuses applications partent du principe qu’un fichier peut être modifié ; elles ne fonctionneront donc pas avec des objets.
Parmi les autres solutions de stockage figurent les magasins clé-valeur et les bases de données transactionnelles traditionnelles. Contrairement à un système de fichiers, il ne s’agit pas de solutions de stockage à proprement parler, mais elles permettent de conserver des données et sont proposées sous forme de services supplémentaires. Avec une architecture adaptée, l’état peut être stocké dans un service clé-valeur ou de base de données.
En résumé : préparez-vous avant la migration
Les environnements de cloud computing offrent des avantages, mais uniquement si les applications clés sont repensées afin de tirer parti des fonctionnalités du cloud tout en limitant l’impact de ses contraintes. Les environnements cloud présentent des scénarios de défaillance différents et souvent une latence réseau accrue, mais permettent une mise à l’échelle rapide et offrent un choix de centres de données dans le monde entier. La préparation d’une migration vers le cloud implique notamment de déterminer quelles applications migrer et lesquelles conserver sur site.
Le processus de transition lui-même doit également faire l’objet d’une réflexion et d’une planification minutieuses, avec notamment un plan de retour arrière au cas où l’application cloud ne fonctionnerait pas comme prévu. Dans le cadre de cette planification, certaines organisations conservent un contrôleur de mise à disposition d’applications (ADC) sur site afin de disposer d’un point de contrôle stratégique pour toutes leurs applications, quel que soit leur lieu d’hébergement. Enfin, planifiez soigneusement la manière dont l’application cloud stockera les données et les informations d’état. Quelle que soit la façon dont vous choisissez de migrer vos applications — et votre entreprise — vers le cloud, envisagez de vous faire accompagner par un partenaire cloud expérimenté.
PUBLIÉ LE 16 AOÛT 2017