Le guide de la migration cloud

Pour commencer, examinons quelques chiffres intéressants. Gartner suit les marchés de l'IT depuis de nombreuses années et prévoit que le nombre d'organisations utilisant des services cloud doublera entre 2018 et 2022. Les sommes dépensées pour les services cloud devrait également doubler sur la même période pour atteindre près de 300 milliards d'euros par an. Pourtant, passer au cloud présente des défis. Selon un sondage organisé par KPMG, 54% des CIO ont déclaré que l'intégration avec le paysage applicatif existant était le plus grand obstacle à l'adoption du cloud. McKinsey a récemment interrogé des CIO sur leurs projets de modernisation IT, dans lesquels le cloud joue un rôle majeur. Ils ont constaté que 80% de ces projets n'ont pas apporté l'agilité ou la valeur métier escomptée. Alors, si le passage au cloud est si difficile, pourquoi les entreprises le font-elles? Et comment peuvent-elles maximiser leurs chances de succès ?

Tout d'abord, examinons les priorités d'un dirigeant classique. Il ne se concentre pas sur la technologie ni même sur la réduction des coûts. Selon McKinsey, la première priorité des dirigeants est la croissance du chiffre d'affaires, suivie de près par l'amélioration de l'agilité et la réduction des délais de mise sur le marché. La plupart d'entre eux sont conscients que les technologies digitales sont un élément clé pour atteindre ces objectifs et attendent de leur DSI qu'il joue un rôle clé dans leur réalisation.

Cependant, dans la plupart des cas, le DSI n'a pas le luxe de pouvoir définir une nouvelle architecture moderne. Il consacre jusqu'à 80 % de son budget annuel à la maintenance des systèmes en place, ce qui laisse peu de ressources disponibles pour l'innovation. Les DSI avec lesquels nous nous entretenons sont conscients qu'une modernisation de leurs systèmes informatiques est nécessaire, et que les technologies en cloud participeront à cette modernisation. Mais il est souvent difficile de savoir par où commencer. Quelles sont les options disponibles ? Et quelle approche est la meilleure pour quel type d'application ?

Examinons quelques modèles simples qui peuvent vous aider à réfléchir de manière structurée à votre migration vers le cloud. Il y a essentiellement trois façons de transférer des capacités IT vers le Cloud :

Lift & shift

Dans ce cas, vous récupérez généralement une application existante et la déployez telle quelle sur une infrastructure as a service (autrement nommée IaaS) dans le cloud. Cette approche présente de nombreux avantages : vous pouvez migrer rapidement vers le cloud et le logiciel ne fonctionnera plus une machine dans votre datacenter que vous devez exploiter, maintenir, sauvegarder et mettre à jour. L'inconvénient est qu'il s'agit toujours du même logiciel que vous devez continuer à exploiter, patcher et debugger par vos propres moyens. L'architecture de ce logiciel, conçue pour fonctionner on-premise, ne s'adaptera pas facilement à la charge et ne disposera pas non plus d'une haute disponibilité intrinsèque.

Adopter le SaaS

La deuxième option consiste à adopter les fonctionnalités fournies par une application SaaS (Software-as-a-Service). Salesforce, ServiceNow ou Marketo en sont de bons exemples. Lorsque vous transférez une fonction métier particulière vers une application SaaS, vous pouvez être en mesure d'arrêter ou de mettre hors service une ancienne application on-premise. L'avantage est que les applications sont "cloud native", avec une tarification claire et sans effort opérationnel de votre part. L'inconvénient est que ces applications SaaS sont souvent adoptées par vos concurrents, ce qui signifie que vous ne pouvez pas différencier votre activité avec elles.

Développer des solutions cloud-native

La troisième option consiste à créer de nouvelles applications cloud natives en utilisant toutes les capacités offertes par une plateforme PaaS (platform-as-a-service), par exemple chez AWS et Azure. Cela peut également vous permettre de supprimer les applications on-premise obsolètes. L'un des principaux avantages de cette approche est la rapidité de mise sur le marché, ce qui la rend très adaptée à vos systèmes d'innovation.

En outre, en créant vos applications à partir de zéro, vous pouvez tirer parti de ce que les fournisseurs de services en cloud offrent de mieux - par exemple, des bases de données et un accès facile à d'immenses espaces de stockage qui peuvent être utilisés comme des "data lakes" pour l'analyse. Parmi les inconvénients, on peut citer le risque d'être lié à un fournisseur de services cloud particulier et les coûts souvent imprévisibles, qui peuvent facilement exploser si la solution n'est pas conçue avec soin.

Vous utiliserez très probablement un mélange de ces trois méthodes. Mais quelle est la plus appropriée pour quel type d'application ? Gartner nous propose un autre modèle très utile à cet égard : le modèle dit du "pace-layer".

L'infrastructure de votre entreprise repose sur les systèmes d'enregistrement ou "Systems of record". Il s'agit des systèmes fondamentaux qui permettent à votre entreprise de fonctionner - votre grand livre financier, votre système de ressources humaines, votre système de gestion d'entrepôt. Ils contiennent les données de votre coeur de métier, qui sont très bien gérées et ne subissent pas de changements fréquents.

Vous ne pouvez pas vous permettre de prendre des risques avec ces systèmes, mais vous ne pourrez pas non plus vous démarquer de vos concurrents avec eux. Il s'agit d'applications standard utilisées par toutes les entreprises, mais elles sont aussi souvent fortement personnalisées pour s'adapter aux spécificités de votre entreprise.

Les systèmes de différenciation constituent la couche suivante. Ce sont les systèmes qui vous permettent de faire ce que vous faites mieux, plus vite et moins cher que vos concurrents. Ils vous donnent l'avantage et ne sont généralement pas fournis par des applications packagées. Par leur nature même, ils sont conçus sur mesure. Et vous souhaitez qu'ils soient plus agiles et plus adaptables que vos systèmes d'enregistrement.

Au sommet se trouvent les systèmes d'innovation. Ils vous aident à pénétrer de nouveaux marchés, de nouveaux canaux, et à vous rendre là où vos concurrents ne sont pas présents. Pour réussir, ils requièrent une rapidité et une agilité extrêmes. Si nous réunissons ces deux modèles, il devient plus facile de définir une trajectoire de migration vers le cloud.

Les systèmes d'enregistrement sont au cœur de votre activité et vous devez les utiliser de manière très prudente. Ces systèmes resteront probablement sur site, car ils sont essentiels pour votre entreprise. Nous parlons ici des systèmes ERP hautement customisés que vous utilisez, ou du mainframe qui n'a pas été modifié depuis des années, mais qui fonctionne bien et conserve sa fonction de base en bon état. Vous pouvez essayer de déplacer ces systèmes ou même de les remplacer un par un par un logiciel SaaS, mais en raison de la criticité du logiciel, ces migrations seront entreprises avec beaucoup de précautions et seront généralement les dernières à être réalisées.

Les systèmes de différenciation et les systèmes d'innovation peuvent également être déplacés, mais c'est en exploitant toute la puissance des plateformes PaaS modernes que vous en tirerez le plus grand profit. Elles fournissent des blocs de construction pour le stockage de données massives, l'analytique, l'IA, les interfaces utilisateur et bien plus encore.

En réalité, la migration de vos applications ne se produira pas comme un big bang et vous aurez un paysage très diversifié d'applications et de types d'hébergement à chaque instant. De nombreux systèmes d'archivage resteront longtemps sur site, tandis que l'entreprise adoptera rapidement de nouvelles applications SaaS pour répondre à ses nouveaux besoins. Enfin, tout nouveau système d'innovation sera directement écrit sur les plateformes cloud. Ainsi, votre infrastructure sera en partie sur site, en partie sous forme de VM dans le cloud, en partie sous forme d'applications SaaS et en partie sous forme d'applications cloud nouvellement créées.

Quel que soit l'endroit où votre environnement est hébergé, l'intégration restera la pièce maîtresse qui relie votre entreprise. Le besoin d'intégration n'a fait qu'augmenter avec la prolifération des applications SaaS, des capteurs et appareils IoT et du développement d'applications mobiles, en plus du grand nombre d'applications de référence.

Votre logiciel d'intégration connecte vos données à travers tous les environnements, en chevauchant tous les domaines et en atteignant tous les points de terminaison. Lorsque votre logiciel commence à être hébergé en dehors de votre centre de données, l'intégration commence à s'étendre à l'ERM, au CRM et au mainframe sur site, aux environnements cloud et SaaS, aux appareils et capteurs périphériques et aux partenaires B2B. Très vite, vous ressentirez le besoin de moderniser votre logiciel d'intégration pour les mêmes raisons que vous avez migré vos autres solutions - besoin d'agilité, de fiabilité et de réduction des coûts opérationnels. Comme l'intégration n'apporte pas de valeur en soi, mais connecte des applications, votre organisation devra évaluer où résident les données importantes - en d'autres termes, où se trouve le centre de gravité de vos données.

La mission principale des logiciels d'intégration étant de libérer vos données en les connectant et en les transformant, vos charges de travail d'intégration doivent être plus proches de l'endroit où se trouvent vos volumes de données. Si la plupart d'entre elles sont encore sur site dans des ERP et des mainframes, le transfert de vos charges de travail d'intégration vers le cloud offrira les avantages opérationnels habituels, mais augmentera également la latence entre vos systèmes et rendra la topologie de votre réseau plus complexe.

D'autre part, si votre entreprise est déjà une grande utilisatrice de logiciels SaaS, tels que Salesforce ou Workday, et que vous exploitez des "data lakes" dans des hyperscalers (tels que AWS, Azure ou Google) pour stocker toutes les données analytiques pertinentes, votre centre de gravité se trouve alors en dehors de votre propre centre de données. Dans ce cas, la migration de vos charges de travail d'intégration vers le cloud améliorera considérablement la configuration et l'architecture globales de votre paysage logiciel.

Comme les données dans le monde actuel peuvent se trouver n'importe où - dans votre data center, chez un hyperscaler de votre choix ou dans des applications SaaS - il devient évident que l'intégration monolithique "taille unique" du passé ne convient pas à tous les cas d'usage. Au lieu de cela, vous commencerez à disperser l'architecture avec des flux d'intégration distincts en fonction des applications à connecter. Voici les options disponibles en prenant en compte cette nouvelle donne.

"Rester on-premise"

De nombreuses organisations ont initialement résolu le problème de l'intégration en adoptant des ESB ("Enterprise Service Bus") et des plateformes d'intégration, qui sont encore largement utilisées et qui, dans de nombreux cas, alimentent des applications critiques pour les organisations. Si les applications connectées se trouvent toujours dans votre datacenter, il n'est pas judicieux de déplacer vos charges de travail d'intégration ailleurs uniquement pour des raisons de coûts opérationnels, car le message remontera dans le cloud pour revenir ensuite dans votre datacenter.

"Réhéberger"

Si les systèmes qui sont intégrés sont déjà transférés dans le cloud, il est logique que vos workflows d'intégration soient également transférés. La façon la plus simple d'y parvenir est de réhéberger vos intégrations telles quelles. Il s'agit d'un transfert de votre architecture d'intégration vers des machines virtuelles hébergées en dehors de votre datacenter. Bien que cette approche vous apporte certains avantages opérationnels, vous ne bénéficierez pas de l'évolutivité et de la fiabilité du cloud, et vous devrez toujours exploiter le logiciel.

"Conteneuriser"

Un autre type de réhébergement qui peut vous permettre d'exploiter davantage le cloud est le reconditionnement du logiciel dans des conteneurs. Les conteneurs sont utilisés comme une distribution packagée plus standardisée qui contient toutes les dépendances nécessaires et qui est beaucoup plus légère qu'une VM. En reconditionnant simplement le logiciel en conteneur, vous n'obtiendrez pas l'évolutivité et la haute disponibilité, mais vous pourrez tirer parti de la mobilité du conteneur pour faciliter la migration - si un conteneur fonctionne dans votre datacenter, il fonctionnera de la même manière dans le cloud.

Le reconditionnement du logiciel n'est pas une tâche triviale qui se limite à une installation. Elle nécessitera une refonte complète de la façon dont vous construisez et exploitez une solution - d'un flux CI/CD différent à une nouvelle façon de surveiller et de résoudre les pannes.

"Refactoriser"

Le reconditionnement dans des conteneurs donne à votre logiciel de la mobilité et plus de fiabilité lors des déploiements, car toutes les dépendances et tous les outils sont mis à jour avec le code le plus récent. Cependant, les conteneurs en eux-mêmes ne vous offrent pas une solution flexible de déploiement sans interruption de service, ou un time to marker rapide pour les nouvelles idées.

Pour atteindre ces objectifs, vous devrez modifier non seulement la manière dont votre logiciel est packagé, mais aussi votre architecture - un logiciel monolithique ne peut pas répondre aux nouvelles exigences, il doit donc être scindé en plusieurs parties plus faciles à gérer qui peuvent fonctionner de manière indépendante sous forme de microservices.

Les ESB sont en pleine évolution, car ils sont considérés comme monolithiques, et les organisations ressentent le besoin de déployer des intégrations légères sous forme de microservices. Cela a conduit à l'émergence d'un runtime de microservices (MSR) qui peut être mis à l'échelle très rapidement pour répondre aux besoins de l'entreprise. Les MSR sont généralement déployés sous forme de conteneurs, mis à l'échelle à l'aide d'un orchestrateur de conteneurs tel que Kubernetes ou OpenShift, puis surveillés à l'aide d'outils open-source tels que Prometheus. Cette architecture repose sur les fondations du reconditionnement en conteneurs et s'accompagne d'exigences importantes pour vos pratiques DevOps - vous devrez automatiser entièrement le cycle de vie du logiciel: développement, build, test et déploiements. Le choix de cette option nécessite donc un savoir-faire spécifique et une bonne maturité dans les processus CI/CD au sein de votre équipe. Cette approche peut être considérée comme la plus difficile de toutes les options, en raison des défis technologiques et opérationnels auxquels votre organisation sera confrontée.

"Changer de plateforme (replatforming)"

Le "replatforming" consiste à exploiter la plateforme d'intégration en tant que service (iPaaS) pour vos charges de travail. Il s'agit d'une offre purement "cloud", qui facilite les intégrations "cloud to cloud" ou "SaaS to SaaS". En utilisant l'intégration en mode SaaS, vous pouvez totalement oublier l'aspect opérationnel de cette couche logicielle d'intégration - le logiciel sera automatiquement mis à jour et pourra évoluer en fonction de votre demande. C'est le choix naturel pour créer de nouvelles intégrations entre systèmes natifs du cloud et applications SaaS, et il offre un grand nombre de connecteurs et de modèles prêts à l'emploi pour ces besoins. Si vos applications sont déplacées vers le cloud, il est logique de créer de nouveaux flux d'intégration dans l'iPaaS pour remplacer votre ESB sur site.

Hybridation

Nous pensons que vos applications ne seront plus jamais hébergées dans un seul centre de données et que vous opterez toujours pour une approche d'intégration hybride en fonction de la criticité du logiciel ou des besoins d'innovation. Ici, les intégrations suivront votre architecture de données et se positionneront le plus proche possible des applications dans les différents scénarios d'hébergement. Au final, vous obtiendrez un mélange de toutes les options d'intégration mentionnées, qui fonctionneront ensemble de manière holistique.

Nous avons déjà abordé les raisons qui motivent la mise en place d'un logiciel de migration vers le cloud, l'orientation possible de vos applications, le rôle de l'intégration dans cette configuration et les possibilités de coexistence avec le reste de votre environnement. En tant que lecteur de cet article, vous avez probablement déjà entamé votre migration vers le cloud et vous vous demandez par où commencer en ce qui concerne la transformation de l'intégration. Nous pensons qu'il y a plusieurs aspects importants à prendre en compte avant de commencer à déplacer vos intégrations hors de votre datacenter. Pour chacun d'entre eux, vous devez répondre aux questions clés décrites ci-dessous. Il s'agit de l'auto-évaluation que tout le monde doit faire avant de définir des actions concrètes.

Vision - Vous devez savoir quels sont les moteurs de votre migration. Bien que cela puisse varier d'une entreprise à l'autre, il existe plusieurs motivations communes - Recherchez-vous une réduction des coûts ? Une plus grande agilité en situation de charge ? La continuité de l'activité et la fiabilité lors des opérations de maintenance ? Dans chacun de ces cas, recherchez les avantages à long terme et essayez de les aligner sur les objectifs métier de votre entreprise.

Évaluation - Dans quel délai espérez-vous atteindre vos objectifs ? Avez-vous effectué une analyse de votre paysage applicatif ? Avez-vous positionné votre centre de gravité ?

Planification - Un grand nombre de clients passent directement à cette phase en se contentant de suivre les dernières tendances technologiques. Une fois la vision et l'évaluation réalisées, vous aurez une idée claire des approches de migration les mieux adaptées à un certain nombre de flux d'intégration.

Exécution - Une fois que vous avez la vision et le plan pour la réaliser, vous devez vous assurer que vous disposez des compétences et du temps nécessaires pour mener cettetransformation. Il n'existe pas de trajectoire de migration parfaite ni de bouton magique permettant d'exécuter vos applications à partir d'un cloud doté d'une architecture moderne. Déterminez les meilleurs moyens d'atteindre vos objectifs métier et définissez des critères de réussite mesurables.

Quel que soit l'endroit où vous déplacez vos charges de travail d'intégration, la première étape consiste toujours à choisir soigneusement une stratégie d'API qui vous aidera à moderniser facilement l'environnement. Ensuite, en comprenant le "centre de gravité" de chaque charge de travail d'intégration, vous pouvez déterminer les options les plus adaptées. Nous vous recommandons de commencer par des gains rapides - le réhébergement des applications en l'état est une bonne option et vous permettra de vous faire une idée de ce que cela signifie de fonctionner dans le cloud. Vous pouvez suivre les coûts de fonctionnement et d'exploitation et surveiller les problèmes cachés qui pourraient apparaître - topologies de réseau, aspects juridiques concernant vos données, lacunes dans les connaissances au sein de votre organisation et bien d'autres encore.

L'étape suivante peut être le "replatforming", surtout si vous commencez à créer des intégrations entre de toutes nouvelles applications SaaS. webMethods.io simplifie la création de ces workflows avec une excellente expérience utilisateur et de nombreuses recettes prêtes à l'emploi pour une quantité de systèmes modernes.

Pendant ce temps, votre organisation peut progressivement acquérir les compétences nécessaires pour mettre en œuvre et déployer des microservices d'intégration dans un environnement d'orchestration de conteneurs.Comme vous finirez par avoir un grand nombre d'intégrations différentes, vous devrez vous préparer à gouverner toutes ces intégrations de manière évolutive.