Migration des applications d’entreprise vers le cloud : 5 règles à suivre (et 1 à enfreindre)
Les organisations qui envisagent de migrer leurs applications d’entreprise vers le cloud public doivent veiller à transférer également les services de mise à disposition des applications dont celles-ci dépendent dans le centre de données. En outre, la migration vers le cloud offre l’occasion d’organiser et de rationaliser la sécurité et les accès, de gagner en visibilité sur le trafic des applications dans le cloud et de concevoir un plan de reprise après sinistre robuste.
Introduction
Pour de nombreuses organisations, la migration des applications d’entreprise vers le cloud public peut s’avérer très intéressante. Elle leur permet de se défaire des coûts fixes et des actifs liés à l’exploitation d’une infrastructure informatique à grande échelle, notamment de centres de données coûteux remplis d’équipements de différentes générations et présentant divers niveaux de maintenabilité. Si ces serveurs assurent le fonctionnement de l’entreprise, ils consomment également de l’énergie, produisent de la chaleur et nécessitent des contrats de support onéreux. La gestion du cycle de vie, de la maintenance et de l’hébergement physique de l’infrastructure informatique exige des compétences, du temps et un budget qui peuvent détourner les services informatiques de leur mission principale : fournir les applications indispensables au fonctionnement de l’entreprise.
Se débarrasser de ce casse-tête opérationnel et de ce gouffre financier pour entrer dans un nouveau monde où un ancien serveur ou une ancienne application peut être mis hors service par un simple appel d’API est souvent judicieux sur les plans financier et opérationnel. Si vous n’avez plus à gérer l’infrastructure de base sur laquelle repose votre système informatique, vous pouvez vous concentrer davantage sur la sécurité, les performances et la disponibilité des applications qui incarnent la véritable valeur ajoutée de l’informatique pour l’entreprise.
Mais avant d’atteindre ce nirvana d’une infrastructure virtualisée ne nécessitant aucune maintenance, vous devrez déterminer la meilleure façon de transférer vos applications vers leur nouvel environnement. La migration d’une application vers le cloud public implique certains choix. Vous pouvez entièrement repenser l’architecture de l’application pour l’adapter à un environnement cloud, ce qui peut offrir une expérience utilisateur élégante et fluide, mais demande souvent beaucoup de temps et de travail. Vous pouvez également vous contenter de transférer les applications exécutées dans votre centre de données vers un cloud public, sans apporter de modifications majeures à leur conception ou à leur plateforme.
Il existe plusieurs bonnes raisons d’envisager ce modèle de « lift and shift » : on estime qu’il coûte environ 10 fois moins cher,1 il est presque toujours beaucoup plus rapide et, dans certains cas, il ne vaut tout simplement pas la peine de réécrire une application dont la durée de vie est limitée. Mais pour réussir une migration « lift and shift », vous devrez suivre quelques règles… et en enfreindre une.
Règle n° 1 : traitez les serveurs comme du bétail, pas comme des animaux de compagnie
Commençons par la règle à enfreindre. Le principe consistant à traiter les serveurs comme du bétail est souvent considéré comme inhérent aux architectures cloud. Si une instance de serveur ne fonctionne pas correctement, ne perdez pas de temps à la réparer : supprimez-la et redéployez-en une nouvelle. Ne mettez pas à niveau les systèmes d’exploitation ni les logiciels ; déployez simplement de nouvelles instances et mettez fin aux anciennes. C’est un conseil judicieux. Mais il peut se retourner contre vous si vous tentez de migrer vers le monde froid et impitoyable du cloud public une application née et élevée dans le confort douillet d’un centre de données.
La plupart des applications d’entreprise n’ont pas été conçues en tenant compte des architectures et des méthodologies cloud. Elles conservent leur état localement, mettent du temps à devenir opérationnelles après le démarrage du serveur sous-jacent, et les arrêts soudains risquent d’entraîner des incohérences dans les données. Vous devez les traiter comme les animaux de compagnie choyés qu’elles sont, et non comme du bétail.
Les applications d’entreprise migrées vers des environnements cloud nécessitent en grande partie les mêmes services de maintenance, de gestion et de mise à disposition des applications (sécurité, disponibilité et performances) que ceux dont elles bénéficient dans le centre de données. Même les services d’équilibrage de charge de base dont ces applications ont besoin seront plus complexes que ceux requis par une application conçue et développée nativement dans le cloud. Pour que votre application prospère dans le cloud, vous devez également y migrer l’infrastructure qui la prend en charge. Heureusement, la plupart des composants d’infrastructure sont désormais disponibles dans le cloud public de votre choix, et vous pouvez y réutiliser les connaissances, les compétences et même les politiques de votre organisation.
Règle n° 2 : déplacez l’application, pas le désordre
L’évolution de la plupart des systèmes informatiques d’entreprise suit une trajectoire qui rappelle le câblage d’une baie de brassage. Vous voyez de quoi il s’agit. Au départ, tout est impeccable, bien conçu et parfaitement réalisé. (Jetez un œil à reddit.com/r/cableporn pour découvrir des configurations vraiment inspirantes.) Mais au bout d’un an, les contraintes de temps et l’urgence ont conduit à prendre un raccourci ici, à utiliser la mauvaise couleur là (« le rouge, c’est pour la DMZ, bon sang ! »). En trois petites années, la baie s’est transformée en un nœud gordien de câbles Ethernet multicolores et non étiquetés, qu’il ne reste plus qu’à arracher pour tout reconfigurer.
La migration vers le cloud est l’occasion de vous débarrasser de ce panneau de brassage désordonné et de reprendre le contrôle de la sécurité et de la gestion des accès. Même si vous devrez déplacer certains de vos services d’infrastructure en même temps que l’application, profitez-en pour rationaliser, visualiser et structurer votre stratégie d’accès aux applications et au réseau.
Règle n° 3 : gardez le contrôle de votre identité
La mesure de contrôle la plus importante que vous puissiez mettre en place est probablement la gestion de l’identité des utilisateurs dans vos environnements cloud. À mesure que vous migrez certaines applications vers le cloud, que vous en abandonnez certaines au profit d’offres de logiciels en tant que service (SaaS) ou que vous en réécrivez entièrement d’autres, vous devrez prendre plusieurs décisions clés concernant la gestion de l’identité des utilisateurs.
L’exploitation de plusieurs services d’identité peut s’avérer contraignante, risquée et inefficace, et réintroduire une partie de la complexité que vous cherchez justement à éliminer. La gestion des identités doit être centralisée, tandis que l’accès doit être fédéré dans tous les environnements requis. Une technologie qui s’intègre à votre service d’identité (généralement Microsoft Active Directory) et l’étend aux services cloud et SaaS à l’aide de protocoles tels que SAML et OAuth permet aux applications d’authentifier les utilisateurs à partir d’une source unique, plutôt que de s’appuyer sur des identités locales.
Mais tout comme les applications se sont dispersées, les utilisateurs aussi. L’ajout de contrôles permettant d’identifier la localisation et les appareils d’un utilisateur, associés à des options d’authentification à deux facteurs et de mots de passe à usage unique, peut offrir une protection contre l’ingénierie sociale et les tentatives similaires visant à compromettre la sécurité des informations de votre organisation.
Règle n° 4 : surveiller pour guérir l’« anxiété liée au cloud »
Les environnements cloud font abstraction de plusieurs couches d’infrastructure dont vous n’avez plus à vous préoccuper directement. C’est une bonne chose, car vous n’avez désormais plus besoin d’assurer la maintenance et le support d’une infrastructure physique. Toutefois, cette externalisation des responsabilités implique également de renoncer à une partie du contrôle direct.
Pour y remédier, vous devrez notamment surveiller plus attentivement les performances des applications. La mise en place d’une meilleure supervision, fournissant des informations pertinentes et exploitables, peut faciliter le dépannage et la planification des capacités.
Un autre avantage peut être de dissiper certaines inquiétudes au sein de l’entreprise. Les questions relatives à la sécurité et aux performances dans le cloud découlent en partie du caractère mutualisé et de la connexion à Internet du cloud public, mais aussi d’un sentiment de perte de contrôle. La mise en place d’une meilleure surveillance des applications et des comportements au sein de l’entreprise peut grandement contribuer à favoriser cette migration et à lever les freins psychologiques à l’adoption du cloud.
Règle n° 5 : restez concentré sur les stratégies de reprise après sinistre et de continuité d’activité
La reprise après sinistre et la continuité d’activité (DR/BC) sont des piliers d’une infrastructure de centre de données et d’une conception d’applications de qualité. L’utilisation d’un cloud public ne vous décharge pas de votre responsabilité de garantir le fonctionnement et la sécurité des applications. Elle facilite toutefois l’accès aux services de DR/BC.
Avant l’apparition des services de cloud public, la création d’un site physique de reprise après sinistre pouvait entraîner des coûts et des délais considérables. Désormais, il est possible d’accéder en quelques minutes à une infrastructure située sur un autre continent, fournie par un prestataire distinct et reposant sur une technologie sous-jacente différente. Toutefois, même si l’infrastructure est beaucoup plus facilement accessible, la création d’une application à haute disponibilité nécessite toujours une planification et une configuration approfondies.
Bien qu’il existe une documentation abondante consacrée à la reprise après sinistre et aux infrastructures cloud, un cadre efficace de planification et de conception de la reprise après sinistre et de la continuité d’activité (DR/BC) peut se résumer à quelques décisions et préoccupations essentielles.
Tout d’abord, vous devrez réfléchir aux risques et au retour sur investissement (ROI). La mise en place d’une solution multirégion et multifournisseur optimale justifiera-t-elle le temps et les dépenses nécessaires ? Si les services cloud peuvent réduire les coûts d’acquisition, les coûts opérationnels liés au maintien de services robustes de reprise après sinistre et de continuité d’activité resteront bien présents.
Deuxièmement, vous devez réfléchir à la manière dont vous allez stocker et distribuer les données transactionnelles tout en garantissant leur cohérence. Il s’agit d’un problème bien connu, mais c’est peut-être l’aspect le plus difficile de la conception d’applications géographiquement distribuées et hautement disponibles. De nombreuses solutions nécessitent des connexions à haut débit et à faible latence entre les différents sites, ou des architectures plus complexes, telles qu’un modèle de cohérence à terme, que les applications d’entreprise adoptent rarement. La mise en place d’une connectivité à faible latence entre différents fournisseurs de services cloud est hors de portée de la plupart des entreprises, mais certaines options commencent à voir le jour.
Le troisième défi majeur consiste à gérer l’accès à vos applications. Pour la plupart des architectures actif-actif ou actif-reprise après sinistre, l’utilisation du DNS pour diriger le trafic vers le centre de données optimal en fonction de sa disponibilité, de sa proximité ou de ses performances offre le meilleur compromis entre simplicité et fonctionnalités. Cela est particulièrement vrai si vous envisagez un modèle multicloud dans lequel vous faites appel à différents fournisseurs de services cloud pour vos applications. L’utilisation de protocoles réseau tels que BGP peut également être une option, mais elle accroît généralement la complexité et comporte certains risques. Une autre possibilité consiste simplement à répartir la charge ou à rediriger le trafic réseau entre les différents clouds à l’aide d’équipements ou de services installés hors du cloud, mais à proximité de celui-ci — ce qui nous amène à notre dernière règle.
Règle n° 6 : rapprochez-vous du cloud
La plupart des moyennes et grandes entreprises qui migrent leurs applications métier vers le cloud souhaiteront intégrer un accès privé sécurisé à leur infrastructure cloud. Si l’utilisation d’une solution VPN sur l’Internet public peut convenir à certaines, de nombreuses entreprises opteront pour une connexion dédiée plus directe au fournisseur de services cloud. Ces liaisons dédiées, fournies par des prestataires de services, offrent confidentialité, bande passante garantie et latence plus faible que les connexions Internet publiques, mais elles ont un coût.
Et si vous avez besoin de connexions résilientes à plusieurs clouds, vous devrez mettre en place plusieurs liaisons. Et si vous devez connecter votre cloud à certains composants d’infrastructure, mais que vos centres de données existants sont géographiquement ou logiquement trop éloignés des points d’interconnexion du réseau cloud ?
De plus en plus, les entreprises envisagent d’héberger leurs équipements dans des environnements connectés au cloud (communément appelés « cloud exchanges ») offrant des connexions haut débit à plusieurs fournisseurs de cloud. Vous pouvez ainsi placer certains de vos actifs informatiques au plus près de votre infrastructure virtuelle dans le cloud et bénéficier de connexions privées à faible latence entre les applications exécutées dans le cloud et les composants d’infrastructure, tels que les systèmes de stockage ou les appliances de sécurité hébergés dans le centre de colocation. Cette configuration vous permet également de tirer parti de vos équipements informatiques existants et d’étendre vos contrôles réseau et de sécurité à l’infrastructure cloud.
Enfin, la colocalisation dans un point d’échange cloud vous permet de mettre en place des contrôles à l’intersection de votre centre de données d’entreprise, de vos infrastructures cloud et de l’Internet public. Vous pouvez étendre ou créer les politiques de sécurité dont votre entreprise a besoin, et bénéficier d’un contrôle et d’une visibilité accrus sur les flux de données applicatives, améliorant ainsi votre posture de sécurité globale et vous aidant à rationaliser et à standardiser les services d’accès et de sécurité.
Conclusion
La migration à l’identique des applications d’entreprise vers un cloud public peut permettre aux organisations de réaliser des économies, de gagner en flexibilité et d’adopter rapidement un environnement cloud. Il est toutefois essentiel, pour réussir cette migration, de reconnaître que les applications d’entreprise ont toujours besoin d’une infrastructure sous-jacente.
Veiller à ce que les services dont dépendent vos applications en matière de sécurité, de performances et de disponibilité soient présents dans le cloud permettra à vos applications d’entreprise traditionnelles de continuer à fonctionner et donnera satisfaction à vos utilisateurs. L’intégration d’outils de supervision vous permettra de détecter rapidement les problèmes et contribuera à atténuer les inquiétudes que les responsables d’applications peuvent ressentir lors de la migration de leurs services vers le cloud.
L’opération de « lift and shift » peut également servir de catalyseur pour rétablir des contrôles robustes, rationaliser les accès et améliorer la continuité d’activité, augmentant ainsi le retour sur investissement global de la migration. Enfin, si vous utilisez plusieurs clouds publics, envisagez les avantages d’une colocalisation au sein d’un point d’échange cloud, qui peut améliorer les performances et vous permettre de standardiser les politiques de sécurité et d’accès à partir d’un point de contrôle unique.
1 Knapp, Kristin, « Les moyens d’atteindre l’objectif », Modern Infrastructure, juillet/août 2015, http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf
PUBLIÉ LE 29 NOVEMBRE 2016