En confiant la sécurité de leurs applications aux hébergeurs, les entreprises courent le risque de freiner leur transformation.
Galvanisées par les opportunités de la transformation digitale, les entreprises risquent de partir déployer de nouvelles applications dans le Cloud sans nécessairement prêter attention aux risques de dette technique. En laissant à un hébergeur le soin d’assurer la sécurité et la haute disponibilité de leurs nouveaux services, elles s’exposent en effet au danger de ne plus pouvoir le quitter facilement. Dès lors, elles seront contraintes de choisir entre un chantier de migration de plusieurs mois susceptible de casser leur dynamique de transformation, ou la fatalité de rester chez un prestataire qui n’offre plus le service le plus adéquat pour leurs besoins.
Mais dans un contexte où il devient primordial de faire preuve de réactivité pour trouver des relais de croissance et pérenniser de nouvelles activités, aucune de ces deux options n’est souhaitable. Heureusement, il existe une alternative : faire le choix dès le départ d’embarquer les fonctions de sécurité et de disponibilité dans les applications.
L’enjeu de la transformation digitale : proposer plus rapidement de nouveaux services
Selon une récente étude de F5, faire de l’informatique un centre de profits et non plus un centre de coûts correspond à l’esprit-même de la transformation digitale, pour les trois quarts des entreprises. Sur le modèle des AirBnB et autres services disruptifs, les entreprises souhaitent aujourd’hui créer de nouvelles applications qui vont leur permettre de gagner de nouvelles parts de marché et mieux servir leurs clients. Pour y parvenir, elles doivent changer leur façon de développer et de déployer ces applicatifs, car le maître-mot dans ce contexte est la réactivité : il faut savoir proposer rapidement des applications et leur ajouter tout aussi rapidement de nouvelles fonctions.
Le modèle qui avait cours jusqu’alors - définir des schémas directeurs, mettre au point toutes les fonctions, les tester, pour finalement livrer un applicatif au bout d’un an et demi - n’est plus envisageable. C’est pourquoi il est recommandé d’intégrer les cultures DevOps et « agiles ». Avec ces outils, il devient possible de livrer une nouvelle application en un mois, puis de l’enrichir chaque semaine. Dans ce schéma de fonctionnement, toute la production est automatisée, de sorte qu’il n’est plus besoin d’attendre après l’informatique pour configurer des ressources. Lorsqu’une application est terminée, elle est utilisable par tout le monde une heure plus tard.
L’autre modernisation consiste à ne plus nécessairement exécuter l’application dans le datacenter interne, mais à la lancer depuis un Cloud, ce qui évite de mobiliser encore des informaticiens pour aller connecter des serveurs et des réseaux. Dans un souci de gagner en flexibilité et sur le coût, telle application interne pour les métiers pourra être hébergée sur tel Cloud moins cher, tandis qu’une autre pour le public ira sur celui qui supporte les plus forts pics d’activité.
Tous les processus sont nouveaux et, de fait, les entreprises sont incitées à remplacer aussi leurs composants de sécurité et de haute disponibilité par ceux que proposent leurs hébergeurs. Et c’est bien tout le problème.
L’écueil des composants de sécurité et de disponibilité qui diffèrent d’un Cloud à l’autre
Mettre une application dans le Cloud revient à s’affranchir des remparts qui protégeaient la périphérie du datacenter. Cela signifie aussi qu’il faut repenser la manière dont les machines virtuelles qui embarquent les applications se répartissent la charge de travail. Que l’on aille chez AWS, Azure, Google ou autre hébergeur de Cloud public, chacun propose des composants adéquats mais qui demandent un effort de paramétrage et d’évaluation. Il est en effet peu probable qu’il corresponde automatiquement au niveau de service que l’on souhaite atteindre. Et, au final, on adaptera les applications spécifiquement à chaque offre. Et cet effort devra être fait pour chaque application qui fonctionne dans un Cloud différent.
C’est un paradoxe. Alors que l’entreprise crée de toutes nouvelles applications qui ne reposent sur rien d’existant et sont donc libres de paraître rapidement en Cloud, voilà que la migration des règles internes de sécurité et de disponibilité freine leur démarrage.
Il y a pire. Qui dit que, demain, l’entreprise souhaitera rester chez ce même hébergeur Cloud ? Peut-être qu’il changera ses conditions, augmentera ses tarifs. Peut-être qu’un concurrent plus intéressant émergera. Il faudra alors refaire cet effort de migration, ce qui coûtera de l’argent et du temps.
Utiliser des composants standard pour un niveau de service universel
Pour éviter cet écueil, les entreprises auraient tout intérêt à lier leurs applications dès le départ à des composants de sécurité et de disponibilité standards, puis à embarquer ces composants dans les applications pour qu’ils soient disponibles avec elles en Cloud. De cette manière, il n’y aura plus jamais à se demander si la sécurité va être impactée par un changement de prestataire. Les applications deviendront automatiquement portables d’une offre de Cloud à l’autre.
Ces composants standards existent : ce sont ceux qui servaient à définir le niveau de service des applications exécutées dans le datacenter. Leurs fournisseurs ont eux aussi embrassé la dynamique de la transformation digitale et ils proposent désormais des versions de leurs solutions adaptées au Cloud. Schématiquement, cela revient à accoler à chaque application les remparts et les interconnexions qui jusqu’ici étaient bâties pour le datacenter.
Le bénéfice supplémentaire de rationaliser les composants de sécurité, de répartition de charge, etc. est de simplifier la gouvernance des applications. La DSI, par exemple, pourra ainsi superviser de manière globale le niveau de service des applications et s’assurer qu’elles respectent de manière homogène les règles de disponibilité et d’accessibilité que l’entreprise s’est fixées.
Selon l’étude citée plus haut, les entreprises qui embrassent la transformation digitale ont en moyenne chacune déjà déployé 200 applications sur deux Clouds concurrents. Nous estimons que, d’ici à 2022, elles en déploieront dix fois plus en multipliant encore les hébergements pour satisfaire aux besoins de chacune. Il ne sera alors plus envisageable de mobiliser suffisamment de moyens pour réfléchir à la manière de les migrer d’un Cloud à l’autre.