Hello !

Pour conclure je vous propose de détailler maintenant les problématiques que nous avons résolus grâce à notre architecture.

Au niveau du projet et du code .Net

• Projet Visual Studio correctement découpé : « separation of concerns »
• Temps d’exécution des builds bien plus rapide.
• Montée en compétence plus rapide sur les projets
• Moins de couplage entre les composants.

Au niveau de l’application

• En cas de modification, on doit tester un service.
• Déploiements plus facile et plus fréquent puisqu’ils sont réalisés sur un périmètre restreint
• La mise à l’échelle est plus simple puisqu’il est facile grâce à ASF de provisionner une nouvelle instance de microservice.

Reprenons notre analyse FURPSE pour détailler les avantages de notre architecture :

• Fiabilité : Notre application est beaucoup plus légère, et la couche de services est résiliente grâce à l’autoscaling Azure Service Fabric.
• Performance : Les temps de réponse sont équivalent mais la charge de calcul est répartis entre service dans le Cloud.
• Maintenabilité : Le code est correctement découpé, il est donc bien plus facile à tester et debugger.
• Evolutivité : En cas d’évolution sur un service, on doit redéployer ce service et non plus toute l’application. On peux effectuer une migration techniques / technologiques de façon plus simple sur un contexte réduit.

Nous avons donc répondu aux problématiques de notre existant et rendus notre application facilement déployable, testable, maintenable, évolutive et tolérante aux pannes.

Nous allons maintenant détailler la mise en œuvre concrète de la solution Azure Service Fabric introduit précédemment.

Notre système d’information de démonstration contient une application cœur de métier, utilisée par tous les employés du SI.

Cet applicatif « monolithique » adresse ainsi tous les métiers de l’entreprise :

• Gestion client
• Comptabilité
• Commerce
• RH
• Fournisseur / Achat

Chaque employé à accès aux divers écrans en fonction de ces droits attribués par rapport à son rôle dans l’entreprise.

Un nouveau besoin pour un usage en mobilité conduit notre SI à une étude autour de son existant et une évaluation des possibilités d’amélioration.

Problématiques de l’existant

Les problématiques autour de cette application cœur de métier sont nombreuses :

Au niveau du projet et du code .Net, une base de code volumineuse apporte plusieurs problématiques :

• Projet Visual Studio conséquent
• Longueur des builds sur les postes de développement.
• Difficulté à démarrer sur le projet pour un nouveau développeur
• Couplage entre les modules de l’application : code spaghettis

Au niveau de l’application :

• Problèmes de performances.
• En cas de modification, il faut retester l’application dans son ensemble car les modules sont fortement couplé.
• Cycle en V plutôt que méthode agile lié au coup de déploiement.
• La mise à l’échelle implique de cloner toute l’application sur un nouveau serveur.

Pour détailler les problèmes de cet existant, nous pouvons utiliser l’approche FURPSE :

• Utilisabilité : L’application est pollué par des lenteurs excessive.
• Fiabilité : En cas de défaillance d’un composant, l’application crashe totalement. L’utilisateur doit alors relancer toute l’application.
• Performance : Lenteur de l’application, au démarrage et lors de la navigation du aux trop nombreuses dépendances. Consommation de ressources CPU/RAM importante.
• Maintenabilité : En cas d’erreur, difficulté d’analyse.
• Evolutivité : Les évolutions sont couteuses à mettre en place car elles impliquent beaucoup d’analyse d’impact et de tests de la part des développeurs.

Conceptions

Le but de ce chapitre est de présenter comment bâtir une architecture microservices à partir de notre existant. Ce que nous voulons obtenir c’est une application de présentation, la plus légère possible et qui ne contient aucune logique fonctionnelle et une couche de service déployé dans Azure Service Fabric.

Celui-ci contient des services regroupés par domaine fonctionnels :

• Clients
• Comptabilités
• Documents
• …

A noter que certains services n’ayant pas besoin d’être forcément scalable (car peu utilisé) peuvent être déployé dans des WebApp plus classique par soucis de simplicité.

Une fois la logique fonctionnelle extraite de notre application, il sera bien plus facile :

• De faire évoluer nos services.
• D’ajouter une nouvelle application cliente.
• De tester et déployer nos services.
• De les rendre résilient aux pannes et adaptable à la charge.

Nous allons présenter différentes possibilités pour mettre en œuvre notre architectures microservices en gardant à l’esprit nos besoins. Nous souhaitons :

• Des services au contexte délimité.
• Un couplage faible entre composants.
• Testables facilement et automatiquement.
• Déployable automatiquement.

Proposition 1 : Un monolithe organisé :

Ce découpage ne convient pas à nos besoins pour des raisons évidente.

Proposition 2 : Un monolithe et des services :

Proposition 3 : Un monolithe distribué. Les services sont dupliqués manuellement pour répondre à la charge :

Le risque de cette dernière proposition est de vite se retrouver à gérer :

Proposition 5 : Une architecture microservice avec Azure Service Fabric :

Proposition retenue : Si le besoin d’ouvrir notre SI à des clients externe est présent nous pourrons facilement le mettre en œuvre grace à Azure API Management :

Prochaine étape : la création de notre cluster Service Fabric !

Hello !

Suite à ce précédent article je vais aujourd’hui parler gestion des donnés avec des microservices dans Azure Service Fabric.

Cet article est une “réponse” aux questions soulevées ici !

Gestion des données

Il est bien sur possible d’utiliser des bases de données existantes (on prem) et d’héberger tout type de base de données dans Azure si besoin pour répondre aux différentes problématiques Data de vos applicatifs.

• SQL Server
• NoSQL : mongoDB
• MySql

En ce qui concerne la séparation des données par service ASF, il n’y a pas de solutions meilleures qu’une autre. Chaque microservice est responsable de ces données et de leurs cohérences mais il n’y a pas d’obligation de provisionner une base de données pour chaque service. Nos options sont :

• Chaque service à son jeu de tables attribués et ne peut effectuer des opérations CRUD que sur ces tables. Un seul microservice doit avoir accès à une table de la base de données. Il est donc interdit à un service B de réaliser une opération CRUD sur les données dont est responsable le service A.

• Un service pour un schéma de la base.
• Un service : une base de données.
• Découpage lecture/écriture des données avec la mise en oeuvre du pattern CQRS.

L’architecte positionnera en fonction des contraintes et besoins de chaque solution la meilleure gestion de donnée pour le système d’informations.

Gestion des transactions

Les microservices peuvent-ils partager une transaction ?

Si une opération de mon SI nécessite deux microservices, comment font-ils pour se partager la transaction et garantir la cohérence du système en cas d’erreur ? Il faudrait pouvoir faire un rollback en cas d’échec et un commit en cas de succès mais sur les deux services via une même transaction.

Il s’agit d’une problématique purement logicielle à traiter manuellement avec éventuellement :

• Commit en deux étapes : voir MSDN.
• Méthode d’annulation : gestion par le développeur d’une méthode Non A pour chaque méthode A.

Ces deux façons de faire sont compliquées à mettre en œuvre et le risque d’erreur est important … Elles ne sont pas conseillées pour du microservice… Après tout si deux services sont impliqués dans une transaction commune, le découpage en « Bounded Context » de l’approche DDD n’est probablement pas optimal !

Ici nous avons traité de problématiques logicielles qui ne sont pas forcément spécifiques à Service Fabric mais à l’implémentation d’une architecture microservices en général. Il me semblais important d’en parler tout de même.