Gestion des risques lors de la modernisation des applications
Published on 28 Aug 2020
Les entreprises qui cherchent à tirer parti d'une plate-forme en tant que service (PaaS) telle que Pivotal Cloud Foundry et Red Hat Open Shift commencent généralement par deux environnements applicatifs :
De nouvelles initiatives (greenfield) qui peuvent être construites à partir de zéro en utilisant les meilleures pratiques natives du cloud
- Environnements d'application existants (brownfield) qu'ils souhaiteraient moderniser pour bénéficier des avantages d'agilité, d'évolutivité et de performance du cloud
- De nombreuses charges de travail existantes (brownfield) sont des applications critiques pour l'entreprise, génèrent des revenus substantiels et sont sensibles aux perturbations. Bien qu'il serait idéal de repenser complètement ces applications en utilisant les principes du cloud natif, cette solution n'est généralement ni pratique ni rentable.
Ce briefing fournit des conseils pratiques et des bonnes pratiques sur la manière de commencer à refactoriser une application monolithique. En combinaison, cela aide les équipes informatiques à accélérer le processus de modernisation et réduit le risque d'impact sur les événements clients et les processus métier en cours de route.
Par où commencer ?
Identifier les candidats et les composants pour le refactoring
Avant de commencer, posons le décor avec quelques hypothèses :
Vous démarrez avec un monolithe bien structuré :
Avant de commencer le processus de refactorisation des éléments de votre monolithe, vous devrez effectuer quelques travaux pour vous assurer qu'il est bien structuré. Si vous n'êtes pas sûr de commencer avec un monolithe bien structuré, apprenez-en plus en regardant cette vidéo « Modular Monoliths » de Simon Brown (@simonbrown), consultant industriel en architecture logicielle.
Vous utilisez des pratiques et des outils DevOps :
Pour tirer le meilleur parti du cloud natif, vous devez suivre les bonnes pratiques DevOps et utiliser des outils d'automatisation pour l'intégration continue (CI)/la livraison continue (CD). Pour plus d'informations à ce sujet, consultez l'eBook « Lessons Learned While Writing The DevOps Handbook » des auteurs : Gene Kim, Mark Tomlinson, Andi Grabner.
Qu'est-ce qu'un monolithe et comment le refactoriser ?
Nous avons tendance à considérer les monolithes comme quelque chose de mauvais dans le nouveau monde actuel des architectures d’applications distribuées et faiblement couplées. Si vous avez un monolithe bien structuré, le seul inconvénient est qu’il s’agit d’une base de code unique et que pour le faire évoluer, vous devez faire évoluer l’ensemble. En substance, « d’un point de vue logiciel, un monolithe est une combinaison de capacités métier ou de contextes délimités, tous liés à un contexte central. Le processus de transformation d’une application en une architecture basée sur des microservices implique la séparation de chacun de ces contextes délimités en leurs propres contextes. »
Voir aussi : 3 avantages de Citrix ADC avec des licences flexibles
