Le cloud est là
De nos jours le cloud est présent dans la grande majorité des entreprises que ce soit au travers d’une application en mode SaaS, d’un service d’infrastructure managé comme la sauvegarde, le stockage ou autre, mais aussi au travers de souscriptions Azure ou AWS pour ne citer qu’eux.
Malgré tout, rares sont les entreprises à avoir opté pour le « TOUT Cloud ». J’ai pour ma part récemment accompagné plusieurs DSI dans cette prise de décision et je vais vous faire part de mon retour d’expérience sur le sujet.
Au passage…
Tout d’abord, si vous ne l’avez pas déjà fait, je vous invite à lire mes articles sur le déménagement de datacenter disponibles sur le site web METANEXT.
Mon objectif n’est pas simplement d’augmenter le nombre de vues de mes précédents articles mais bien le fait que les problématiques soient très semblables que l’on migre un datacenter vers un autre datacenter ou vers le cloud.
Allez on se lance !
Bien que souvent évité car considéré comme risqué, le déménagement d’un datacenter est toujours motivé par des raisons pécuniaires, l’insatisfaction de l’hébergeur ou une stratégie d’entreprise.
En revanche la décision de migrer dans le cloud est parfois prise suite à un lobbying accru des acteurs majeurs du cloud public ou un effet de mode. C’est pour éviter de faire un choix inadapté à l’entreprise qu’il est essentiel d’étudier la faisabilité technique et financière.
Qu’avons-nous à migrer ?
Comme dans toute étude, pour pouvoir se projeter il faut savoir ce que l’on a. La première étape est donc de référencer l’existant afin de déterminer :
- Le périmètre et la volumétrie concernés
- Les interactions applicatives
- Les niveaux de services attendus
- Les contraintes de sécurité
- Les stratégies en termes de PCA et PRA
- Les obligations réglementaires (ex : localisation)
- Les contrats de licences (ex : BYOL ?)
- Les forces et faiblesses du SI (techniques, organisationnelles, …)
- ….
L’objectif est de disposer de la vision la plus exhaustive possible de l’existant. On s’appuiera autant que faire ce peut sur la documentation disponible (référentiel, DAT, cartographie du SI, …) et sur la connaissance du SI par les équipes en place.
Un point important à ne pas négliger dans cet audit, c’est l’ensemble des appliances physiques présentes dans le SI. Qui dit cloud dit environnement virtuel. Il faut donc trouver une solution pour le devenir de ces appliances. Bien souvent celles-ci ont un équivalent virtuel disponible chez les cloud providers.
Mais attention à l’aspect licence. En effet il faut également vérifier que les licences pour l’équipement physique soient compatibles ou transférables sur son équivalent virtuel (ce qui malheureusement est rarement le cas). Dans le cas où un équivalent virtuel n’est pas possible il faudra noter dans l’étude de prévoir un projet de remplacement de la fonctionnalité.
Une fois l’audit flash terminé passons à la projection du SI dans le cloud.
L’hébergement
L’aspect hébergement est à étudier en priorité. Plusieurs aspects sont à prendre en compte dans le choix de l’hébergement cible :
- La couverture de risques : avec la combinaison de zones de disponibilités (AZ en anglais dans le texte pour Availability Zone qui correspond globalement à 2 salles physiques ou 2 bâtiments) et de régions (soit généralement l’échelle d’un état) on peut couvrir l’ensemble des risques imaginables. Tout en sachant que plus on couvre de risques plus le coût sera élevé !
- Les services nécessaires : tous les services ne sont pas disponibles sur l’ensemble des régions, il est donc important de connaitre vos besoins avant de choisir la cible
- Le coût : les coûts d’hébergement sont différents en fonction de la région
L’interconnexion
Une fois la région cible choisie vient ensuite la problématique réseau et notamment l’interconnexion au cloud provider.
Il est possible de se connecter au cloud public de différentes manières mais il est évident que pour gérer l’ensemble des infrastructures d’un SI, la mise en place de liens directs est nécessaire. Petite subtilité, le terme « direct » est un peu galvaudé parce que pour vous connecter à votre cloud provider il faudra prendre un lien chez un opérateur qui vous mettra en relation avec le lien du cloud provider.
Ce qui signifie que vous devrez payer un abonnement opérateur et un abonnement à votre cloud provider. En suite vous ne payerez que les données sortantes du cloud.
Le réseau
Outre l’interconnexion réseau, la gestion de la topologie réseau dans le cloud est aussi à prendre en compte. Comme pour l’ensemble des services disponibles dans le cloud public, on peut très vite se retrouver avec une topologie réseau hétérogène et difficile à gérer. Pour éviter cela il est recommandé de partir sur une topologie « hub and spoke ».
D’une part vos entrées/sorties se feront à travers un réseau virtuel type DMZ (le « hub ») ce qui permet une meilleure sécurisation de votre environnement cloud et d’autre part vous pouvez créer une multitude de réseaux virtuels selon vos besoins (les « spoke ») qui seront reliés au hub.
De plus ce service permet une gestion centralisée du réseau (configuration des liens sécurisés, des flux réseau, …). Enfin si ce service pouvait être un SPOF dans ces premières versions, aujourd’hui que ce soit avec Azure ou AWS le service peut être résilient.
Enfin, il ne faut pas oublier de réfléchir aux contraintes de l’interconnexion réseau durant le projet et à la cible. Notamment les aspects d’extension de réseau et les modalités de routage durant le projet.
Les serveurs
Alors qu’un déménagement d’un datacenter physique vers un autre implique des problématiques de choix entre physique ou virtuel pour les serveurs, la migration vers le cloud n’offre pas cette possibilité.
Ce sera virtuel ou pas ! Malgré tout, des alternatives sont possibles dans le virtuel, surtout si vous utilisez VMware pour votre infrastructure de production. En effet des offres VMware pour le cloud hybride sont disponibles (VMC on AWS, AVS, GCVE, OVHcloud Hosted Private Cloud, …). Ces solutions permettent d’envisager une migration par étape, en limitant fortement les changements, tout en mettant progressivement un pied dans le cloud.
Car migrer dans le cloud c’est faire un choix dans le devenir de votre SI et de vos applications.
Plusieurs possibilités s’offrent à vous :
- Rehosting ou « As Is »: soit la migration à l’identique de votre infrastructure.
- Replatforming: soit l’utilisation de services du cloud pour certaines briques de votre infrastructure comme les bases de données par exemple en mode DBaaS
- Refactoring: soit la transformation de votre SI en mode « Cloud Native » pour utiliser au mieux les services du cloud
- Repurchasing: soit acheter un service équivalent dans le cloud en mode SaaS
- Retire: soit l’abandon de la solution
Ce qu’il faut appréhender c’est l’aspect financier de votre choix. Globalement moins vous ferez de changements sur votre infrastructure durant la migration, plus vous paierez un coût d’hébergement élevé.
En revanche plus vous allez transformer et utiliser les services natifs du cloud moins le coût d’hébergement sera élevé. Mais transformer représente également un coût important et demande du temps et des compétences.
Mon avis est que si vous avez du temps pour migrer il faut autant que possible privilégier le refactoring et et le replatforming. Au contraire si vous êtres pris par le temps le choix du « As Is » ou des solutions cloud hybride VMware sont à privilégier.
Vous resterez dans un environnement VMware familier et les outils de migration à votre disposition seront plus adaptés.
La disponibilité
Maintenant, nous savons où seront nos infrastructures, comment nous serons inter-connectés et quels services de compute nous allons utiliser. Alors nous pouvons réfléchir à la gestion de la disponibilité des services.
En entrée il faut s’appuyer sur les classes de services définies sur l’existant (normalement en accord avec le Métier !) puis projeter le besoin avec les services disponibles. Sur ce point tous les cloud ne sont pas égaux.
Il faudra donc pour chaque classe de service et chaque cloud provider faire correspondre le besoin avec une solution technique (ex : résilience applicative, DRaaS, basic failover, sauvegarde…). Il est à noter que les solutions type résilience applicative ou DRaaS impliquent peu de changements d’architecture mais ont un coût plus élevé. A l’inverse le basic failover implique souvent des changements d’architecture qui sont à prendre en compte lors de la migration.
L’organisation
Enfin, une fois que nous avons parcouru les différents aspects de notre SI, arrêtons-nous sur les aspects organisationnels et de gestion de l’humain.
Le cloud n’est pas un hébergement classique. Si le cloud est agile, flexible et en innovation permanente cela implique une organisation et des équipes capables d’être également agiles, flexibles et en perpétuelle évolution.
Un projet de migration dans le cloud implique un vrai travail sur l’organisation à mettre en place, de la gouvernance au MCO, pour gérer au mieux le cloud et un grand plan de formation des équipes pour adopter a minima le vocabulaire et acquérir le savoir-faire propre au cloud.
Cet aspect est souvent minimisé mais il est une part non négligeable du budget projet. De plus il est essentiel pour une adoption complète et réussie.
En conclusion
Si la migration dans le cloud est en partie semblable à un simple déménagement de datacenter, de nombreux points spécifiques au cloud sont à prendre en compte pour une migration réussie.
De plus il ne faut pas oublier qu’au-delà d’un simple déplacement des infrastructures, le cloud implique également des changements d’organisation et une vraie montée en compétence des équipes pour une intégration réussie.
par Thibault LABRUT, Architecte Solutions
