Torbz - Fotolia
Quelle est la meilleure approche pour mettre ses applications dans le cloud ?
Que vous souhaitiez mettre à jour les workloads dans le cadre d'une migration ou vous orienter vers un modèle cloud natif, examinez d'abord les avantages et les inconvénients de chaque approche.
La plupart des entreprises ont compris : migrer une application existante dans le cloud sans modifications préalables ne donnera pas de résultats probants. Au lieu de lieu de cela, elles doivent adopter des applications cloud natives ou moderniser les charges de travail existantes afin de tirer pleinement parti des technologies qu’elles utilisent.
Premièrement, cela demande de comprendre la différence entre une application modernisée et son alternative cloud native. La meilleure approche dépend des workloads, des compétences des équipes et des fonctionnalités que les sociétés considèrent les plus pertinentes à placer au sein d’une infrastructure totalement distribuée.
Dans le cadre d’une modernisation, les entreprises développent généralement le front end à l’aide de composants distribués et scalables. Ceux-ci proviennent souvent des offres de fournisseurs de services dans le cloud ou celles des éditeurs tiers. Les sociétés se concentrent surtout sur l’interface utilisateur, ce qui en fait des sortes d’extensions des serveurs web.
À l’inverse, l’approche cloud native consiste à détacher la plupart - sinon la totalité - des parties évolutives et distribuables d’une application afin qu’elles puissent être déployées en tant que microservices « stateless » connectées par des APIs. Cela facilite une meilleure adaptation et permet aux entreprises de déployer un plus grand nombre d’éléments dans le cloud.
Dans la plupart des cas, trois critères suffisent à choisir la bonne approche : la flexibilité des workloads, le choix de ce qui doit rester sur site et ce qui peut aller dans le cloud, et les caractéristiques de chargement de l’application.
1. La flexibilité des workloads
Toutes les charges de travail ne sont pas prêtes pour une modernisation pure et simple. Les applications tierces ne sont souvent pas modifiables. Théoriquement, les alternatives open source peuvent subir ce traitement, mais cela implique une courbe d’apprentissage importante et beaucoup de développement pour l’équipe en charge. De plus, l’actualisation de services tiers se limite souvent à une personnalisation du front-end.
Il est également difficile de changer des pans entiers d’un logiciel maison, surtout quand celui-ci accuse son âge. Le code source et la documentation peuvent être obsolètes et les compétences de programmation requises manquent parfois à l’entreprise. Dans le cas présent, il convient de concentrer cette phrase sur ce qui peut être mis à jour dans le cloud.
2. Hybride : les frontières à ne pas franchir
Qu’est ce qui doit aller dans le cloud ? Qu’est ce qui doit rester dans le data center ? Concrètement, cette décision dépend de facteurs tels que les règles de conformité et la sécurité des données. Souvent, les entreprises constatent qu'elles ont besoin de laisser les éléments critiques et les logiciels associés sur site. La modernisation ou l’approche cloud native n’est pas forcément la bonne solution, surtout si une petite partie de l’application peut être transférée dans le nuage.
Cependant, les fonctionnalités principales de produits métiers pourraient être redéveloppées. Pour ce faire, elles doivent être peu connectées et dépendre de faibles échanges de données.
Ce « rebuild » améliorerait les temps de réponse et de chargement, à condition que l’architecture hybride tienne la charge. Le volume d’échange de données est également un facteur important, puisque c’est ce qui coûte cher dans le cloud.
Le traitement des transactions à haut volume au niveau du back-end est beaucoup plus complexe que celui réalisé au front-end. En effet, la procédure demande un accès permanent aux bases de données et à leurs actualisations. Or, la plupart des entreprises ont déjà construit ou acquis des applications pour gérer ces processus dans le centre de données.
L’activité au niveau de la base de données est intrinsèquement dynamique : celle-ci enregistre des états que les transactions successives peuvent modifier. Les organisations peuvent utiliser des techniques cloud natives pour certaines parties de leurs applications critiques, tels que les éléments correspondant à l’édition et la conception de rapports. Pour ce qui est de la base de données associée, il est nécessaire de tester l’architecture transactionnelle afin d’obtenir des performances souhaitées.
3. Les caractéristiques de chargement de l’application
Le cloud s’avère idéal pour distribuer et multiplier les processus applicatifs. Si un logiciel demande peu de ressources, l’héberger sur ce type d’infrastructure distribuée n’apportera sans doute pas de gains significatifs. Cependant, les outils puissants et employés régulièrement profiteront pleinement de la migration. Pour ce qui est des workloads critiques à variable importante, adopter l’approche cloud native permet d’en tirer le meilleur parti.
Evidemment, l’application associée doit être utilisée par un nombre suffisant d’employés. Si peu de monde l’utilise, le volume des transactions sera trop faible pour justifier la migration, bien qu’elle puisse profiter de la containerisation.
En revanche, si elle est mise entre les mains de nombreux collaborateurs, de clients et de partenaires à travers un portail, alors celle-ci bénéficierait d’une architecture basée sur les microservices.
Par exemple, une campagne de publicité pourrait provoquer un pic de publicité - qui sans préparation, entraînerait un arrêt du service associé -, impacter négativement l’expérience client et faire échouer l’opération. Un cas d’usage parfait pour une approche cloud native.
Avant de se décider, il faut prendre en compte tous les aspects évoqués précédemment. Le cloud natif est bien adapté aux applications qui ne sont pas étroitement liées à l'état d'un compte ou d'un élément d'inventaire - vous pouvez les adapter ou les remplacer à volonté. Les applications modernisées tirent parti de la résilience du cloud et offrent également certains avantages en termes d'évolutivité, mais elles conservent des processus transactionnels traditionnels. Déterminer où les besoins se situent sur ce spectre aidera grandement à orienter cette stratégie.
