Prise en charge des applications cloud natives à douze facteurs dans Mendix | Mendix Guide d'évaluation

Qu'est-ce que la méthodologie d'application à douze facteurs ?

Bien qu’il ne s’agisse pas à proprement parler d’un ensemble de principes architecturaux, Application à douze facteurs La méthodologie est un ensemble de bonnes pratiques pour les applications cloud natives.

Comment le Mendix Prise en charge de l'exécution des applications cloud natives à douze facteurs ?

Les sections ci-dessous décrivent comment Mendix est conforme aux exigences méthodologiques de l'application Twelve-Factor.

• Base de code

  Par défaut, le code source de chaque application que vous créez avec Mendix est stocké dans le Mendix Référentiel de code Team Server. Lorsque vous déployez une application, un package est créé en fonction de votre modèle tel qu'il est stocké dans Team Server. Ce package est ensuite déployé dans vos différents environnements, par exemple d'acceptation ou de production.

• Dépendances

  Toutes les dépendances (comme les modules et les bibliothèques) utilisées par les modules de votre application font partie du modèle d'application. Cela signifie qu'aucune dépendance implicite aux outils n'existe dans votre environnement. Cela garantit des déploiements fiables.

• Configuration

  Les besoins de configuration sont définis dans votre modèle d'application via des constantes. Ces valeurs peuvent être spécifiées au moment du déploiement dans votre environnement ou via des API appelées dans votre pipeline CI/CD. Les valeurs de configuration réelles ne font jamais partie de votre modèle, ce qui signifie que le même package de déploiement peut être déployé dans n'importe quel environnement sans modifier le modèle d'application.

• Services d'accompagnement

  Toutes les exigences externes (comme la base de données pour stocker les données de votre application) et les services à appeler depuis votre application peuvent être configurés au moment du déploiement. Comme les exigences précédentes, cela garantit que le même package de déploiement testé peut être utilisé dans n'importe quelle situation, avec n'importe quel service de support, sans modification du modèle.

• Construire, publier, exécuter

  S'il était possible de modifier le code dans un environnement de production, la mise à l'échelle de votre application deviendrait imprévisible et peu fiable. Cela rendrait également le débogage et la résolution des problèmes plus difficiles. Pour éviter ce problème, Mendix La plateforme sépare clairement les étapes de construction et d’exécution.

  Dans l' Mendix Portail, vous devez d'abord créer un package à partir de votre modèle, qui pourra ensuite être déployé dans vos environnements. Si vous souhaitez effectuer une modification de code en production, vous devez modifier votre modèle puis créer un nouveau package. Mendix fournit également des API pour créer et déployer vos applications, afin que vous puissiez intégrer cette approche dans votre pipeline CI/CD personnalisé.

• Processus

  Mendix L'environnement d'exécution est conçu pour être complètement sans état. Il partage les données via une base de données, garantissant une évolutivité et une résilience faciles.

• Liaison de Port

  Pour faciliter la mise à l'échelle et l'exécution de la même application dans différents environnements, l'application doit être autonome (ce qui signifie que l'endroit où elle écoute les demandes des clients doit être configurable). Mendix les applications peuvent être configurées de cette manière, permettant à la plate-forme sous-jacente en tant que service (PaaS) (par exemple, Docker ou Kubernetes) de faire évoluer facilement le nombre de conteneurs hébergeant votre application.

• Concurrency

  Mendix utilise une combinaison de threads et de processus Java pour s'adapter à la demande de vos utilisateurs finaux. La méthodologie Twelve-Factor App met l'accent sur la nécessité d'évoluer via des processus ; sinon, vos exigences d'évolutivité seront limitées au maximum de ce qu'une machine virtuelle Java (JVM) peut prendre en charge (évolutivité verticale). En prenant également en charge l'évolutivité des processus, des ressources supplémentaires peuvent toujours être facilement ajoutées (évolutivité horizontale).

• Jetable

  Mendix Les instances d'exécution peuvent être arrêtées et démarrées selon les besoins. Dans un environnement multi-instances, les utilisateurs ne remarqueront généralement pas si une instance d'exécution est redémarrée. L'avantage de cette solution est que l'évolutivité horizontale est plus simple et plus rapide, et que le déploiement de nouvelles versions ou de nouvelles configurations devient plus rapide.

• Parité développement/production

  Pour garantir la qualité, les applications déployées dans des environnements de test doivent se comporter de la même manière dans les environnements de production. Mendix Dans le cloud, tous les environnements sont provisionnés de la même manière. Les seules différences sont la configuration, les données et votre application. Les données peuvent être déplacées entre les environnements via la sauvegarde et la restauration pour garantir des tests avec des données représentatives.

• Journaux

  Mendix Cloud utilise le Firehose de Cloud Foundry pour collecter tous les événements de journal de toutes vos applications. Vous pouvez les visualiser et les filtrer dans le Mendix Portail.

• Processus administratifs

  Pour éviter les problèmes de synchronisation, la méthodologie Twelve-Factor App conseille d'expédier le code administratif avec le code d'application. Mendix applique cette pratique, de sorte que le seul code qui s'exécutera dans votre environnement d'application est le code qui fait partie de votre application. Cela signifie que vous devez intégrer le code d'administration au modèle. Les utilisateurs implémentent souvent cela avec la logique d'administration dans une page d'administration en implémentant un microflow à exécuter après le démarrage de l'application ou en créant des API pour déclencher des actions d'administration.