Vous migrez des applications vers le cloud ? Lisez ceci en premier.

Les environnements de cloud computing constituent désormais une caractéristique dominante du paysage informatique, les organisations déplaçant applications locales héritées vers le cloud avec une régularité toujours croissante. Mais migrer une application vers le cloud nécessite bien plus que de simplement déplacer l’ application vers une machine virtuelle chez un fournisseur de cloud. Les motivations des différentes organisations pour la migration vers le cloud sont diverses, mais chaque organisation doit prendre en compte certains facteurs clés et adopter de bonnes pratiques pour garantir le succès de la migration vers le cloud. Pour tirer le meilleur parti de la migration vers le cloud, planifiez à l’avance, à la fois l’architecture de application et la transition des locaux vers le cloud.

Un environnement cloud se comporte différemment d’un environnement sur site. Certaines des différences entre les deux environnements sont évidentes, comme le fait que les ressources informatiques sont détenues et gérées par une autre entreprise, au lieu d’être détenues et gérées en interne. Toutefois, plusieurs des différences les plus importantes ne sont pas liées à la technologie. En général, toute technologie disponible auprès d’un fournisseur de cloud est également disponible sur site. Ce que propose le cloud, c’est un modèle de consommation alternatif, pas une technologie alternative. En d’autres termes, les avantages du passage à un fournisseur de cloud résident dans la manière dont les ressources de calcul sont consommées, et non dans les ressources de calcul elles-mêmes.

Les fournisseurs de cloud ne peuvent pas nécessairement dupliquer toutes les fonctionnalités sur site, telles que les politiques de conformité d’audit des données conçues pour le matériel sur site. Étant donné que les composants cloud sont dispersés géographiquement, la latence est généralement pire dans les déploiements cloud. Les fournisseurs de cloud sont également confrontés à d’autres limitations. Étant donné que les fournisseurs adhèrent à des normes pour tous les clients, il existe de réelles limites à la personnalisation des environnements informatiques. Par exemple, peu de fournisseurs de cloud proposeront des équipements informatiques rares et exotiques.

Mais si une entreprise peut fonctionner dans ces limites, un fournisseur de cloud peut offrir des capacités de consommation hors de portée de la plupart des entreprises. Un fournisseur de cloud peut exploiter des centres de données dans le monde entier, offrant aux organisations le choix du centre de données dans lequel localiser les ressources de calcul. Un fournisseur de cloud peut également absorber les coûts fixes, permettant à une entreprise de payer uniquement pour les ressources réellement utilisées. Étant donné qu’un fournisseur de cloud bénéficie d’économies d’échelle inégalées par la plupart des entreprises, il peut investir massivement dans des systèmes permettant de gérer et d’automatiser les déploiements. Notez qu’aucun de ces avantages n’est de nature technique ; les avantages d’un fournisseur de cloud résident plutôt dans les choix et la structure de coûts disponibles pour le consommateur.

Afin d'atténuer les limites et de tirer parti des avantages d'un fournisseur de cloud, un service informatique doit modifier la manière dont il déploie les applications, en modifiant les flux de travail pour tirer le meilleur parti des atouts relatifs d'un fournisseur de cloud, tout en évitant les dépendances sur des attributs où un environnement cloud est désavantagé, comme la latence.

Les économies de coûts sont souvent mentionnées comme l’un des principaux moteurs du passage au cloud, mais les véritables raisons ont tendance à être plus nuancées. La plupart des motivations se répartissent en trois catégories : la certitude, la productivité et l’agilité.

Les fournisseurs de cloud public augmentent la certitude en regroupant la technologie pour la rendre plus consommable et, ce faisant, en absorbant une partie du risque opérationnel informatique. Étant donné que les fournisseurs entretiennent et assument la responsabilité de l’infrastructure, une organisation peut ignorer ces préoccupations. De même, les fournisseurs de cloud mettent généralement à disposition des outils permettant d’obtenir un aperçu des opérations informatiques, augmentant ainsi la visibilité. Étant donné que les coûts du cloud public sont généralement fonction de la consommation, une organisation peut lier plus étroitement les avantages d’une application (tels que les revenus) aux coûts opérationnels de cette application. Au fur et à mesure que l’ application est utilisée, les coûts augmentent, mais les avantages aussi. En déplaçant les dépenses d’investissement vers les dépenses opérationnelles, il devient moins nécessaire de prévoir une marge de croissance future dans les décisions d’achat. La gestion de ces incertitudes au niveau du fournisseur de cloud offre des avantages mesurables.

Une autre raison d’adopter le cloud public est l’augmentation de la productivité. Les outils de collaboration et d’automatisation des fournisseurs sont parmi les plus avancés disponibles sur le marché. De plus, le fait de ne pas avoir à gérer l’infrastructure permet au personnel informatique de se concentrer sur les efforts stratégiques de l’entreprise, tandis que les opérations rationalisées qui peuvent être gérées de n’importe où augmentent la productivité du personnel informatique.

La dernière raison d’adopter le cloud public est peut-être la plus convaincante : l’agilité. Étant donné que le fournisseur de cloud crée l’illusion de ressources infinies disponibles à tout moment, la vitesse et la direction des efforts commerciaux ne sont plus liées aux contraintes de provisionnement informatique. Les ressources peuvent être déployées en quelques secondes ou minutes. Un projet peut consommer un environnement informatique complexe pendant une courte période sans se soucier de la mise hors service du matériel lorsque le projet prend fin. Les applications peuvent être déployées, mises à l’échelle et supprimées rapidement sans se soucier des ressources matérielles.

Bien qu’une migration vers le cloud présente de nombreux avantages, un effort de migration comporte également plusieurs défis. Les obstacles et les risques varient en fonction du moment où ils surviennent dans le processus de migration : avant la migration, pendant la migration et après la migration. S’attaquer à ces obstacles et à ces risques en amont augmente les chances de réussite de l’effort de migration.

La planification avant la migration est peut-être la partie la plus critique du processus de migration. Les efforts de migration peuvent échouer en raison d’un manque de réarchitecture de l’ application pour tirer parti des capacités du cloud. C’est également le moment de faire le point sur la complexité de l’application et de commencer à la gérer. La formation informatique doit également avoir lieu dès le début de l’effort. Les déploiements dans le cloud ont tendance à se traduire par une exécution cloisonnée et une prolifération des outils, et la planification dès les premières phases peut contribuer à faciliter le processus de migration.

La migration des applications vers le cloud a tendance à prendre plus de temps et à être plus complexe que prévu initialement. Pour aider à minimiser les problèmes, commencez par une application petite et relativement indépendante afin que les problèmes rencontrés aient un impact minimal. Les leçons tirées de la première migration d’une petite application peuvent être appliquées aux migrations futures.

Les problèmes à long terme liés aux migrations deviennent apparents une fois la migration terminée. Des problèmes de sécurité et de conformité peuvent survenir, souvent en raison du fait 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 difficile lorsque les anciens et les nouveaux systèmes se trouvent non seulement dans des environnements différents, mais sont également développés avec des cultures différentes. Certaines organisations s’inquiètent du verrouillage du cloud, notamment avec l’essor des conteneurs. Enfin, les problèmes budgétaires peuvent être un problème, car les coûts variables du cloud peuvent être difficiles à prévoir chaque trimestre.

Une technique d’évaluation des applications est la matrice maturité/localisation. Examinez vos applications pour déterminer le niveau de maturité dont vous avez besoin. Les applications qui offrent une différenciation concurrentielle ou qui sont de niche peuvent être mieux servies sur site. À l’autre extrémité du spectre, les applications à faible coût ou leaders en matière de coûts (notamment en termes de coût de changement) s’intègrent souvent bien dans un environnement cloud. D’autres facteurs à prendre en compte incluent l’évolutivité. Supposons qu’une nouvelle application ait été déployée et qu’elle puisse éventuellement évoluer jusqu’à 100 fois la charge actuelle. Pour rester en avance sur la croissance du déploiement sur site, l’infrastructure devrait être considérablement surprovisionnée, ce qui entraînerait des coûts d’investissement supplémentaires pour les ressources inactives. Cependant, si cette même application était déployée dans un environnement cloud, les coûts augmenteraient avec la croissance et il ne serait pas nécessaire de procéder à un surprovisionnement.

Les problèmes de réseau peuvent également jouer un rôle dans la décision concernant les applications à migrer vers un environnement cloud. Si une application comporte une grande proportion d’utilisateurs distribués, comme un réseau de revendeurs étendu, ou un nombre important d’utilisateurs de messagerie distants, un déploiement sur site canalise tout ce trafic vers le centre de données. Étant donné que le trafic traverse déjà Internet, les applications ne sont pas sensibles à la latence. Lorsque des applications telles que celles-ci sont placées dans un environnement cloud, la latence du réseau ne change pas, mais elle libère de la bande passante dans les centres de données sur site qui serait autrement consommée par les utilisateurs distribués.

Dans le même temps, il existe des raisons de conserver certaines applications sur site. Les applications ayant une espérance de vie plus courte pourraient ne pas valoir les risques et les coûts d’un effort de migration. Certaines applications dépendent d'une faible latence du réseau et de vitesses de stockage, et pourraient avoir des performances bien inférieures dans un environnement cloud. Les problèmes de conformité et de sécurité sont souvent des raisons pour lesquelles les applications sont conservées sur site. Certaines procédures d'audit supposent un accès physique aux systèmes et aux données afin de vérifier les données, tandis que d'autres exigent que l' application et le système d'exploitation fonctionnent sur du matériel nu (c'est-à-dire qu'ils ne peuvent pas être exécutés sur une machine virtuelle). Au fil du temps, les procédures de conformité s’adapteront à l’environnement cloud, mais dans de nombreux cas, cela n’est pas encore arrivé. Au lieu d’assumer le risque d’échouer aux audits de conformité avec des applications dans le cloud, il pourrait être plus judicieux de conserver ces applications sensibles sur site pour le moment. Certaines applications doivent prendre en charge des systèmes et des processus existants et ne peuvent donc pas être réarchitectées pour fonctionner dans un cloud. Ces applications pourraient également être candidates à une installation sur site. Pour ces raisons, certaines applications devraient avoir une priorité de migration inférieure à celle des applications mieux adaptées à un environnement cloud.

Il est préférable de laisser les applications sur site

• Applications avec une courte durée de vie
• Applications nécessitant une faible latence
• Applications pour lesquelles il existe des problèmes de conformité
• Applications prenant en charge les systèmes hérités

De nombreuses organisations doivent surmonter des défis lors du processus de migration. Une question majeure à laquelle il faudra répondre est de savoir comment réaliser la transition proprement dite ? Une approche consiste à utiliser le DNS pour résoudre l’ application sur site jusqu’à ce que l’ application cloud ait été entièrement testée, puis à modifier les enregistrements DNS pour résoudre 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 un TTL faible, peut-être quelques secondes seulement, afin qu'après la transition, les clients puissent rapidement s'adapter aux nouvelles applications. Cette approche comporte toutefois certains risques. La réduction du TTL peut augmenter considérablement le trafic DNS ainsi que la charge sur les serveurs. Une organisation pourrait ignorer le TTL et le cache pendant des périodes plus longues que celles spécifiées, obligeant certains utilisateurs à se résoudre à utiliser l' application sur site longtemps après la mise en œuvre du basculement. Pensez à tester la robustesse de votre infrastructure DNS avant d’utiliser cette approche.

Le processus de transition peut également révéler des problèmes avec la nouvelle application qui n’ont pas été détectés lors des tests. Un moyen de se protéger contre une application problématique est un plan de secours qui permet au traitement 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 utilise une transition partielle appelée test canari, qui fait passer une partie des utilisateurs vers l’ application cloud pendant qu’elle est surveillée. À mesure que la confiance dans l’ application augmente, davantage d’utilisateurs, et finalement tous, peuvent être transférés. À l’inverse, si un problème survient, les utilisateurs transférés peuvent revenir à l’utilisation de l’ application sur site. Les tests Canary peuvent être effectués par un contrôleur de distribution application (ADC) programmable via F5® iRules®, minimisant ainsi les risques tout en augmentant le nombre d'options ouvertes à l'équipe d'exploitation pendant la période de transition.

L’une des plus grandes erreurs commises par les organisations lors de la migration applications est de ne pas les réorganiser pour le cloud. Consacrer du temps à modifier la structure de l’ application afin qu’elle tire parti des différences d’un environnement cloud peut apporter des avantages significatifs.

Par exemple, la mise à l’échelle dans un environnement cloud est triviale par rapport à la mise à l’échelle sur site. Au lieu de concevoir l' application et de la tester pour la charge du pire des cas, concevez plutôt l' application pour qu'elle soit légère mais évolutive. Il n’est pas nécessaire de maintenir une surcharge pour une empreinte importante lorsque l’utilisation de application couvre un large spectre. Construisez plutôt petit et soyez prêt à évoluer. De même, certaines pannes, comme les pannes de courant, sont moins probables dans un environnement cloud, il est donc moins nécessaire de les concevoir.

D’autre part, les environnements cloud introduisent de nouvelles limitations qui ne sont pas régulièrement rencontrées sur site. Les architectes cloud notent qu’une conception doit prévoir la défaillance de n’importe quelle instance de machine virtuelle à tout moment dans le cadre du traitement régulier. Le stockage est également différent dans un environnement cloud. Les conceptions sur site utilisent régulièrement le stockage en blocs local. 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 d’une défaillance d’instance pourrait être une recette pour un désastre. D’autres paradigmes de stockage existent, tels que le stockage basé sur des objets ou les services de stockage clé-valeur. La protection contre les limitations d'un environnement cloud peut être réalisée en réarchitectant l' application.

Certaines applications ou systèmes de contrôle peuvent être conservés sur site. De nombreuses organisations conserveront Active Directory sur site tout en utilisant la fédération pour étendre l’identité dans un environnement cloud. De même, un ADC fournit de nombreux services de sécurité pour prendre en charge la distribution application , tels que les pare-feu, les pare-feu application Web, la protection DDoS et l’interception SSL/TLS ainsi que le chaînage de services. Un ADC fournit également une gestion avancée du trafic et un proxy programmable, ainsi qu'une gestion des accès.

Les organisations ont généralement consolidé ces services application en externe à l’ application , car les services ne font pas partie de la logique métier, mais sont plutôt des préoccupations opérationnelles. Pour permettre des changements opérationnels indépendants des calendriers de publication des application , de nombreuses entreprises concentrent l'expertise du domaine qui peut être appliquée à toutes les applications en utilisant un ADC comme point de contrôle stratégique. Cependant, les environnements cloud modifient ce modèle.

Une première approche de la distribution application dans les environnements cloud consistait à répliquer les services ADC à l’aide d’outils natifs dans chaque environnement cloud. Il est rapidement devenu évident que les fournisseurs de cloud n'offraient pas le même niveau de capacités natives, ce qui laissait aux organisations le choix : soit maintenir des normes de distribution application hétérogènes entre les environnements cloud et sur site, soit reconcevoir toutes les applications au plus petit dénominateur commun.

À mesure que les entreprises se sont développées dans plusieurs environnements cloud, les deux options sont devenues moins intéressantes. Supposons qu’une organisation s’appuie sur trois fournisseurs de cloud et gère également un centre de données sur site. L'organisation devait soit maintenir quatre ensembles d'expertise SSL/TLS, quatre ensembles d'expertise DDoS, etc., soit se standardiser sur un ensemble de services de base de plus en plus décousu (et limité). Le déploiement d’une seule nouvelle application dans un environnement cloud supplémentaire impliquait un coût marginal important, soit lié à un autre ensemble d’experts du domaine, soit à un nouvel ensemble de 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 à un ensemble d'experts du domaine de gérer toutes les applications, quel que soit l'endroit où ces applications se trouvent. En utilisant les appareils matériels ou logiciels BIG-IP® existants, une organisation peut injecter des services application avancés complets devant n'importe quelle application , où qu'elle se trouve, offrant ainsi à toutes les applications un point de contrôle stratégique, géré par un seul ensemble d'experts du domaine. De plus, Application Connector renforce la sécurité en éliminant toutes les adresses IP publiques visibles, réduisant ainsi les surfaces d’attaque. En conservant les clés de chiffrement stockées de manière centralisée et non dans les instances cloud, les organisations peuvent être sûres que leurs informations cryptographiques critiques restent privées. Enfin, Application Connector augmente l’efficacité de votre déploiement cloud en permettant à l’instance proxy de détecter automatiquement de nouveaux nœuds de charge de travail.

L’une des plus grandes différences entre les applications sur site et les applications cloud est le stockage de l’état de application . Dans leur grande majorité, les conceptions sur site utilisent un stockage de blocs local, tel qu'un disque dur ou un disque SSD. Une application cloud peut également utiliser le stockage en bloc, mais le stockage est local à l'instance et les conceptions doivent s'attendre à ce que les instances échouent. Si les organisations ne réorganisent rien d’autre dans la conception des application lors du déplacement d’une application vers le cloud, elles doivent modifier la manière dont l’état est géré.

Un type de stockage cloud courant est le stockage d'objets, où chaque objet est essentiellement un fichier mais adressé à l'aide d'un nom. En général, le stockage n'a qu'un seul niveau de hiérarchie (c'est-à-dire un dossier ou un répertoire), donc le mappage d'un système de fichiers traditionnel à des objets peut être problématique. Étant donné que les objets ne peuvent pas être modifiés (uniquement créés, lus et supprimés), le stockage d’objets est un bon choix pour le contenu statique, tel que les images, mais pas pour l’état. De nombreuses applications supposent qu'un fichier peut être modifié, applications ne fonctionneront donc pas avec des objets.

D’autres choix de stockage incluent les magasins clés-valeurs et les bases de données transactionnelles traditionnelles. Il ne s'agit pas d'un stockage comme un système de fichiers, mais ils stockent des données et sont fournis en tant que service supplémentaire. Avec une conception efficace, l'état peut être stocké dans un service clé-valeur ou de base de données.

Les environnements de cloud computing offrent des avantages, mais seulement si les applications clés sont réarchitecturées pour tirer parti des fonctionnalités du cloud tout en atténuant l’impact des limitations du cloud. Les environnements cloud présentent différents scénarios de défaillance et présentent souvent une latence réseau accrue, mais permettent une mise à l'échelle rapide et un choix de centres de données dans le monde entier. Les considérations relatives à la migration vers le cloud incluent la détermination des applications à migrer et de celles à conserver sur site.

Une réflexion et une planification minutieuses doivent également être prises en compte dans le processus de transition lui-même, ainsi qu’un plan de secours au cas où l’ application cloud ne se comporterait pas comme prévu. Dans le cadre du processus de planification, certaines organisations conservent un ADC sur site comme point de contrôle stratégique pour toutes les applications , quel que soit l'endroit où elles sont hébergées. Enfin, planifiez soigneusement la manière dont l’ application cloud stockera les données et l’état. Quelle que soit la manière dont vous choisissez de déplacer vos applications(et votre entreprise) vers le cloud, pensez à faire appel à un partenaire cloud expérimenté.