Pourquoi les professionnels du DevOps devraient-ils s’intéresser aux architectures par application ?

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Cette question sous-entend que vous devriez le faire.

Depuis des décennies, nous déployons sur des plateformes partagées les services applicatifs qui constituent une grande partie de la chaîne de production. Les services applicatifs tels que l’équilibrage de charge, les services de performance applicative, le pare-feu applicatif (WAF) et l’identité fédérée sont fournis par les équipes NetOps sur une infrastructure partagée, souvent sous la forme d’un contrôleur de mise à disposition d’applications (ADC).

Mais le temps et la demande, ainsi que l’émergence d’architectures applicatives telles que les microservices, imposent des changements dans ce pipeline. Ces changements sont bénéfiques tant pour les équipes NetOps que DevOps, car elles évoluent vers un modèle davantage en phase avec les calendriers de déploiement et les pratiques opérationnelles telles que l’infrastructure en tant que code.

Certains services applicatifs restent solidement ancrés dans une infrastructure partagée. Le DNS. La protection contre les attaques DDoS volumétriques. Les pare-feu réseau. Ces services sont par nature des services d’entreprise . Autrement dit, ils sont conçus pour protéger, défendre et servir l’entreprise. Si ces services tombent en panne, c’est toute l’entreprise qui se retrouve privée de productivité et de bénéfices.

Mais d’autres services applicatifs sont étroitement liés à une application donnée ; leurs configurations, leurs API et leurs services sont souvent paramétrés spécifiquement pour prendre en charge une seule application. Non pas une architecture unique, mais une application unique.

La responsabilité de ces services se déplace de plus en plus en amont, vers les équipes chargées de l’exploitation des applications (DevOps), et implique davantage les développeurs qui fournissent ces applications. Et même si un modèle partagé peut encore fonctionner — et c’est souvent le cas — pour fournir les services nécessaires à la mise à disposition et à la sécurité des applications, un modèle propre à chaque application est préférable pour bon nombre de ces services, et ce, pour plusieurs raisons.

Tout d’abord, un modèle par application résout efficacement les conflits de calendrier de déploiement. Les entreprises sont souvent confrontées à des conflits liés à l’infrastructure partagée lors de la configuration et du déploiement des services applicatifs qu’elle prend en charge. Une infrastructure partagée implique des ressources partagées, ce qui entraîne inévitablement un risque de conflit entre les configurations. En éliminant cette possibilité, il est possible de réduire les réticences à effectuer des déploiements plus fréquents ou hors calendrier. Après tout, si un service applicatif est dédié à mon application et s’exécute sur sa propre plateforme avec ses propres ressources, le conflit est résolu efficacement. Mon application, mon risque.

Deuxièmement, un modèle par application soutient les nouvelles initiatives d’automatisation, notamment la mise en pratique de méthodologies telles que l’infrastructure en tant que code. En dédiant les ressources et la plateforme à une seule application, la configuration ne concerne que cette application. L’immutabilité peut ainsi être garantie et le risque d’entropie évité. En fait, je dirais (comme je l’ai fait récemment) qu’il est impossible de mettre correctement en œuvre une infrastructure immuable sans une architecture par application. Cette approche permet de l’intégrer à un pipeline de déploiement continu qui s’étend au-delà de l’infrastructure applicative jusqu’au « réseau ». La mise à disposition de cette capacité implique de transférer la responsabilité de la configuration et de la gestion continue des NetOps aux DevOps. La bonne nouvelle, c’est que cette responsabilité accrue s’accompagne d’un contrôle accru : les DevOps deviennent « propriétaires » du service applicatif et peuvent effectuer les mises à niveau et les correctifs, ainsi que le redéployer selon leurs propres conditions et calendriers.

Enfin, un modèle par application est d’emblée plus portable. Comme il n’est pas lié à une plateforme partagée et repose presque exclusivement sur des artefacts de déploiement (configurations et modèles), l’essentiel du pipeline de production peut migrer d’un cloud à un autre, ou d’un environnement sur site vers un environnement hors site, avec beaucoup moins de difficultés et d’efforts. Cette liberté permet aux organisations de choisir le cloud et l’emplacement les mieux adaptés à l’application concernée, sans être limitées par les coûts liés à la migration.

Le DevOps peut tirer de grands avantages de l’adoption d’une architecture par application pour les services applicatifs, aussi bien sur site que dans le cloud public. Alors que les équipes NetOps sont soumises à une pression croissante pour offrir davantage de contrôle et de visibilité aux autres domaines opérationnels, le moment est bien choisi pour partager une pizza et quelques bières avec vos homologues NetOps et discuter de la mise en place d’une architecture de nouvelle génération, centrée sur les applications et dédiée à chacune d’elles.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie