Pourquoi les praticiens DevOps devraient-ils se soucier des architectures par application ?
Cette question implique la conclusion que vous devriez le faire.
Depuis des décennies, nous déployons les services applicatifs qui constituent une grande partie du pipeline de production sur des plates-formes partagées. Les services d'application tels que l'équilibrage de charge, les services de performances des applications, WAF et l'identité fédérée sont fournis par NetOps sur une infrastructure partagée, souvent sous la forme d'un contrôleur de distribution d'applications (ADC).
Mais le temps et la demande, ainsi que les architectures d’application émergentes comme les microservices, imposent des changements dans ce pipeline . Ces changements sont bénéfiques, tant pour NetOps que pour DevOps, car ils évoluent vers un modèle qui s’aligne plus étroitement sur les calendriers de déploiement et les pratiques opérationnelles telles que l’infrastructure en tant que code.
Certains services applicatifs restent fermement ancrés dans une infrastructure partagée. DNS. Défense contre les attaques DDoS volumétriques. Pare-feu réseau. Ces services sont par nature des services aux entreprises . Autrement dit, ils sont conçus pour protéger, défendre et servir l’entreprise. Et si ces services échouent ? Aucune productivité ni profit dans l’ensemble de l’entreprise.
Mais d’autres services d’application sont très affines avec les applications ; leurs configurations, API et services sont souvent configurés spécifiquement pour prendre en charge une seule application. Pas une architecture unique, mais une application unique.
La responsabilité de ces services se déplace de plus en plus vers les opérations d'application (DevOps) et l'implication des développeurs qui fournissent les applications. Et même si un modèle partagé peut (et fonctionne souvent) toujours fonctionner pour fournir les services d'application de livraison et de sécurité nécessaires, un modèle par application pour beaucoup d'entre eux est souhaitable pour plusieurs raisons.
Tout d’abord, un modèle par application résout proprement les conflits de calendrier de déploiement . Les entreprises sont souvent contraintes par des conflits d’infrastructure partagés en ce qui concerne la configuration et le déploiement des services d’application qu’elles prennent en charge. Une infrastructure partagée signifie des ressources partagées, ce qui augmente invariablement le risque d’un conflit de configurations. En éliminant cette possibilité, la résistance à des déploiements plus fréquents ou hors calendrier peut être atténuée. Après tout, si un service d’application est dédié à mon application et s’exécute sur sa propre plateforme avec ses propres ressources, le conflit est parfaitement résolu. Mon application, mon risque.
Deuxièmement, un modèle par application prend en charge les efforts d’automatisation émergents qui incluent la mise en pratique de méthodologies telles que l’infrastructure en tant que code. En consacrant des ressources et une plateforme à une seule application, la configuration inclut uniquement cette application. L’immuabilité peut être imposée et le risque d’entropie évité. En fait, je dirais ( et je l'ai fait récemment ) que vous ne pouvez pas créer correctement une infrastructure immuable sans une architecture par application. Cette approche permet l’inclusion dans un pipeline de déploiement continu qui s’étend au-delà de l’infrastructure d’application et dans « le réseau ». Fournir cette capacité signifie transférer la responsabilité de la configuration et de la gestion continue de NetOps à DevOps. La bonne nouvelle est qu’avec cette plus grande responsabilité vient un plus grand contrôle, car DevOps devient le « propriétaire » du service d’application et est habilité à mettre à niveau, corriger et redéployer selon ses propres conditions et calendriers.
Enfin, un modèle par application est immédiatement plus portable. Sans être lié à une plateforme partagée et s'appuyant presque exclusivement sur des artefacts de déploiement (configurations et modèles), la majeure partie du pipeline de production devient capable de migrer d'un cloud à un autre, sur site vers hors site, avec beaucoup moins de frictions et d'efforts. Cette liberté offre aux organisations la possibilité de choisir le meilleur cloud et le meilleur emplacement pour l’application en question sans être limitées par les coûts associés à la migration.
DevOps peut grandement bénéficier de l’encouragement de l’adoption d’une architecture par application pour les services d’application, à la fois sur site et dans le cloud public. Alors que NetOps est sous pression pour fournir un meilleur contrôle et une meilleure visibilité à d'autres domaines opérationnels, le moment serait venu de prendre une pizza et une bière et d'avoir une conversation avec vos homologues NetOps sur la possibilité de passer à la prise en charge d'une architecture par application de nouvelle génération centrée sur les applications.