Les organisations envisageant de déplacer des applications d’entreprise vers le cloud public doivent s’assurer qu’elles déplacent également les services de distribution application sur lesquels leurs applications s’appuient dans le centre de données. En outre, la migration vers le cloud offre l’opportunité d’organiser et de rationaliser la sécurité et l’accès, d’obtenir une visibilité sur le trafic des application basées sur le cloud et d’élaborer un plan de reprise après sinistre solide.

Pour de nombreuses organisations, déplacer des applications d’entreprise vers le cloud public peut être une proposition très intéressante. Cela leur permet de se débarrasser des coûts fixes et des actifs liés à l’exploitation d’une infrastructure informatique à grande échelle, y compris des centres de données coûteux dotés d’équipements de différentes générations et de différents niveaux de support. Bien que ces serveurs fassent fonctionner l’entreprise, ils consomment également de l’énergie, produisent de la chaleur et nécessitent des contrats de support coûteux. 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 nuire à la mission globale des organisations informatiques : fournir les applications qui font fonctionner l’entreprise.

Se débarrasser de ce casse-tête opérationnel et de cette perte financière en échange d'un nouveau monde où un ancien serveur ou une ancienne application peut être retiré avec un simple appel d'API est souvent logique sur le plan financier et opérationnel. Si vous n’avez plus besoin de gérer l’infrastructure de base qui exécute votre informatique, vous pouvez vous concentrer davantage sur la sécurité, les performances et la disponibilité des applications qui représentent la véritable valeur ajoutée de l’informatique à l’entreprise.

Mais avant d’atteindre ce nirvana d’infrastructure virtualisée et sans maintenance, vous allez devoir déterminer la meilleure façon de déplacer vos applications vers leur nouveau domicile. La migration d’une application vers le cloud public implique certains choix. Vous pouvez entièrement réorganiser l' application pour un environnement cloud, ce qui peut se traduire par une expérience utilisateur élégante et rationalisée, mais peut souvent être un processus chronophage et exigeant en main-d'œuvre. Alternativement, vous pouvez simplement récupérer les applications exécutées dans votre centre de données et les déposer dans un cloud public sans apporter de modifications importantes à la conception ou à la plateforme.

Il existe un certain nombre de bonnes raisons d’explorer ce modèle « lift and shift » : On estime que cela coûte environ 10 fois moins cher,¹ c'est presque toujours beaucoup plus rapide, et dans certains cas, cela ne vaut tout simplement pas la peine de réécrire une application avec une durée de vie limitée. Mais si vous souhaitez réussir votre migration « lift and shift », il y a quelques règles à suivre, et une que vous devrez enfreindre.

Nous allons commencer par celui à casser. Le concept consistant à traiter les serveurs comme du bétail est souvent considéré comme intrinsèque aux architectures cloud. Si une instance de serveur fonctionne de manière incorrecte, ne perdez pas de temps à la réparer : arrêtez-la simplement et redéployez-la. Ne mettez pas à niveau les systèmes d’exploitation ou les logiciels ; déployez simplement de nouvelles instances et terminez les anciennes. C'est un conseil solide. Mais cela peut se retourner contre vous si vous essayez de déplacer une application qui est née et a grandi dans le luxe douillet du centre de données vers le monde froid et dur du cloud public.

La plupart des applications d’entreprise n’ont pas été conçues en tenant compte des architectures et des méthodologies cloud. Ils conservent l'état localement, ils prennent du temps à être en ligne après le démarrage du serveur sous-jacent et les arrêts soudains entraîneront probablement des données incohérentes. Vous devez les traiter comme des animaux de compagnie choyés, et non comme du bétail.

Les applications d’entreprise transférées dans des environnements cloud nécessitent une grande partie des mêmes services de soins, de gestion et de distribution application (sécurité, disponibilité et performances) que ceux qu’elles reçoivent 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 nécessaires à une application conçue et née dans le cloud. Si vous souhaitez que votre application prospère dans le cloud, vous devez déplacer son infrastructure de support avec elle. Heureusement, la plupart des composants d’infrastructure sont désormais disponibles dans le cloud public de votre choix, et vous pouvez réutiliser vos connaissances, vos compétences et même vos politiques organisationnelles dans le cloud.

L’évolution de la plupart des systèmes informatiques d’entreprise suit un chemin qui ressemble à celui d’un rack de câblage de panneau de brassage. Tu connais celui-là. Cela commence magnifiquement, bien conçu et parfaitement exécuté. (Jetez un œil à reddit.com/r/cableporn pour des configurations vraiment inspirantes.) Mais en l'espace d'un an, les nécessités du temps et l'urgence ont conduit à un raccourci ici, à l'utilisation de la mauvaise couleur là (« le rouge, c'est pour la DMZ, bon sang ! »). En trois ans à peine, l’armoire s’est transformée en un nœud gordien de câbles Ethernet multicolores et non étiquetés qui n’ont besoin que d’être arrachés et reconfigurés.

Passer au cloud est votre chance de vous débarrasser de ce panneau de brassage encombré 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 avec l’ application, vous devez profiter de cette opportunité pour rationaliser, visualiser et organiser votre stratégie d’accès aux application et au réseau.

Le contrôle le plus important que vous puissiez mettre en place est probablement la gestion de l’identité des utilisateurs dans vos environnements cloud. Lorsque vous déplacez certaines applications vers le cloud, supprimez certaines applications au profit d'offres SaaS (Software as a Service) ou réécrivez complètement certaines applications , vous devrez prendre plusieurs décisions clés concernant la gestion des identités des utilisateurs.

L’exécution de plusieurs services d’identité peut être fastidieuse, risquée et inefficace, et peut entraîner une certaine complexité que vous devriez essayer d’éliminer. La gestion des identités doit être centralisée, mais l’accès doit être fédéré dans tous les emplacements requis. La 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 avec une source unique, plutôt que de s'appuyer sur l'identité locale.

Mais tout comme les applications sont devenues plus dispersées, les utilisateurs le sont aussi. L'ajout de contrôles qui identifient l'emplacement et les appareils d'un utilisateur, combiné à des options d'authentification à deux facteurs et de mots de passe à usage unique, peut fournir une défense contre l'ingénierie sociale et les tentatives similaires visant à compromettre la sécurité des informations de votre organisation.

Les environnements cloud soustraient plusieurs couches d’infrastructure à votre préoccupation directe. C’est une bonne chose, car vous n’avez désormais plus besoin d’entretenir et de soutenir une infrastructure physique. Toutefois, cette externalisation de responsabilité s’accompagne également d’une cession de contrôle direct.

L’une des choses que vous devrez faire pour contrer ce problème est de surveiller plus attentivement les performances des application . L’ajout d’une meilleure surveillance fournissant des informations pertinentes et exploitables peut faciliter le dépannage et la planification des capacités.

Un autre avantage peut être la suppression de certaines préoccupations au sein de l’entreprise. Les questions relatives à la sécurité et aux performances dans le cloud proviennent en partie des aspects multi-locataires et connectés au public du cloud public, mais elles découlent également de la perte de contrôle perçue. L’ajout d’une meilleure surveillance des applications et du comportement de l’entreprise peut contribuer de manière significative à promouvoir cette migration et à supprimer les barrières émotionnelles à l’adoption du cloud.

La reprise après sinistre et la continuité des activités (DR/BC) sont les piliers d’une bonne infrastructure de centre de données et d’une bonne conception des application . L’utilisation d’un cloud public ne vous dispense pas de votre responsabilité de maintenir les applications opérationnelles et sécurisées. Cependant, cela réduit la barrière à l’entrée pour les services DR/BC.

Avant la disponibilité des services de cloud public, la création d’un emplacement physique de reprise après sinistre pouvait impliquer des coûts et des délais importants. Désormais, vous pouvez accéder à l’infrastructure d’un autre continent auprès d’un fournisseur distinct utilisant une technologie sous-jacente différente en quelques minutes. Mais même si l’infrastructure est peut-être beaucoup plus facilement disponible, la création d’une application hautement disponible nécessite toujours une planification et une configuration importantes.

Bien qu'il existe une documentation complète consacrée au sujet de la reprise après sinistre et des infrastructures cloud, un bon cadre de planification et de conception pour la reprise après sinistre et la continuité des activités peut être réduit à quelques décisions et préoccupations clés.

Tout d’abord, vous devez réfléchir au risque et au retour sur investissement (ROI). Opter pour la solution multirégionale et multifournisseur ultime vaut-il la peine d’y consacrer du temps et de l’argent ? Même si les services cloud peuvent réduire le coût d’acquisition, les coûts opérationnels liés au maintien de services DR/BC robustes seront toujours là.

Deuxièmement, vous devez réfléchir à la manière dont vous allez stocker et distribuer les données transactionnelles et assurer leur cohérence. Il s’agit d’un problème bien connu, mais c’est peut-être la partie la plus difficile de la création applications géographiquement dispersées et hautement disponibles. De nombreuses solutions nécessitent des connexions à bande passante élevée et à faible latence entre les emplacements, ou des conceptions plus ésotériques telles qu'un modèle de cohérence éventuel que les applications d'entreprise adoptent rarement. La création d’une connectivité à faible latence entre différents fournisseurs de cloud n’est pas à la portée de la plupart des entreprises, mais certaines options deviennent disponibles.

Le troisième défi clé est la gestion de l’accès à vos applications. Pour la plupart des conceptions actives-actives ou actives-DR, l'utilisation du DNS pour diriger le trafic vers le centre de données optimal en fonction de la disponibilité, de la proximité ou des performances représente le meilleur équilibre entre simplicité et fonctionnalité. Cela est particulièrement vrai lorsque vous envisagez un modèle multi-cloud dans lequel vous utilisez différents fournisseurs de cloud pour vos applications. L’utilisation de protocoles réseau tels que BGP peut également être une option, mais cela ajoute généralement de la complexité et certains risques. Une autre option pourrait consister simplement à équilibrer la charge ou à commuter le trafic réseau entre les clouds à l’aide d’équipements ou de services placés à des emplacements extérieurs au cloud, mais proches de celui-ci, ce qui nous amène à notre règle finale.

La plupart des entreprises de taille moyenne à grande qui migrent des applications d’entreprise vers le cloud souhaiteront intégrer un accès privé sécurisé à leur infrastructure cloud. Bien que l’exécution d’une solution VPN sur Internet public puisse être appropriée pour certains, de nombreuses organisations utiliseront une connexion dédiée plus directe au fournisseur de cloud. Ces liens dédiés fournis par les fournisseurs de services offrent confidentialité, bande passante garantie et latence inférieure à celle des connexions Internet publiques, mais ils ont un prix.

Et si vous avez besoin de connexions résilientes à plusieurs clouds, vous devrez provisionner plusieurs liens. Et que se passe-t-il 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 de peering du réseau cloud ?

De plus en plus, les organisations envisagent de colocaliser leurs équipements dans des environnements connectés au cloud (communément appelés échanges cloud) qui offrent des connexions à haut débit à plusieurs fournisseurs de cloud. Cela vous permet d'héberger certains de vos actifs informatiques extrêmement près de votre infrastructure virtuelle cloud, ce qui vous offre des connexions privées à faible latence entre les applications exécutées dans le cloud et les composants d'infrastructure tels que les dispositifs de stockage ou de sécurité hébergés dans le centre de colocation. De plus, cette configuration vous permet d’exploiter l’équipement informatique existant et d’étendre les contrôles de réseau et de sécurité à l’infrastructure cloud.

Enfin, la colocalisation dans un échange cloud vous permet de placer des contrôles au niveau du nœud 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 obtenir un meilleur contrôle et une meilleure visibilité des flux de données des application , améliorant ainsi votre posture de sécurité globale et vous aidant à rationaliser et standardiser les services d'accès et de sécurité.

Le transfert et le déplacement des applications d’entreprise vers un cloud public peuvent permettre aux organisations d’économiser de l’argent, d’augmenter leur flexibilité et de migrer rapidement vers un environnement cloud. Reconnaître que les applications d’entreprise ont toujours besoin d’une infrastructure environnante est toutefois essentiel pour une migration réussie.

En garantissant que les services sur lesquels vos applications s'appuient pour la sécurité, les performances et la disponibilité sont présents dans le cloud, vos applications d'entreprise traditionnelles continueront de fonctionner et vos utilisateurs seront satisfaits. L’intégration d’une surveillance vous permettra de repérer rapidement les zones problématiques et d’atténuer l’anxiété que les propriétaires application peuvent ressentir lorsque leurs services migrent vers le cloud.

L’acte de levage et de déplacement peut également agir comme un catalyseur pour rétablir des contrôles robustes, rationaliser l’accès et améliorer la continuité des activités, ce qui augmentera le retour sur investissement global de la migration. Enfin, si vous exploitez plusieurs clouds publics, pensez aux avantages de la colocalisation dans un échange cloud, ce 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.

¹ Knapp, Kristin, « Les moyens pour parvenir à la fin », Modern Infrastructure, juillet/août 2015, http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf .