Liste de contrôle de migration AWS de référence pour les entreprises prêtes pour DevOps – Bien choisir son serveur d impression

Chaque migration d'application est différente, mais chaque processus suit les mêmes étapes de base. Utilisez cette liste de contrôle de migration AWS pour vous assurer que tout est prêt pour le lancement et au-delà.

Les nombreux services cloud d'Amazon englobent divers niveaux de stockage et tailles d'instances, environnements d'applications gérées, informatique sans serveur, etc. Les migrations AWS nécessitent les bons services pour s'adapter à la charge de travail. Ces services doivent également prendre en compte l'architecture, le contexte métier, les besoins en ressources et les risques de sécurité d'une application. L’adoption et l’optimisation du cloud sont également un bon moment pour la modernisation avec les processus DevOps et Agile.

La culture est une autre composante majeure du succès, a déclaré Matthias Buchner, architecte en chef des solutions DevOps chez Flux7, un fournisseur de services informatiques.

"Lorsque les entreprises se préparent à migrer, elles sous-estiment la courbe d'apprentissage", a déclaré Buchner. On nous a tous dit que le cloud serait facile, mais les développeurs, les opérations, la sécurité et les dirigeants d'entreprise ont tous beaucoup à apprendre.

Lorsque vous parcourez cette liste de contrôle de la migration AWS, notez les tâches qui seront difficiles ainsi que celles qui ne s'appliqueront pas à votre charge de travail donnée. Ces étapes sont basées sur l'expérience du monde réel et sont divisées en cinq sections: évaluation des applications, choix d'hébergement, déploiement de l'application, opérations informatiques, support des applications et, enfin, gestion de projet. Imprimez cette liste de contrôle avant de passer à AWS et cochez les cases à la fin de chaque étape de la migration.

1. Préparation de l'architecture d'application

Une bonne liste de contrôle de la migration AWS commence par une révision de l'application. L'équipe de migration doit décider si l'application est prête pour le cloud. En outre, il doit établir des contraintes commerciales et des estimations de coûts.

Énumérez les avantages et les inconvénients du transfert de cette application vers AWS. Quels sont les moteurs commerciaux et technologiques? Contactez tous les responsables appropriés impliqués dans les décisions de migration.

Évaluer l'état de préparation au cloud de l'application. Est-il conçu pour évoluer de manière flexible, avec des composants séparés, ou est-il monolithique? Aura-t-il besoin d'un refactoring avant la migration? L'ensemble de l'application sera-t-il disponible sur AWS ou uniquement sur certains composants, tels que l'interface frontale?

Indiquez les composants de l'application qui doivent rester en interne, le cas échéant.. Définir les moteurs technologiques et / ou métier pour la non-migration. Créez un plan pour migrer ces composants internes vers le cloud public à l'avenir, le cas échéant. Déterminez si AWS Outposts, l'offre d'infrastructure sur site gérée du fournisseur de cloud, convient à ces composants. Les avant-postes sont lancés à la fin de 2019 et ajoutent un autre niveau de prise de décision pour les migrations AWS.

Évaluer les bases de données d'application. Les bases de données migreront-elles vers Amazon Relational Database Service ou Amazon Aurora, ou l'organisation doit-elle transférer un déploiement Oracle ou Microsoft SQL Server sur EC2? Sinon, l'équipe de migration conservera-t-elle la ou les bases de données sur site et transférera-t-elle uniquement le traitement ou l'exécution de l'application vers AWS?

Données sécurisées. Planifiez la manière dont l'application entrera et sortira les données en toute sécurité vers ces points de terminaison du cloud, via Internet public ou via une fibre dédiée. Déterminez comment les données seront protégées au repos et en mouvement et vérifiez cette conception avec l'équipe de sécurité.

Mapper les intégrations et les dépendances des composants de l'application. Les équipes de migration doivent comprendre comment les flux de travail traversent les composants et où se trouvent les problèmes potentiels. AWS propose un service de découverte d'applications à exécuter sur un déploiement local, ou les entreprises peuvent s'appuyer sur des cartes de dépendance des applications et des outils de suivi des actifs déjà en place dans leurs centres de données.

Coûts estimés. Le cloud ne coûte pas forcément moins cher et les équipes doivent prendre en compte les coûts de transfert de données, de stockage, d'utilisation des calculs et de mise à l'échelle. AWS propose le calculateur mensuel simple pour divers services, tels que les instances EC2, Elastic Load Balancing, etc., avec des exemples de déploiement d'applications. Une organisation peut également recourir à des outils tiers de gestion des coûts.

Les entreprises peuvent être prises dans un seul chemin de migration d'application, par exemple en refacturant tout pour une utilisation optimale du cloud. Pour réussir véritablement, vous devez combiner cloud, Agile et DevOps, mais toute évolution technologique doit être évaluée en fonction des objectifs du projet, a déclaré Buchner. Si l'application est configurée pour prendre sa retraite dans deux ans, soulevez et passez au besoin. Mais si l’application représente un investissement pour l’entreprise, prenez le temps de l’optimiser.

2. Hébergement sur AWS

Une fois que l'équipe de migration comprend ses besoins en ressources et en opérations, elle peut déterminer comment ses applications doivent être hébergées dans le cloud. Utilisez cette section de la liste de contrôle de la migration AWS pour évaluer les choix d'hébergement AWS.

Définir une stratégie d'infrastructure. L'application nécessite-t-elle un Amazon VPC dédié ou doit-elle être déployée sur des instances multi-locataires? AWS recommande de configurer un compte AWS Landing Zone avec plusieurs utilisateurs pour activer la migration.

Configurer les types d'instances d'application. Ces instances doivent correspondre aux demandes de ressources et de mise à l'échelle de l'application. Les exemples incluent les machines virtuelles éclatées T3 à moindre coût, les instances M5 à usage général et d'autres types d'instances EC2 optimisés pour le calcul, le stockage ou autre. L'équipe de migration pourrait également passer à des choix AWS de niveau supérieur, tels que Elastic Beanstalk ou même AWS Lambda pour une exécution sans serveur.

Évolutivité intégrée. Les administrateurs peuvent configurer les applications pour qu'elles évoluent automatiquement avec AWS Auto Scaling, mais ils doivent être conscients des conséquences financières de toute consommation de ressources supplémentaire. Implémentez les limites via un ajustement manuel ou en fonction d'une stratégie de dimensionnement. Planifiez la mise à l'échelle des applications en conjonction avec un réseau de diffusion de contenu, tel que AWS CloudFront ou un autre outil tiers, tel que CloudFlare.

Configurer le stockage pour répondre aux demandes de données variées et aux exigences de redondance. AWS propose le stockage d'objets S3, Elastic Block Store et d'autres services de stockage, notamment S3 Glacier pour les archives. Implémentez la gestion du cycle de vie du stockage qui déplace les données entre les niveaux de stockage chaud et froid. Pour migrer une grande quantité de données vers AWS, considérez Snowball, un périphérique physique livré aux utilisateurs et transmettant les données de l'application à AWS.

Attribuer l'environnement d'hébergement en fonction des restrictions ou des exigences géographiques. Pour réduire le temps de latence, par exemple, l'application doit être déployée dans les régions AWS proches des principales bases clients. Ou, pour se conformer aux lois sur la résidence des données, le stockage doit être rattaché à une région.

M. Buchner a averti que les entreprises habituées à dimensionner les ressources matérielles sur site peuvent obtenir une précision excessive lors de la planification d'instances. C'est une ancienne façon de penser. "Dans le nuage, vous pouvez changer [resource allocation] en quelques minutes, faites donc la meilleure estimation, lancez-la et optimisez-la à partir de là ", a-t-il déclaré.

3. Déploiement d'applications

Lorsque la maintenance et la gestion des serveurs cèdent la place à des instances de cloud standardisées, les entreprises doivent passer aux opérations automatisées et à l'infrastructure en code (IaC). Faites en sorte que la migration vers le cloud en vaille la peine avec un toolkit de déploiement bien planifié et un processus combinant les méthodologies Agile et DevOps.

Migrer l'application et les composants associés sur AWS. Amazon propose toute une gamme de services natifs pour la migration, notamment le service de migration de base de données AWS, le service de migration de serveur AWS, CloudEndure Migration et VMware Cloud sur AWS.

Configurer un pipeline CI / CD. Ces pipelines déploient l'application et mettent à jour les ressources AWS. AWS propose CodeBuild et CodePipeline de manière native et prend en charge des pipelines indépendants, tels qu'une suite intégrée d'outils connectés par Jenkins.

Créer des modèles IaC pour la configuration de l'infrastructure d'application. Utilisez des modèles CloudFormation avec CloudFormer natifs ou des outils tiers tels que Terraform de HashiCorp. Celles-ci permettent un déploiement et une standardisation rapides.

Si vous continuez à développer Waterfall, ne laissez pas l'implémentation Agile et DevOps créer un obstacle à la migration vers le cloud. L’adoption de DevOps est plus difficile sur le terrain et est conçue différemment des pipelines en nuage, a déclaré Buchner. Par conséquent, au lieu d'apprendre deux fois DevOps, commencez par l'étape Cloud et utilisez-le pour propulser la croissance Agile et DevOps au sein de l'entreprise.

4. Opérations et support

Une migration réussie dans le cloud constitue le début, et non la fin, du cycle de vie d'une application. Le reste du cycle de vie – surveillance, détection des incidents, réponse et gestion des ressources – est l'endroit où l'équipe peut éviter les problèmes de performances et de sécurité et affiner les processus DevOps.

Mettre à jour la surveillance des performances de l'application. Terminez la boucle de rétroaction DevOps avec la surveillance des opérations dans le cloud. Établissez de nouvelles métriques de performances de base pour l'application, en particulier si les composants ont été restructurés pour les services cloud. Définissez de nouveaux seuils pour les alertes et analysez les outils de surveillance tiers par rapport à AWS CloudWatch.

Surveiller les ressources d'infrastructure en fonction du modèle à responsabilité partagée. La performance et la disponibilité de l'infrastructure physique sont désormais la responsabilité d'AWS., mais tout ce qui en plus revient à vos équipes des opérations informatiques. Ils doivent savoir quand l'application rencontre des problèmes, quand leurs instances sont mal configurées ou ont des goulots d'étranglement et quand les centres de données d'AWS sont à blâmer. Suivez les problèmes sur la page AWS Service Health Dashboard.

Établir des mesures de sécurité préventives. Le périmètre de sécurité change lorsqu'une application est déplacée vers le cloud public. Quels pare-feu sont en place? Les pare-feu virtuels pourraient-ils contrôler efficacement le trafic d'instance? Prenez le temps de lire des informations sur les violations majeures de la sécurité informatique et sur les moyens d'éviter le même sort.

Activer la surveillance et le renforcement de la sécurité. Utilisez des tests de pénétration, des analyses de vulnérabilité et d’autres efforts de détection. Les entreprises ayant plusieurs comptes AWS doivent examiner les options de gouvernance, telles que AWS Control Tower.

Configurer l'agrégation de journaux et les archives. Les organisations utilisant des applications de cloud hybrides trouvent la gestion centralisée des journaux difficile en raison des sources disparates d'informations de journalisation. Ils peuvent avoir besoin d’outils distincts pour regrouper les journaux d’AWS et de la configuration sur site.

Documenter et pratiquer les procédures d'intervention en cas d'incident. La gestion du cloud diffère grandement des tâches sur site, dans lesquelles les administrateurs contrôlent les serveurs et peuvent même les dépanner physiquement. Utilisez les ressources à la demande comme point de départ pour annuler instantanément les mises à jour problématiques.

Revisitez les procédures de sauvegarde d'application et de récupération après sinistre. Placez le site de récupération après sinistre dans une autre région AWS ou dans une zone de disponibilité ou assurez-vous que l'application peut basculer sur des serveurs sur site.

Étouffement étalement. La mise en service sur AWS est plus facile que sur site. Par conséquent, surveillez la taille du déploiement et les limites de dimensionnement périodiquement après la migration. Ajustez si nécessaire pour répondre à la demande et respectez votre budget. La mise à l'échelle automatique des ressources AWS peut masquer des problèmes de performances des applications. Par conséquent, examinez les factures pour toute utilisation imprévue.

La sécurité est une préoccupation pour la plupart des organisations qui déplacent des applications sur site vers AWS. Commencez par des vérifications simples, avec l'outil AWS Trusted Advisor, par exemple, pour détecter ce que Buchner appelle des "failles de sécurité flagrantes". Il existe également des outils sophistiqués d'audit de la sécurité commerciale. La prochaine étape consiste en une analyse d'environ trois heures par rapport au cadre AWS Well-Architected, qui mesure l'excellence opérationnelle, la sécurité, la fiabilité, la performance, l'efficacité et l'optimisation des coûts. De plus, dans le cas d'applications hautement sécurisées, les entreprises peuvent faire appel à des spécialistes de la sécurité pour auditer l'application, le réseau, le contrôle d'accès et d'autres surfaces d'attaque.

5. Gestion de projet et coût

Une liste de contrôle de migration AWS ne se termine pas lorsque votre projet est hébergé sur le cloud. Les considérations relatives à la gestion de projet, telles que l'évaluation de l'application et les décisions de l'équipe, sont importantes même après la migration. Revisitez-les fréquemment pour vous assurer que le projet est sur la bonne voie et souvenez-vous de former, former et former encore.

Définir les objectifs et la portée de la migration à long terme. Comment l'entreprise gérera-t-elle les comptes AWS et les dépenses lorsque les applications migreront? Chaque département gérera-t-il son propre déploiement AWS ou l'adoption du cloud sera-t-elle contrôlée de manière centralisée? Comment les décisions prises pour ce projet se répercuteront-elles dans toute l'organisation?

Construire un calendrier basé sur le plan de migration. Prenez en compte les vacances et les initiatives commerciales pertinentes pour créer un calendrier réaliste.

Évaluez les compétences du personnel en matière d'AWS et formez-vous en conséquence. Assurez-vous que le développement des compétences est spécifiquement lié aux tâches quotidiennes du membre de l'équipe. Capturez des sessions de formation pour une utilisation future et une amélioration continue.

Sélectionnez les bons outils et services. Les outils doivent répondre aux besoins de l’entreprise et les entreprises doivent former les administrateurs à leur utilisation. Réévaluez fréquemment les outils à mesure que de nouvelles fonctionnalités apparaissent et que le paysage des fournisseurs change. Interrogez les utilisateurs pour vous assurer que les outils fonctionnent comme prévu et qu'ils sont pleinement utilisés.

Formaliser la communication organisationnelle et le partage des connaissances. Tout le monde doit être sur la même page – architectes d’applications, développeurs, administrateurs et spécialistes des opérations de sécurité, ainsi que propriétaires d’applications et dirigeants d’entreprise. Centralisez la documentation du runbook, les modèles IaC et autres connaissances pertinentes pour le projet dans un wiki ou un autre référentiel.

Utiliser des estimations de coûts et des simulations pour définir un budget post-migration. Les dépenses en nuage peuvent rapidement devenir incontrôlables. Assurez-vous que le budget tient compte de la demande variable et cyclique et qu'il est possible de sonner l'alarme lorsque l'application s'écarte de la norme.

Lorsque les entreprises passent au cloud, elles doivent prévoir la gestion des comptes au fil du temps. Peu de gens ont abordé cette préoccupation au début, et une entreprise de taille moyenne peut facilement se retrouver avec 120 comptes AWS, a déclaré Buchner. Plus de comptes signifient plus de mots de passe, plus de frais généraux, de plus grandes lignes budgétaires et une complexité potentiellement inutile. Les entreprises peuvent regrouper leurs comptes avec AWS Organizations et ont probablement besoin de s'y consacrer après quelques incursions réussies dans le cloud.

Buchner conseille de séparer les comptes selon trois scénarios: si les comptes appartiennent à des équipes ou à des unités commerciales indépendantes sans chevauchement, lorsque l'entreprise doit connaître les coûts exacts associés à différentes charges de travail et pour des raisons de sécurité et de conformité lorsque diverses applications s'exécutent sur AWS.

Laisser un commentaire