L’ironie est savoureuse avec le mot à la mode du jour : « cloud-native ».
La première chose à noter est que le cloud natif, malgré son nom, ne nécessite pas de cloud. Étonnant, n’est-ce pas ? Ce nom vient de l’approche architecturale qui consiste à créer une application reposant sur une infrastructure et conçue autour des concepts du cloud : élasticité, économies d’échelle et informatique distribuée. Il est indéniable que le cloud computing a étendu ces concepts à tous les aspects de la mise à disposition des applications : de l’architecture applicative à l’automatisation, de l’intégration basée sur des API à l’infrastructure. Le cloud computing a changé notre façon de développer, de créer et de déployer des applications. Les applications nées dans le cloud public en ont naturellement repris bon nombre de dépendances et de caractéristiques. Ce nom reflète donc fidèlement l’étymologie de ce style architectural.
Il existe également un lien indéniable entre les applications cloud natives et les conteneurs. Cela les distingue en soi des applications nées dans le cloud, qui s’appuient principalement sur des machines virtuelles et des services cloud natifs pour atteindre des objectifs similaires. Les applications cloud natives et les conteneurs sont étroitement liés, car les orchestrateurs de conteneurs associés (Kubernetes) constituent le moyen le plus simple et le plus répandu de coupler les applications à l’infrastructure nécessaire pour assurer l’élasticité et, grâce à celle-ci, réaliser les économies d’échelle souhaitées.
Dans une application cloud native, les composants sont décomposés en unités élémentaires afin de permettre des économies d’échelle. C’est pourquoi le cloud native et les conteneurs sont presque indissociables. Il faut pouvoir mettre à l’échelle, à la demande, uniquement les fonctions sollicitées. Ce type de partitionnement fonctionnel et élastique des applications repose traditionnellement sur des architectures utilisant le routage de couche 7 (HTTP), et le cloud native ne fait pas exception. Ces mêmes principes s’appliquent aux applications modernes, qui utilisent généralement un contrôleur d’entrée (un service applicatif d’infrastructure) chargé de distribuer les requêtes entrantes vers l’instance conteneurisée appropriée d’un composant applicatif.
Ce partitionnement est souvent effectué au niveau des API, où les URI sont associées à des appels d’API, eux-mêmes associés à des Services de conteneurs spécifiques. Le contrôleur d’entrée dirige les requêtes vers le Service de conteneurs approprié, qui les répartit à son tour entre un ensemble d’instances du composant ou de l’application. Il s’agit d’une architecture à deux niveaux, dans laquelle le contrôleur d’entrée de couche 7 (HTTP) transmet les requêtes à un équilibreur de charge classique (POLB), qui se charge de leur acheminement et de leur traitement.
De plus, nous dépendons des registres de services qui constituent, en coulisses, un autre service applicatif d’infrastructure nécessaire pour assurer l’élasticité des applications cloud natives. Sans mécanisme de découverte de services, l’équilibrage de charge et le contrôle des flux entrants ne peuvent pas fonctionner, ce qui rend l’application inutilisable.
Cette relation — entre les composants, les services, les registres de services, les répartiteurs de charge et le contrôle des flux entrants — incarne les principes des applications cloud natives. Les composants applicatifs et l’infrastructure sont étroitement liés sans pour autant être fortement couplés. Les composants ne peuvent réaliser d’économies d’échelle ni être distribués entre différents environnements sans les capacités de routage de couche 7 et de répartition de charge classique. La dépendance entre l’infrastructure et les applications est bien réelle et essentielle à l’impératif commercial de déployer des applications.
Rien de tout cela ne dépend d’un quelconque environnement de cloud computing ni n’en nécessite un. Une application cloud native peut être — et est souvent — déployée de manière autonome. En fait, si l’on examine les données relatives aux conteneurs et à l’endroit où ils s’exécutent, on constate que les environnements « sur site » restent plus répandus que les environnements de cloud public.
S’il est certes possible de déployer des conteneurs sur un cloud privé (sur site), nos propres études continuent de montrer que le cloud privé sur site reste le modèle de cloud le plus utilisé. Plus des trois quarts (79 %) des personnes interrogées dans le cadre de notre étude « État des services applicatifs 2019 » disposent d’applications dans un cloud privé sur site, tandis que le cloud public peine toujours à franchir le seuil de la majorité, avec 45 %.
Les applications cloud natives reposent sur une architecture en plein essor, dont la croissance se poursuivra assurément au cours des cinq prochaines années. Comprendre leur relation avec les services applicatifs d’infrastructure, ainsi que leur dépendance à leur égard, est essentiel pour déployer et sécuriser efficacement ces applications modernes.
À 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.