Chez NGINX, nous parlons depuis plusieurs années de la nécessité de rendre les applications véritablement modernes et adaptatives : portables, cloud natives, résilientes, évolutives et faciles à mettre à jour. Plus récemment, deux concepts facilitant la création et la livraison d’applications modernes se sont imposés. Le premier est le Platform Ops, dans lequel une équipe plateforme à l’échelle de l’entreprise sélectionne, maintient, connecte et sécurise tous les outils dont les équipes de développement et DevOps ont besoin pour travailler. Le second est le décalage vers la gauche, qui consiste à intégrer aux applications des fonctions de sécurité, de mise en réseau et de supervision adaptées à la production, et ce dès les premières étapes du cycle de développement. Les développeurs assument ainsi davantage de responsabilités pour des fonctions qui relevaient auparavant des équipes ITOps, tout en bénéficiant d’un choix et d’une autonomie accrus quant à la manière précise de les mettre en œuvre.
Si cela semble prometteur, dans la pratique, il est difficile de mettre en œuvre les opérations de plateforme (Platform Ops) et de « décaler vers la gauche » les outils d’infrastructure et d’exploitation. D’une part, de plus en plus d’applications sont déployées de manière fortement distribuée, dans des environnements conteneurisés et à l’aide de l’un des moteurs d’orchestration Kubernetes, toujours plus nombreux. Les entreprises souhaitent également déployer leurs applications dans plusieurs environnements sans s’enliser dans les différences entre les clouds, ni entre les clouds et les environnements sur site.
Une « image de référence » pour les applications modernes
Comme il se doit, nos clients et notre communauté continuent de solliciter notre aide pour relever les défis auxquels ils sont confrontés. Ils veulent profiter de tous les avantages, mais assembler toutes les briques — sécurité, réseau, observabilité et suivi des performances, mise à l’échelle — demande un véritable travail. Rendre la plateforme ainsi obtenue suffisamment robuste pour les environnements de production exige encore davantage d’efforts. Ils se demandent : « Pourquoi n’existe-t-il pas d’“image de référence” pour les applications modernes, que nous pourrions déployer à partir d’un seul dépôt ? »
C’est une bonne question, et nous nous sommes donné pour défi d’y apporter une réponse satisfaisante. Nous avons d’abord reformulé la question en termes plus concrets. Selon nous, voici ce que nous demandent nos clients et notre communauté : « Pouvez-vous nous aider à intégrer différents produits logiciels dans un ensemble plus cohérent, à optimiser la pile afin de définir précisément les configurations et les paramètres appropriés, et ainsi nous épargner ce travail et ces difficultés ? Et pouvez-vous faciliter l’exécution de l’application dans différents clouds, sans avoir à apporter de modifications majeures à la configuration en raison des différences entre les services et les fonctionnalités sous-jacents ? »
Nous considérons qu’une solution répondant véritablement à ces questions profiterait à l’ensemble de la communauté — et pas seulement à nos partenaires au sein de centaines d’entreprises et chez tous les grands fournisseurs de cloud —, ce qui constituerait une véritable réussite sans perdant. Idéalement, cette solution ne serait pas un simple « jouet », mais un code robuste, testé et prêt à être déployé dans des applications de production exécutées dans des environnements Kubernetes. Et, franchement, nous voulons que tout le monde puisse récupérer librement notre travail directement sur GitHub.
Pour aller droit au but, nous annonçons aujourd’hui, à l’occasion de NGINX Sprint 2.0, le lancement de notre solution : la première version de la Modern Apps Reference Architecture (MARA), une architecture et un modèle de déploiement open source pour les applications modernes. Nous espérons qu’elle vous plaira, que vous l’utiliserez, vous l’approprierez et, mieux encore, que vous la modifierez ou créerez un fork pour l’améliorer ou l’adapter à vos besoins. Cet article présente ce que nous avons conçu et son fonctionnement.
L’architecture de référence NGINX pour les applications modernes
Définir les applications adaptatives modernes
Commençons par définir l’application moderne et adaptative idéale. Elle peut être composée de microservices, être conteneurisée et respecter les principes de conception cloud native (faible couplage, facilité de mise à l’échelle, indépendance vis-à-vis de l’infrastructure), mais ce n’est pas une obligation. L’un des principes fondamentaux des applications modernes consiste à concevoir leur architecture spécifiquement pour tirer parti de l’abstraction de l’infrastructure. Cette définition est simple, mais importante, car elle établit le modèle de base de toutes les architectures de référence.
Les piliers essentiels d’une architecture d’application moderne sont la portabilité, l’évolutivité, la résilience et l’agilité.
- Portabilité – L’application peut être facilement déployée sur différents types d’appareils et d’infrastructures, dans des clouds publics et sur site.
- Évolutivité – L’application peut rapidement et facilement augmenter ou réduire sa capacité afin de s’adapter aux pics ou aux baisses de la demande, partout dans le monde.
- Résilience – L’application peut basculer sans interruption vers des clusters nouvellement créés ou des environnements virtuels situés dans différentes régions de disponibilité, différents clouds ou centres de données.
- Agilité – L’application peut être rapidement mise à jour grâce à des pipelines CI/CD automatisés ; dans l’univers des applications modernes, cela implique également un rythme de développement plus soutenu et des déploiements de code plus fréquents.
Conception de notre architecture de référence
Nous souhaitions créer une plateforme répondant aux exigences fondamentales de notre définition des applications modernes et de notre modèle de déploiement. Au-delà des objectifs techniques, nous voulions illustrer les principes modernes de conception d’applications et encourager notre communauté à effectuer ses déploiements sur Kubernetes. Et oui, nous voulions proposer du code « réutilisable » que les équipes de développement, DevOps et Platform Ops pourraient tester, modifier et améliorer. En bref, nous voulions proposer :
- Une architecture Kubernetes facile à déployer, prête pour la production et qui n’a rien d’un jouet
- Une plateforme qui met en avant le fonctionnement des produits partenaires sur Kubernetes
- Un bouton permettant de compiler et de déployer facilement un contrôleur Ingress Kubernetes
- Un environnement de test pour les futures intégrations de produits et de partenaires
- Un framework de déploiement modulaire
- Un dépôt unique de code open source pour faciliter sa découverte et son adoption
Voici les choix de conception et de partenariat que nous avons faits pour la première version de la plateforme (pour découvrir nos projets concernant la prochaine version, consultez « Bien plus d’intégrations et davantage de flexibilité dans la version 2 »). Nous sommes convaincus qu’il est essentiel que notre application de référence soit ouverte aux partenaires afin de favoriser l’engagement de ces derniers comme celui de la communauté.
- Développement open source – https://github.com/nginxinc/kic-reference-architectures/ ; nous avons créé ce dépôt en collaboration avec la communauté NGINX/F5
- Cible de déploiement – Amazon Elastic Kubernetes Service (EKS)
- Automatisation de l’infrastructure en tant que code – Python et Pulumi, qui prend en charge les configurations Terraform et les scripts d’automatisation écrits dans la quasi-totalité des langages de programmation courants
- Image de l'Ingress Controller – NGINX Plus précompilée pour les abonnés, NGINX Open Source précompilée sur DockerHub, et l'une ou l'autre version compilée à partir du code source
- Gestion des journaux (stockage et analyse) – Elastic, car cette solution est très populaire auprès de nos utilisateurs
- Surveillance des performances et tableaux de bord – Prometheus et Grafana
- Développement continu (CD) – Spinnaker
- TLS – cert-manager
- Application de démonstration – Google Bank of Anthos
Comment le code est déployé
Pour installer et déployer l’application d’exemple, exécutez une seule commande afin de lancer le script de démarrage. Les projets Pulumi suivants sont alors exécutés dans l’ordre indiqué. Chaque nom de projet correspond à un nom de répertoire relatif au répertoire racine du dépôt. Pour plus de détails, consultez le fichier README.
vpc - Defines and installs VPC and subnets to use with EKS └─eks - Deploys EKS
└─ecr - Configures ECR for use in EKS cluster
└─kic-image-build - Builds new NGINX Ingress Controller image
└─kic-image-push - Pushes image built in previous step to ECR
└─kic-helm-chart - Deploys NGINX Ingress Controller to EKS
cluster
└─logstore - Deploys Elastic log store to EKS cluster
└─logagent - Deploys Elastic (filebeat) logging agent to
EKS cluster
└─certmgr - Deploys cert-manager.io Helm chart to EKS
cluster
└─anthos - Deploys Bank of Anthos application to EKS
clusterBien plus d’intégrations et davantage de flexibilité dans la version 2
Nous sommes conscients que notre première initiative ne propose peut-être pas toutes les intégrations dont vous avez besoin pour votre environnement Kubernetes. L’approche Platform Ops consiste à offrir un choix judicieux, mais pas illimité. Afin de permettre aux équipes Platform Ops, DevOps et de développement de tester plus facilement notre nouvelle plateforme de référence et, éventuellement, de l’adopter, nous prévoyons de nombreuses améliorations à court terme, notamment :
- Mettre en place des environnements Kubernetes sur Digital Ocean, OpenShift, Rancher, vSphere et d’autres plateformes
- Intégrez NGINX Controller> pour gérer et surveiller NGINX Plus Ingress Controller[Note de la rédaction – NGINX Controller s’appelle désormais F5 NGINX Management Suite.]
- Fournir une configuration prête à l’emploi pour NGINX App Protect
- Intégration aux produits et services F5 tels que BIG‑IP, Cloud Services et Volterra
- Intégration à NGINX Service Mesh et à Aspen Mesh basé sur Istio
- Intégration native avec Terraform et d’autres outils d’automatisation
- Prendre en charge d’autres options de CI/CD
- Déployer des clusters distincts ou multiples pour les services d’infrastructure et d’application
Nous espérons que notre travail pourra servir de cadre à d’autres plateformes de référence et de point de départ « réutilisable » pour développer toutes sortes d’applications modernes différenciées. Kubernetes étant un mécanisme extrêmement puissant, tant pour créer des applications modernes que pour donner davantage d’autonomie aux équipes chargées des opérations des plateformes et favoriser une culture shift-left, plus notre architecture de référence sera étendue et modulaire, mieux ce sera. Nous sommes impatients de savoir ce que vous, la communauté, pensez de notre travail et, surtout, de découvrir ce que vous allez créer à partir de celui-ci.
Premiers pas avec l’architecture de référence
Téléchargez notre plateforme de référence et essayez-la. Dites-nous ce que vous en pensez et ce que vous aimeriez nous voir développer ensuite. Les pull requests sont plus que bienvenues. Nous avons hâte de collaborer avec vous sur la prochaine génération d’applications modernes, adaptables et « réutilisables », qui contribuent en retour à la communauté et à l’ensemble des développeurs.
Articles connexes
Cet article fait partie d’une série. À mesure que nous enrichissons les fonctionnalités de MARA, nous en publions les détails sur le blog :
- Une nouvelle architecture de référence open source pour les applications modernes (cet article)
- Intégration d’OpenTelemetry à l’architecture de référence des applications modernes – Rapport d’avancement
- MARA : désormais disponible sur un poste de travail près de chez vous
- Annonce de la version 1.0.0 de l’architecture de référence NGINX pour les applications modernes
À propos de l’auteur
Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.