Cohérence. Dans le monde de la technologie, nous utilisons ce terme pour désigner le caractère équivalent d’un élément. Un élément est cohérent s’il se comporte de la même manière au fil du temps ou dans différentes conditions. La cohérence reste problématique pour les entreprises évoluant dans un environnement multicloud. Selon notre rapport 2019 sur l’état des services applicatifs, cela concerne la plupart d’entre vous (87 %).
De toute évidence, les écarts de taux de déploiement des services applicatifs entre les centres de données et le cloud s’expliquent par une cause simple : le manque de cohérence dans le déploiement de ces services.
Mais ce n’est pas la seule cause de ce manque de cohérence. D’après la même enquête, de nombreuses personnes déploient effectivement des services applicatifs sur site et dans le cloud public, mais peinent encore à assurer leur cohérence, notamment en matière de sécurité.
Cela nécessite d’examiner plus en profondeur ce que signifie la « cohérence », car je soupçonne qu’une partie du problème tient au fait que l’on ne reconnaît pas qu’il existe deux niveaux distincts de cohérence et que tous deux sont importants.
Les services applicatifs ne sont pas des contrôleurs de mise à disposition d’applications
Au cœur de cette réflexion sur la cohérence se trouve la différence entre un contrôleur de mise à disposition d’applications (ADC) et un service applicatif.
L’ADC est une plateforme qui fournit des services applicatifs. Cet ADC constitue un système à part entière, tout comme Kubernetes. Kubernetes est une plateforme permettant de déployer et d’exploiter des conteneurs. Un ADC est une plateforme permettant de déployer et d’exploiter des services applicatifs.
C’est important, car les plateformes (ou les systèmes, si vous préférez) reposent sur une notion de cohérence distincte de celle des « éléments » qu’elles déploient et exploitent. La cohérence se situe au niveau opérationnel, c’est-à-dire au niveau de la gestion et de l’exploitation de la plateforme et des services applicatifs qu’elle fournit.
Cohérence fonctionnelle
Cela se distingue nettement de la cohérence fonctionnelle, qui est assurée par chaque service applicatif. La cohérence fonctionnelle englobe les capacités du service applicatif. C’est généralement à cela que l’on fait référence lorsque l’on évoque les difficultés liées à la cohérence multicloud, car c’est l’aspect le plus visible.
La cohérence fonctionnelle est particulièrement difficile à garantir lors du déploiement de services applicatifs provenant de différents fournisseurs. Un WAF ou un service anti-bot proposé par un fournisseur n’est pas nécessairement équivalent, sur le plan fonctionnel, à celui d’un autre fournisseur.
L’une des raisons pour lesquelles les entreprises peinent à assurer la cohérence de leur environnement multicloud n’est pas qu’elles ne déploient pas de services applicatifs dans le cloud, mais plutôt qu’elles déploient différents services applicatifs dont les capacités fonctionnelles sont incohérentes. Une standardisation fondée sur l’équivalence fonctionnelle les aidera à atteindre la cohérence qu’elles ont tant de mal à obtenir.
Cohérence opérationnelle
La deuxième source d’incohérence, moins souvent évoquée, se situe au niveau de la plateforme. Pour un grand nombre d’entreprises, il s’agit de l’ADC. Lors de leur migration vers le cloud public, de nombreuses organisations choisissent (intentionnellement ou non) d’utiliser des solutions cloud natives pour les services applicatifs.
Cela introduit immédiatement une incohérence opérationnelle au niveau de la plateforme. La manière dont vous provisionnez, intégrez et exploitez ces services applicatifs relève des opérations et génère une dette opérationnelle dès que vous vous connectez à la première API.
Vous n’utilisez probablement pas de services applicatifs cloud natifs sur site. Cela signifie que vous devez désormais gérer deux plateformes de services applicatifs différentes. Leurs méthodes de gestion, d’analyse, de supervision, tout est différent.
C’est comme utiliser deux ADC différents sur site. Si certaines très grandes entreprises parviennent à fonctionner ainsi, nous avons constaté au fil des ans que la plupart des organisations se standardisent sur une plateforme ADC unique. La cohérence opérationnelle et la possibilité de reproduire les politiques de services applicatifs sur l’ensemble des applications ont largement motivé cette décision.
Mais lors de leur migration vers le cloud, certains ont oublié pourquoi ils avaient initialement standardisé leur infrastructure sur une plateforme ADC : pour garantir la cohérence opérationnelle et faciliter le support. L’introduction de plateformes supplémentaires alourdit nécessairement la charge des équipes d’exploitation et compromet la recherche de cohérence.
La cohérence exige une standardisation
La standardisation peut être un terme inquiétant pour certaines personnes qui estiment qu’elle étouffe l’innovation. Mais une situation où chacun fait ce qu’il veut est encore plus préoccupante : si elle peut favoriser l’innovation, elle n’est pas viable à long terme et crée un environnement opérationnel chaotique.
Alors que l’informatique est sous pression pour apporter de la valeur à l’entreprise, augmenter les effectifs opérationnels afin de maintenir plusieurs plateformes et une multitude de services applicatifs semble aller à l’encontre de l’objectif visant à assurer une cohérence multicloud.
La standardisation, en particulier au niveau de la couche opérationnelle, est un élément clé de l’innovation, car elle évite au personnel de devoir se concentrer sur l’exploitation des plateformes et favorise plutôt la collaboration en matière de politiques et d’architecture.
En garantissant une cohérence à la fois opérationnelle et fonctionnelle entre les différentes plateformes, les organisations peuvent obtenir la cohérence des politiques souhaitée sans dépasser leur budget.
À 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.