« Migration du nuage » est une expression qui peut effrayer même les entreprises les plus courageuses d’aujourd’hui, mais elle n’a pas besoin d’être aussi effrayante. L’an dernier, Davies a réussi à migrer toutes ses applications d’un centre de données conventionnel vers AWS (Amazon Web Services) et ici nous partageons quelques-unes des choses utiles que nous avons apprises en chemin. Petite mise en garde avant de commencer : il ne s’agit pas d’un guide étape par étape pour créer un plan de migration vers le cloud, mais plutôt de quelques conseils utiles que nous sommes heureux d’avoir pris en compte pour décider comment faire ce passage intimidant vers le cloud.
Apprenez l’environnement
L’infrastructure cloud partage de nombreuses caractéristiques avec les centres de données conventionnels dans les services qu’elle offre, mais au-delà des concepts de haut niveau, elle peut aborder les choses de manière très différente. Commencez par vous renseigner sur les offres offertes par le fournisseur infonuagique, et comment il est recommandé qu’elles soient toutes intégrées ensemble. AWS, par exemple, fournit un cadre bien architecturé qui partage leurs meilleures pratiques. Passez du temps à apprendre à penser de façon « native cloud », puis adaptez cela à votre charge de travail actuelle, plutôt que d’essayer de copier votre configuration existante dans le cloud. Un des principaux avantages de l’infrastructure cloud est la possibilité d’utiliser des services gérés. Copier les infrastructures et les patrons existants est une façon infaillible d’annuler cet avantage.
Construction pour l’échec
Cela est étroitement lié au point précédent, mais suffisamment important pour mériter une section à part entière. Le cloud vous offre d’excellents outils pour évoluer, tant pour la performance que pour la résilience. Vous pouvez lancer plusieurs serveurs, équilibrer la charge entre différents centres de données à travers le monde, directement depuis votre bureau! Sans trop de configurations supplémentaires, Davies fait fonctionner un système très résilient de sorte que lorsqu’un serveur qui tombe en panne, il est immédiatement terminé et qu’un nouveau remplacement est reconstruit à partir de zéro sans interruption d’application. Adopter cette approche dès le départ et traiter chaque serveur comme jetable élimine un énorme risque.
Détermine ce que tu veux faire toi-même
Comme mentionné plus haut, les plateformes cloud vous permettent d’utiliser de nombreux services gérés, où la maintenance et la gestion sont déchargées et cachées pour vous. Nous avons utilisé ces services partout où c’était possible, laissant la maintenance et les tâches quotidiennes à AWS, ce qui nous a permis de nous concentrer sur des choses plus grandes et meilleures.
Mais ça ne marchera pas toujours. Si vos exigences sont plus complexes, il se peut que vous manquez certaines fonctionnalités qui sont cachées par le processus géré. Le découvrir tôt est essentiel pour ne pas perdre de temps à déployer un service managé, pour ensuite réaliser plus tard que vous ne pouvez pas l’utiliser.
Utiliser l’infrastructure comme code
Je deviens un peu plus technique maintenant, mais Infrastructure as Code (IaC) vous permet de créer des modèles réutilisables qui décrivent tout ce qui concerne votre environnement cloud, des serveurs qui tournent, aux règles de pare-feu actives et aux noms de domaine que vous possédez. Cela peut sembler un cauchemar (créer un nouveau serveur en IaC prendra environ dix fois plus de temps que de cliquer sur le bouton dans la console web), mais croyez-nous, ça en vaut la peine :
- Réplication – vous pouvez déployer ce serveur autant de fois que vous le souhaitez, dans exactement le même état à chaque fois.
- Gestion des changements – en utilisant un système de contrôle de versions sur vos modèles, vous pouvez très facilement mettre en place un processus de gestion des changements autour de l’infrastructure
- Reprise après sinistre – un employé malveillant décide de supprimer tous vos actifs? J’espère que non, mais si tu utilises IaC, tu peux tout relancer en quelques minutes avec les modèles.
Automatisez, automatisez, automatisez!
Lors d’une récente entrevue, notre ingénieur principal en infrastructure cloud a dit qu’il adorait développer dans le cloud parce que « tout est une API ». À l’époque, le véritable impact de cela ne m’a pas frappé, mais c’est un concept très important à comprendre – tout ce qui peut être fait dans le nuage peut être automatisé. Avez-vous besoin d’envoyer par courriel un rapport de conformité mensuel depuis votre pare-feu? Ou créer temporairement des utilisateurs de tests de pénétration et mettre leurs adresses IP sur liste blanche? Vous voyez l’idée, tout peut être automatisé.
Lorsque Davies a migré nos applications vers le cloud l’an dernier, nous avons utilisé ces directives pour éclairer notre processus décisionnel. Les résultats? Nous avons réussi à construire une plateforme infonuagique prête à l’avenir, tout en évitant certains des pièges les plus courants liés à la migration vers le nuage. En fait, cette approche a été si réussie qu’elle est maintenant la base de tout ce que nous déployons sur AWS.