Deux modèles distincts de « passage au cloud » ont émergé. Le premier, le plus évident, est l’approche native. Par « native », on entend une application nouvelle, soit développée de zéro, soit réécrite. L’approche native encourage à se concentrer étroitement sur l’application, en partant du principe qu’une fois celle-ci adaptée au cloud, les performances et la sécurité dépendent du déploiement des services cloud appropriés. Ce n’est pas tout à fait vrai, mais c’est suffisamment proche de la réalité pour que nous nous en contentions pour l’instant.
La deuxième approche est le « lift and shift », qui consiste exactement en ce que son nom suggère : extraire une application existante de l’infrastructure de son centre de données et la transférer vers le cloud, où elle repose alors sur une infrastructure cloud. Toutefois, dans ce modèle, l’attention ne peut pas porter uniquement sur l’application, car celle-ci présente également des dépendances qu’il faut prendre en compte. Cela inclut d’autres composants architecturaux couvrant les services applicatifs et d’infrastructure.
Cela a récemment été mis en évidence dans un rapport de Cloud Velox, qui s’intéresse à l’utilisation du cloud comme centre de données secondaire. Ce rapport relevait notamment le constat suivant :
“Un stéréotype persiste selon lequel les professionnels de l’informatique seraient très majoritairement opposés au cloud en raison de préoccupations liées à la sécurité et au réseau. Pourtant, 55 % des personnes interrogées ont déclaré qu’elles adopteraient la reprise après sinistre dans le cloud à condition de pouvoir étendre au cloud les contrôles de sécurité et de réseau de leur infrastructure sur site. Cela laisse entendre que les professionnels de l’informatique ne sont pas opposés au cloud : ils souhaitent simplement y disposer de contrôles équivalents. ”
Cloud Velox se concentrait sur la reprise après sinistre, mais il semble que la problématique générale s’applique plus largement. La migration des applications vers le cloud est bien plus acceptable si l’on peut également y transférer les contrôles (services) réseau et de sécurité.
En résumé, si vous migrez une application qui a été optimisée au fil des années grâce à des services applicatifs hébergés sur le réseau, mais sans emporter ces services, vous perdez le bénéfice de ces optimisations. Il existe cette idée reçue selon laquelle le simple fait d’être dans le cloud améliore les performances, car l’application se trouve physiquement plus près du réseau fédérateur d’Internet et des utilisateurs qui interagissent avec elle. C’est en partie vrai, mais pas totalement. En effet, les performances d’une application ne dépendent pas principalement de la latence du réseau. En réalité, bon nombre des inefficacités qui nuisent aux performances d’une application sont liées à la taille et à la composition du contenu, à une mauvaise gestion des connexions et à l’impossibilité de régler correctement la pile réseau en fonction des besoins spécifiques de l’application.
Les préoccupations en matière de sécurité ne disparaissent pas non plus comme par magie lorsque vous migrez une application vers le cloud sans la modifier. Si l’application était vulnérable aux attaques XSS ou aux injections SQL dans le centre de données, vous pouvez être certain qu’elle le restera une fois transférée dans le cloud*. Si ces risques étaient traités dans le centre de données au moyen d’un pare-feu applicatif web ou de dispositifs de sécurité déployés sur un proxy programmable, il est préférable de migrer également le pare-feu applicatif et le proxy avec l’application.
La possibilité de « migrer en l’état » une architecture, plutôt que la seule application, est l’une des raisons de la popularité croissante des offres de cloud en colocation. Celles-ci permettent également de réaliser des économies par rapport à une infrastructure sur site et offrent un meilleur contrôle que le cloud, mais l’un de leurs principaux atouts reste sans aucun doute la possibilité de migrer en l’état une architecture complète et de profiter du « cloud voisin ». Les entreprises souhaitent parfois rapprocher la source de données des applications déployées dans le cloud afin d’éviter la latence préjudiciable aux performances qu’entraîneraient des allers-retours jusqu’au centre de données de l’entreprise. Elles veulent parfois pouvoir faire évoluer horizontalement le front-end sans perturber le back-end (et, là encore, éviter la latence). Le recours à un fournisseur de cloud en colocation le leur permet, car le cloud se trouve juste à côté et est accessible via une interconnexion très rapide, digne d’un centre de données.
Quelle que soit l’approche adoptée pour le cloud (colocation ou cloud public), la clé d’une migration réussie vers le cloud consiste à transférer autant d’éléments de l’architecture que possible. Indépendamment des options de services cloud, il est important de maintenir les services applicatifs critiques avec leur application tout au long de la transition afin que le changement d’emplacement ne compromette ni les performances ni la sécurité.
*Également appelée loi de Hoff qui, bien qu’elle ne soit pas véritablement une loi, reste une observation aussi juste aujourd’hui que lorsqu’elle a été formulée pour la première fois en 2009
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.