Stratégie de haut niveau
Une fois qu'une organisation a déterminé qu'elle est prête à passer à cloud, elle doit prendre un certain nombre de décisions spécifiques au contexte. Il est essentiel de disposer d'une stratégie générale et directrice.
En définissant vos objectifs et les problèmes que vous espérez résoudre grâce à votre stratégie de migration vers le cloud, vous pouvez vous assurer que vos stratégies commerciales et technologiques sont alignées. Qu'espérez-vous obtenir ?
- Essayez-vous de réduire les coûts ou d'améliorer les délais de mise sur le marché ?
- Vous avez du mal à attirer et à retenir du personnel qualifié ?
- Vous essayez d'améliorer la qualité de votre produit ou de vos services ?
- Ces objectifs sont-ils urgents ou à long terme ?
- Avez-vous des exigences de conformité à respecter lorsque vous vous rendez sur le site cloud?
Ces facteurs sont essentiels pour déterminer à quoi doit ressembler votre stratégie de migration vers cloud.
Sélection des fournisseurs
Pour une organisation relativement petite dont les exigences en matière de charge de travail sont homogènes, une stratégie de cloud à fournisseur unique peut s'avérer la plus appropriée, car il n'est pas nécessaire d'investir dans plusieurs fournisseurs de cloud pour des raisons de redondance technique ou pour éviter le verrouillage des fournisseurs.
Une organisation beaucoup plus importante, telle qu'une banque mondiale avec diverses charges de travail et différents niveaux d'exigences techniques, serait plus susceptible de poursuivre une stratégie multi-cloud, car cela donnerait à chaque équipe de projet la flexibilité de choisir le fournisseur qui répond le mieux à ses exigences. En outre, les grandes organisations sont plus susceptibles d'avoir des exigences de conformité internes et externes à remplir, et celles-ci peuvent nécessiter la capacité de déplacer les charges de travail entre les fournisseurs cloud dans un délai relativement court.
Une stratégie hybride, dans laquelle interviennent à la fois un centre de données traditionnel et le(s) fournisseur(s) cloud, peut également s'avérer judicieuse pour les moyennes et grandes entreprises, en particulier si la transition vers le site cloud s'étale sur plusieurs années. Cette stratégie peut également s'avérer pertinente s'il est nécessaire de faire évoluer vos tactiques de migration vers cloud de manière plus dynamique à mesure que vous en apprenez davantage sur la mise en œuvre des technologies cloud au sein de votre entreprise.
Les six R
Une fois que vous avez déterminé vos objectifs de migration vers le cloud et la stratégie de vos fournisseurs, l'étape suivante consiste à décider de la manière dont vous allez procéder pour migrer vos charges de travail vers le cloud.
Tout d'abord, vous devez procéder à un audit de votre application existante. Cela peut vous donner une idée du niveau et de la nature du travail requis pour aller sur le site cloud. Lors de cet audit, vous pouvez classer votre application en fonction de l'approche que vous souhaitez que les équipes qui en ont la charge adoptent pour leur migration vers cloud. AWS présente six "stratégies de migration courantes ". Ces stratégies peuvent être appliquées de manière générale ou chaque équipe peut choisir la stratégie la plus adaptée à sa situation du moment, en fonction de la taille de l'organisation et de la complexité de la situation.
1. Réhéberger
La première stratégie, la plus simple, consiste à réhéberger votre application (également connue sous le nom de "lift and shift"). Il s'agit de les déplacer des serveurs physiques d'un centre de données vers des serveurs virtuels fonctionnant sur le site cloud. En général, cela ne nécessite aucune modification du code et relativement peu de changements au niveau des processus et des technologies environnantes telles que les réseaux. Elle peut également permettre à votre organisation d'acquérir les compétences et l'expérience en matière de cloud computing nécessaires à d'autres pratiques natives du cloud computing.
2. Replatform
Également connue sous le nom de "lift, tinker and shift", cette approche est similaire au rehosting, mais va plus loin en intégrant un certain nombre de services cloud fondamentaux au niveau de l'application. Par exemple, AWS IAM (Identity and Access Management) peut être intégré à votre application pour remplacer ou compléter les systèmes IAM plus traditionnels orientés vers les centres de données.
3. Le rachat
Également connue sous le nom de "drop and shop", cette approche consiste à remplacer une application existante sur site par un service sous licence basé sur le site cloud. Il peut s'agir de modifier le modèle de licence utilisé par votre entreprise, de réduire le coût de la maintenance et, éventuellement, de permettre une mise à niveau plus rapide et plus facile.
4. Refactoriser/Reconstruire
Une approche plus "cloud-native" consiste à prendre vos bases de code existantes et à les modifier ou à les étendre pour qu'elles fonctionnent avec des services "cloud" plus modernes. Un exemple consiste à conteneuriser le code de votre application, à exécuter la configuration et à les exécuter au sein d'un service Kubernetes basé sur le cloud, tel que l'EKS d'Amazon ou l'AKS d'Azure. Cela peut impliquer des réécritures substantielles de votre base de code existante pour lui permettre de fonctionner et d'augmenter l'évolutivité ; une réécriture complète peut même être nécessaire pour utiliser des outils véritablement cloud-natifs (par exemple, des outils sans serveur comme AWS Lambda ou Azure Functions).
5. Retraite
Avec les deux dernières stratégies "passives", les charges de travail ne sont pas du tout transférées sur le site cloud. Votre audit de la charge de travail peut révéler des systèmes redondants ou qui ne valent plus la peine d'être maintenus. Ces applications peuvent être retirées.
6. Conserver
La dernière stratégie "passive", la rétention, consiste à maintenir votre application en fonctionnement et à choisir de ne pas la migrer vers le site cloud dans un avenir prévisible. Il existe un certain nombre de raisons de conserver votre demande en dehors du site cloud, notamment
- Contraintes réglementaires sur le lieu d'exécution de l'application ou exigences élevées de conformité interne en matière de sécurité
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- Pas d'analyse de rentabilité pour les perturbations causées par le déplacement de l'application
- Les systèmes existants ne sont pas pris en charge dans les environnements cloud
Par où commencer ?
En plus de décider de votre stratégie globale et de classer l'approche tactique par charge de travail, vous aurez besoin d'un plan pour construire votre infrastructure cloud afin de prendre en charge le déplacement des charges de travail. Une approche consiste à laisser chaque équipe choisir la manière de construire ses propres systèmes sur le site cloud. Cette approche présente toutefois plusieurs inconvénients, car les équipes peuvent reproduire des schémas de mise en œuvre erronés et répéter les erreurs des autres ou violer les règles de conformité internes/externes.
Une autre approche consiste à créer une sorte de "centre d'excellence" centralisé ou une équipe d'infrastructure ( cloud ). Cette équipe peut choisir de mettre en place les systèmes de base sur lesquels les autres équipes peuvent exécuter leurs charges de travail.
Lorsqu'il s'agit de mettre en place ces garde-corps, certains éléments de conception doivent être privilégiés par rapport à d'autres.
Comptes
L'unité la plus élémentaire de votre architecture cloud est le compte cloud. L'utilisation d'un seul compte pour l'ensemble de votre organisation n'est presque jamais évolutive, car vous finissez par vous heurter à des limites de compte. Il est donc important de déterminer les limites du compte. Le compte sera-t-il utilisé pour représenter une unité commerciale particulière, une équipe individuelle ou un groupe de services logiciels ? Comment cela fonctionnera-t-il avec votre service financier ? Qui doit recevoir la facture ? Il est important de le savoir dès le départ, car les coûts peuvent s'accumuler rapidement.
IAM
Le système de gestion des identités et des accès est l'unité d'architecture la plus élémentaire. Au fur et à mesure que votre infrastructure cloud se développe, vous devrez prendre en compte les implications en matière de sécurité de l'accès des utilisateurs aux différents services et données cloud, et le plus tôt sera le mieux. Imposer ces règles rétrospectivement à des systèmes qui fonctionnent déjà peut s'avérer compliqué.
Mise en réseau
La migration vers le site cloud implique soit la virtualisation de votre réseau existant, soit une refonte complète. Le service VPC (AWS) ou VNet (Azure) vous permet de configurer un réseau isolé pour exécuter un ensemble de services distinct au sein de votre compte. Il convient d'accorder une attention particulière à la communication entre les services de votre organisation et les ressources de base du réseau, telles que les adresses IP.
Migration des données
S'il est facile de migrer les services informatiques vers le site cloud, la migration des données peut s'avérer un peu plus délicate. Les grands entrepôts de données peuvent être de grandes infrastructures complexes dont le déplacement nécessite une planification minutieuse. Pour ce faire, il faut savoir comment transférer vos données sur le site cloud tout en respectant les normes de performance, de conformité et d'exploitabilité de votre organisation.
Conclusion :
Une fois que vous avez défini votre stratégie de haut niveau pour cloud, l'élaboration d'une stratégie de migrationcloud réussie nécessite une planification méticuleuse et la prise en compte de tous les aspects de votre entreprise. L'étape suivante consiste à choisir la stratégie de fournisseur de cloud qui vous convient, qu'il s'agisse d'une migration simple vers un seul fournisseur, d'une approche multi-fournisseurs de cloud ou d'une stratégie hybride. Enfin, vous devez architecturer votre migration vers cloud en considérant d'abord les composants clés de l'infrastructure avant de commencer à intégrer l'application.
J'espère que cet article de blog a été intéressant et utile.
Surveillez les prochains articles de blog sur les conteneurs/Kubernetes et les services sans serveur.
Si vous commencez à vous rendre sur le site cloud, vous souhaiterez peut-être lire mon nouveau livre blanc intitulé Five Best Practices for Secure cloud Migration (Cinq bonnes pratiques pour une migration sécurisée vers le site).
Vous pouvez en savoir plus sur les solutions de Sécurité du cloud de Point de contrôle ici ou planifier une démo avec l'un des ingénieurs Sécurité du cloud de Point de contrôle ici.
Pour comprendre comment concevoir et mettre en œuvre des architectures de cloud sécurisées, consultez ce livre blanc.
Commentaires