Azure Service Fabric : notre projet

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 :

7 - Azure Service Fabric : notre projet

  • 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é :6 - Azure Service Fabric : notre projet

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

Proposition 2 : Un monolithe et des services :5 - Azure Service Fabric : notre projet

Proposition 3 : Un monolithe distribué. Les services sont dupliqués manuellement pour répondre à la charge :4 - Azure Service Fabric : notre projet

Le risque de cette dernière proposition est de vite se retrouver à gérer :3 - Azure Service Fabric : notre projet

Proposition 5 : Une architecture microservice avec Azure Service Fabric :

2 - Azure Service Fabric : notre projet

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 :1 - Azure Service Fabric : notre projet

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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *