Pour l’avant-dernière chronique de sa série sur le move-to-cloud, Benito Diz détaille les 7e et 8e étapes clés que sont le transport d’applications lui-même et le décommissionnement.
Dans mes précédentes chroniques, j’ai décrit les six premières étapes fondamentales pour un move-to-cloud réussi. Il est donc temps de rentrer au cœur du sujet de la migration elle-même.
7e étape : Réaliser le transport des applications, la migration
Dans le cas du transport ou du déménagement d’une application, il convient d’œuvrer à sa réinstallation en utilisant au maximum des solutions de services managés (PaaS). Ce qui a pour effet d’éviter d’acheter des licences et de maintenir les contrats de maintenance. L’entreprise conserve alors uniquement ses contrats d’assistance de haut niveau en cas de besoin.
A lire aussi : Move-to-cloud : quels fondamentaux pour (vraiment) réussir la transformation de l’entreprise ?
Alors, comme lors de la planification de la création du datacenter virtuel, il est indispensable de référencer et de taguer chaque objet utilisé afin de déterminer le périmètre exact (IaaS et PaaS) d’une application, et d’évaluer le coût exact associé aux services fournis.
Les flux des applications sont alors routés à travers le bus de données et l’API Gateway. Les chaînes d’exécution de travaux sont programmées, si possible (hors ordonnanceurs internes à certains progiciels qui font qu’il est complexe de sortir les traitements de la solution) dans le nouvel ordonnanceur. La configuration est inscrite dans le système d’automatisation et les processus d’intégration, de mise en production, de tests sont définis dans l’orchestrateur.
Pour obtenir une transparence et un contrôle continu des actions réalisées sur les infrastructures, tous les objets IaaS et PaaS sont décrits dans le Bastion d’accès et le passage à travers ce dernier est alors généralisé.
Comme vu lors de la création du datacenter virtuel, les outils de supervisions doivent évoluer pour se tourner vers les contrôles des points de fonction métier et vers le contrôle permanent d’intrusion. Ces derniers sont alors à développer en parallèle du déplacement de l’application.
Quant aux nouvelles applications, elles sont directement construites et architecturées dans le Cloud avec les services natifs Cloud. De même que pour le reste du système d’information, les flux de données sont routés à travers l’ESB et l’API Gateway, les infrastructures IaaS et PaaS sont sécurisées par le Bastion. Finalement, la supervision des points de fonction est plus simple à mettre en place dans ce nouvel environnement.
La migration des applications et des données se fait conformément aux règles de transport en lien avec le niveau de sensibilité des applications, et la destination doit correspondre au bon niveau de sensibilité.
Ce transport s’effectue par des canaux sécurisés et permet une purge des données en accord avec le principe de durée de conservation et celui de minimisation des données : supprimer les données personnelles qui ne sont plus utiles et/ou dont la durée de conservation établie est dépassée.
8e étape : Et si nous décommissionnions
Le périmètre de décommissionnement, les processus associés sont définis de façon précise.
Les décommissionnements concernent l’arrêt / désinstallation d’applications, des bases de données, des souches système, des matériels serveur et réseaux locaux du datacenter et autre si nécessaire, les baies informatiques, les accès réseau inter-sites… Sans oublier les contrats d’entretien, de maintenance, d’usage, d’assistance…
Il est important de bien lister tout ce qui est associé à une application, un module ou un service afin de ne pas oublier de les résilier. Il faut de même connaître en amont et référencer les périodes de prévention d’une résiliation afin de ne pas générer de surcoût alors que ces services ne sont plus utilisés.
Dans ma prochaine chronique, il ne nous restera donc qu’à étudier l’étape finale qu’est la « nouvelle production », mais aussi les questions du financement et de la « fin » du projet de move-to-cloud.