Now Reading
Une approche de la modernisation cloud – 2
0

Une approche de la modernisation cloud – 2

by Cloud Guru4 septembre 2013

Dans la première partie, nous avons discuté du modèle d’évaluation de l’infrastructure informatique et de l’environnement informatique en cours, notamment du matériel utilisé, de la pile logicielle, du niveau logiciel en cours, ainsi que des différentes zones réseau telles que l’intranet, l’extranet et Internet. Nous avons aussi traité de l’importance de la collecte automatisée des données à l’aide d’outils et de scripts, ainsi que de l’application des sorties de ces scripts dans le modèle d’adoption du cloud suivant.

Modèle d’adoption du cloud

Une fois l’évaluation terminée, l’étape suivante consiste à exécuter une analyse de faisabilité et à développer une stratégie pour la modernisation cloud dans un environnement cloud IBM. Une vue en diagramme de la stratégie d’adoption du cloud pratiquée par IBM (en anglais) est décrite ci-dessous.

Un modèle de référence pour l’adoption d’une solution cloud utilisant différents services doit être considéré lors de la création d’une stratégie de modernisation cloud. Dans le cadre de notre travail, nous avons pris en compte l’infrastructure sous forme de service (IaaS), la plateforme sous forme de service (PaaS) et le logiciel sous forme de services (SaaS) pour la modernisation cloud. Nous n’avons pas pris le processus métier sous forme de service (BPaaS) en compte dans le contexte en cours, considérant que notre besoin de modernisation cloud ne satisfaisait pas aux aspects d’optimisation des processus métier.

Identification de candidats pour le cloud cible

Modèle d’adoption IaaS

Le modèle d’adoption IaaS est destiné à faire passer l’image d’applications dans son ensemble de l’environnement source à l’environnement cible. Au cours de notre travail, nous avons appliqué la règle du 80-20, selon laquelle 20 % des applications au sein de l’entreprise du client et la plupart des applications critiques sont associées à de fortes exigences non fonctionnelles telles que les performances et la croissance. La plupart des applications vont passer dans l’environnement cloud cible EN L’ETAT, avec peu de changements. Cela réduit également le risque d’incertitude durant la migration vers le cloud car le changement du nom d’hôte et de l’adresse IP augmente le risque et le coût de la migration en raison d’une dépendance des connexions en amont et en aval, des règles de pare-feu, de la configuration de proxy et des certificats.

Il existe plusieurs façons d’adopter ce modèle, par exemple en étendant le réseau existant dans un environnement cloud cible, comme une extension de réseau local virtuel (VLAN) où le même sous-réseau ou la même passerelle peut être conservé(e) entre la source et le réseau cible. Vous pouvez faire une copie de l’image à l’aide d’outils tels que PlateSpin, VM-Converter, MS-backup et Flash-achieve. La plupart des organisations déplacent leur charge de travail en deux temps afin de minimiser le risque de migration vers le cloud, en passant au cloud en l’état sans introduire beaucoup de modifications, opération associée à un retour sur investissement immédiat du fait de la réduction de l’empreinte matérielle, puis en optimisant l’environnement pour une meilleur efficacité, ce qui entraînera une amélioration continue.

article1_2Modèle d’adoption PaaS

Le modèle d’adoption PaaS est associé à un catalogue défini de services s’exécutant pour un ensemble de logiciels middleware dans un ensemble prédéfini de l’environnement du système d’exploitation. Les applications ne peuvent pas être déplacées en l’état en raison de l’incompatibilité du middleware ou de la version du système d’exploitation entre la source et l’environnement cible. Cette opération requiert une transformation des applications, laquelle est associée à la mise à niveau du middleware applicatif ou de l’environnement du système d’exploitation existant, ou à la remise en plateforme de l’environnement de déploiement d’applications en cours. La charge de travail qui ne peut pas être déplacée vers l’IaaS en l’état en raison de l’incompatibilité d’une image existante dans le matériel cible requiert le modèle d’adoption PaaS suivant :

  • Au niveau machine virtuelle (VM) : création d’une machine virtuelle dans l’environnement cible et migration du composant depuis la source vers la cible à la place d’un déplacement de l’image complète. Des outils tels que AppZero peuvent être optimisés pour la migration de niveau composant.
  • Au niveau conteneur/instance d’application : déplacement de l’application Java d’entreprise depuis l’ancien conteneur vers le nouveau conteneur, avec par exemple WebSphere Migration Toolkit, exportation-importation du profil d’application.
  • Au niveau instance de base de données : déplacement de la charge de travail de base de données depuis l’instance de base de données source vers l’instance de base de données cible. Des outils comme DB2Move, DB2load peuvent être optimisés pour la migration au niveau des instances de base de données.

Ce modèle d’adoption est plus complexe que l’adoption IaaS et requiert un savoir faire applicatif poussé, ainsi qu’une bonne connaissance des tests.

Modèle d’adoption SaaS

Le modèle d’adoption SaaS est associé à la transformation de l’application source en services prêts à l’emploi dans le cloud d’un environnement cible. Dans le scénario d’adoption SaaS, l’application n’est ni migrée en l’état, ni mise à niveau vers l’environnement cible. Ce modèle est associé à la réécriture d’application afin d’adapter des services cloud existants dans un environnement cible. La génération d’une application à service partagé ou d’une base de données à service partagé, ou encore l’adoption de services cloud dans un environnement cible constituent des exemples du modèle d’adoption SaaS. Il s’agit du type de transformation le plus complexe d’adoption du cloud, et il nécessite la réingénierie des applications pour l’environnement cible. Toutes les méthodes de cycle de vie de projet pour le développement et la transformation d’application doivent être suivies pour atteindre le résultat escompté.

Sélection du candidat

Après avoir finalisé l’adoption du cloud, nous devons nous à référer l’infrastructure informatique et aux résultats d’évaluation des applications afin d’établir un organigramme destiné à regrouper la charge de travail applicative en utilisant le choix d’adoption ci-dessous. Les candidats sont sélectionnés en fonction de la compatibilité logicielle, de l’architecture de référence, des caractéristiques de la charge de travail et des dépendances de plateforme applicative.

Le processus suivant peut être adopté pour la sélection du candidat :

  • Séparer et lancer le groupe de la « victoire rapide » (qui ne nécessite pas d’évaluation de niveau détaillée) et mettre en place les plannings d’implémentation.
  • Collecter les données d’application détaillées propre à l’application, examiner les interfaces applicatives et le déploiement/développement d’application dans l’environnement en cours
  • Faire l’inventaire du code d’application pour chaque application personnalisée – par exemple, exécutez un outil de comptage de code en fonction des référentiels de code
  • Comprendre et estimer l’effort et le coût pour que réseau, systèmes, stockage et licences logicielles soient prêts
  • Déterminer s’il existe des projets en cours associés à des contraintes de disponibilité de ressource

Conclusion

Pour récapituler cette approche, il est particulièrement important de maîtriser les environnements informatiques et les modèles d’adoption cible. L’étape suivante consiste à catégoriser la charge de travail en fonction du modèle d’adoption, à estimer l’effort et le coût pour chaque modèle d’adoption. Nous devons considérer que pour toute initiative de modernisation cloud, une approche de type big-bang constitue la pire des erreurs. Une évaluation rigoureuse de la charge de travail et de la stratégie impliquée dans chacun des modèles d’adoption sont la clé du succès. Toutes les solutions de modernisation cloud doivent être étudiées depuis une perspective d’entreprise. La définition du retour sur investissements en fonction du modèle adopté, ainsi que l’organigramme qui en découle, doit être effectuée sur une période de temps suffisante.

b-mohapatraBiswajit Mohapatra est consultant agréé IBM et responsable Global Integrated Delivery pour IBM BAM (AMS Business Application Modernization). Biswajit est respondable IBM India Competency for Global Specialized Application Modernization (AM) et Conversions & Migration (C&M) Competency.   Biswajit possède une expérience multi-fonctions de 17 années dans l’industrie informatique couvrant l’expertise-conseil, la définition d’organigrammes technologiques, l’architecture de solutions, l’incubation d’offres, l’innovation technologique, la mise en place de solutions, le développement de capacités et fonctions, l’établissement d’équipes basées sur la pratique, la gestion de grands comptes avec responsabilité P&L, la gestion des relations client/partenaire/alliance, la direction de centre de distribution d’unité métier stratégique, ainsi que la prise en charge de la distribution intégrée mondiale. Biswajit possède une maîtrise des disciplines et outils de reconception des processus métier, architecture métier et innovation technologique destinés à aider les organisations à atteindre leurs objectifs de transformation. Les responsabilités actuelles de Biswajit incluent la croissance de la rationalisation de portefeuille des applications, l’analyse d’applications et les organigrammes d’implémentation, l’extraction de règles métier, le portage, la conversion, la restructuration, la réingénierie, la consolidation, l’activation Web, l’adaptation de systèmes existants à SOA et la modernisation cloud.

d-roy-choudhuriDebasis Roy Choudhuri est architecte senior certifié IBM et architecte en chef de Business Application Modernization, distribution mondiale IBM. Il possède une expérience de 15 ans dans l’industrie, englobant une large gamme de compétences et rôles dans les verticales. Il est spécialisé dans la conception d’infrastructures applicatives, la consolidation de serveurs, la migration de charge de travail à partir de systèmes existants vers différents environnements virtualisés et cloud. Il possède une expérience exhaustive de l’architecture et de la conception, des personnalisations et de la mise en oeuvre de différentes solutions de transformation. Il a pris part à différentes procédures de rupture de contrat de travail de centre de données complexes depuis 2006. Il est également membre du comité de révision de certification pour l’Architecture Review Board (Inde). Il travaille actuellement sur des engagements de solution cloud pour des clients IBM ANZ.

Retrouvez l’article en version original sur thoughtsoncloud.com

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?