Une nouvelle architecture de référence pour les applications modernes Open Source

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 sont apparus pour faciliter la création et la diffusion d’applications modernes. Le premier est Platform Ops , où une équipe de plateforme au niveau de l’entreprise organise, maintient, connecte et sécurise tous les outils dont les équipes de développement et DevOps ont besoin pour faire leur travail. La deuxième approche est le déplacement vers la gauche , ce qui signifie intégrer la sécurité, la mise en réseau et la surveillance de niveau production dans les applications dès les premières étapes du cycle de développement. Les développeurs se retrouvent avec davantage de responsabilités pour les fonctions qui appartenaient auparavant à l'ITOps, mais disposent en même temps de plus de choix et d'une plus grande indépendance quant à la manière exacte dont ils implémentent ces fonctions.

Même si cela semble bien, en réalité, il est difficile de mettre en œuvre Platform Ops et de « déplacer vers la gauche » l’infrastructure et les outils d’exploitation. D’une part, de plus en plus d’applications sont déployées de manière hautement distribuée, dans des environnements conteneurisés et en utilisant l’un des nombres croissants de moteurs d’orchestration Kubernetes. Les entreprises souhaitent également déployer leurs applications dans plusieurs environnements sans se laisser embourber par les différences entre les clouds et 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 demander notre aide pour relever les défis auxquels ils sont confrontés. Ils veulent tout le meilleur, mais assembler toutes les pièces (sécurité, mise en réseau, observabilité et surveillance des performances, mise à l’échelle) nécessite un réel travail. Rendre la plateforme résultante suffisamment robuste pour les environnements de production nécessite encore plus de travail. Ils se demandent : « Pourquoi n’existe-t-il pas d’« image de référence » pour les applications modernes que nous pouvons lancer à partir d’un seul référentiel ? »

C’est une bonne question, et nous avons relevé le défi de trouver une bonne réponse. Tout d’abord, nous avons reformulé la question en termes plus concrets. Nous pensons que nos clients et notre communauté se posent cette question : « Pouvez-vous nous aider à intégrer différents produits logiciels dans un ensemble plus cohérent, à ajuster la pile pour définir les configurations et les paramètres appropriés, et à nous épargner du travail et des ennuis ? Et pouvez-vous faciliter l’exécution de l’application dans différents clouds sans avoir à apporter des modifications de configuration majeures en raison de différences dans les services et fonctionnalités sous-jacents ? »

Nous considérons qu’une solution qui répond réellement à ces questions est bénéfique pour l’ensemble de la communauté – et pas seulement pour nos partenaires dans des centaines d’entreprises et tous les principaux fournisseurs de cloud – une véritable victoire à somme non nulle . Idéalement, la solution n’est pas un « jouet », mais un code solide, testé et prêt à être déployé dans des applications de production en direct exécutées dans des environnements Kubernetes. Et, franchement, nous voulons que n’importe qui puisse voler notre travail directement depuis GitHub.

Pour aller droit au but, aujourd'hui, lors du NGINX Sprint 2.0, nous annonçons le lancement de notre solution : la première itération de la Modern Apps Reference Architecture (MARA), une architecture open source et un modèle de déploiement pour les applications modernes. Nous espérons que vous l'aimerez, l'utiliserez, le volerez et, mieux encore, le modifierez ou le forkerez pour l'améliorer ou le personnaliser. Cet article décrit ce que nous avons construit et comment cela fonctionne.

Définition des applications adaptatives modernes

Commençons par définir l’application moderne et adaptative idéale. Il peut être composé de microservices, être conteneurisé et adhérer aux principes de conception cloud natifs (faiblement couplé, facile à mettre à l’échelle, non lié à l’infrastructure) – mais ce n’est pas obligatoire. Une partie de l’éthique des applications modernes consiste à concevoir une architecture spécifiquement conçue pour tirer parti de l’abstraction de l’infrastructure. Cette définition est simple mais importante car elle établit le modèle de base pour toutes les architectures de référence.

Les piliers clés d’une architecture d’application moderne incluent la portabilité, l’évolutivité, la résilience et l’agilité.

• Portabilité – Il est facile de déployer l’application sur plusieurs types d’appareils et d’infrastructures, sur des clouds publics et sur site.
• Évolutivité – L’application peut évoluer rapidement et de manière transparente vers le haut ou vers le bas pour s’adapter aux pics ou aux réductions de la demande, partout dans le monde.
• Résilience – L’application peut basculer en toute élégance vers des clusters ou des environnements virtuels nouvellement créés dans différentes régions de disponibilité, clouds ou centres de données.
• Agilité – L'application peut être rapidement mise à jour via des pipelines CI/CD automatisés ; dans le monde des applications modernes, cela implique également une vitesse de code plus élevée et des push de code plus fréquents.

Concevoir notre architecture de référence

Nous voulions créer une plateforme qui réponde aux exigences de base de notre modèle de définition et de déploiement d'applications modernes. Outre les objectifs techniques, nous souhaitions illustrer les principes de conception d’applications modernes et encourager notre communauté à se déployer sur Kubernetes. Et oui, nous voulions proposer du code « volable » avec lequel les développeurs, les équipes DevOps et Platform Ops peuvent jouer, modifier et améliorer. En bref, nous souhaitions offrir :

• Une architecture Kubernetes facilement déployable et prête pour la production qui n’est pas un jouet
• Une plateforme qui met en évidence le fonctionnement des produits partenaires sur Kubernetes
• Un bouton poussoir pour faciliter la création et le déploiement d'un contrôleur d'entrée Kubernetes
• Un environnement de test pour les futures intégrations de produits et d'alliances
• Un cadre de déploiement enfichable
• Un référentiel unique de code open source pour simplifier la découverte et l'adoption

Voici les choix de conception et de partenariat que nous avons faits pour la première version de la plateforme (pour nos plans pour la prochaine version, voir Beaucoup plus d'intégrations et plus de flexibilité dans la version 2 ). Nous sommes convaincus que rendre notre application de référence inclusive pour les partenaires est essentiel pour stimuler l’engagement des partenaires et de la communauté.

• Développement open source – https://github.com/nginxinc/kic-reference-architectures/ ; nous avons construit le 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 accepte les recettes Terraform et les scripts d'automatisation de presque tous les langages de codage courants
• Image du contrôleur d'entrée - NGINX Plus pré-intégré pour les abonnés, NGINX Open Source pré-intégré sur DockerHub et l'une ou l'autre version créée à partir de la source
• Gestion des logs (stockage et analyse) – Élastique , car très appréciée par nos utilisateurs
• Suivi des performances et tableaux de bord – Prometheus et Grafana
• Développement continu (DC) – Spinnaker
• TLS – gestionnaire de certificats
• Application de démonstration – Google Bank of Anthos

Comment le code est déployé

Pour installer et déployer l’exemple d’application, émettez une seule commande pour appeler le script de démarrage, et les projets Pulumi suivants sont exécutés dans l’ordre indiqué. Chaque nom de projet correspond à un nom de répertoire relatif au répertoire racine du référentiel . Pour plus de détails, consultez le fichier README .

vpc - Définit et installe le VPC et les sous-réseaux à utiliser avec EKS └─eks - Déploie EKS
└─ecr - Configure ECR pour une utilisation dans le cluster EKS
└─kic-image-build - Crée une nouvelle image NGINX Ingress Controller
└─kic-image-push - Envoie l'image créée à l'étape précédente à ECR
└─kic-helm-chart - Déploie NGINX Ingress Controller sur le cluster EKS
└─logstore - Déploie le magasin de journaux Elastic sur le cluster EKS
└─logagent - Déploie l'agent de journalisation Elastic (filebeat) sur le cluster EKS
└─certmgr - Déploie le graphique Helm cert-manager.io sur le cluster EKS
└─anthos - Déploie l'application Bank of Anthos sur EKS 
                            grappe

Beaucoup plus d'intégrations et plus de flexibilité dans la version 2

Nous reconnaissons que notre effort initial pourrait ne pas fournir toutes les intégrations dont vous avez besoin pour votre environnement Kubernetes. Platform Ops propose des choix intelligents, mais pas illimités. Pour faciliter l'essai et l'adoption potentielle de notre nouvelle plateforme de référence par les équipes Platform Ops, DevOps et développeurs, nous prévoyons de nombreuses améliorations à court terme, notamment :

• Démarrez Digital Ocean, OpenShift, Rancher, vSphere et d'autres environnements Kubernetes

• Intégrez-le à NGINX Controller > pour gérer et surveiller NGINX Plus Ingress Controller

  [ Éditeur – NGINX Controller est désormais F5 NGINX Management Suite .]

• Fournir une configuration prête à l'emploi pour NGINX App Protect
• Intégration avec les produits et services F5 tels que BIG‑IP , Cloud Services et Volterra
• Intégration avec NGINX Service Mesh et Aspen Mesh basé sur Istio
• Intégrez nativement Terraform et d'autres outils d'automatisation
• Prise en charge d'autres options CI/CD
• Déployer des clusters distincts ou multiples pour les services d'infrastructure et d'application

Nous espérons que notre travail pourra devenir un cadre pour d’autres plateformes de référence et un point de départ « volable » pour la construction de tous types d’applications modernes différenciées. Parce que Kubernetes est un mécanisme très puissant pour créer des applications modernes et pour renforcer les opérations de plateforme et la culture shift-left, plus notre architecture de référence est étendue et enfichable, mieux c'est. Nous sommes impatients de voir ce que vous, la communauté, pensez de notre travail et, plus important encore, ce que vous construisez avec lui.

Démarrer avec l'architecture de référence

Téléchargez notre plateforme de référence et essayez-la. Dites-nous ce que vous pensez et ce que vous aimeriez que nous construisions ensuite. Les demandes d'extraction sont plus que bienvenues. Nous sommes impatients de nous associer à vous pour la prochaine génération d'applications modernes, adaptables et « volables » qui profitent à la communauté et à tous les développeurs.

Articles Similaires

Cet article fait partie d'une série. Au fur et à mesure que nous ajoutons des fonctionnalités à MARA, nous publions les détails sur le blog :

• Une nouvelle architecture de référence pour les applications modernes Open Source (ce post)
• Intégration d'OpenTelemetry dans l'architecture de référence des applications modernes – Rapport d'étape
• MARA: Actuellement en cours d'exécution sur un poste de travail près de chez vous
• Annonce de la version 1.0.0 de l'architecture de référence des applications modernes NGINX