Pour ne plus se perdre dans les nuages !
L’ensemble des articles sur l’architecture. Principes et mises en oeuvre technique.
Aujourd’hui je vous partage une liste d’outil et de documentation de référence pour votre travail d’architecte sur Azure. Cette liste est forcément incomplète, n’hésitez pas à indiquez ce que vous utilisez dans les commentaires ou sur twitter !
Continuer la lecture de « Les outils de l’architecte Azure »
Mardi 31 mars à lieu l’Azure Community Day. Un événement en ligne regroupant un ensemble de présentations sur différentes briques Azure !
Parmi l’ensemble des conférences, plusieurs font intervenir des speakers francophones. Ces talks sont regroupés sur le channel n°3 !
Voici le planning de ces présentations dédiés Azure.
Continuer la lecture de « Virtual Azure Community Day »Aujourd’hui je vous propose une liste de liens : des sites, blog ou flux Twitter qui vous permettrons de vous documenter et de rester à jour sur la solution Azure, le cloud de Microsoft. Bonne lecture !
Continuer la lecture de « Quelques liens utiles pour Azure »Aujourd’hui nous allons parler d’Azure Monitor. Comme son nom l’indique, cette solution, que nous pouvons utiliser avec AKS comme avec d’autres briques Azure, permet de collecter et présenter :
Hello !
Pour conclure je vous propose de détailler maintenant les problématiques que nous avons résolus grâce à notre architecture.
Reprenons notre analyse FURPSE pour détailler les avantages de notre architecture :
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.
Pour la communication entre services nous avions listé deux possibilités :
Ici je vais expliquer la communication synchrone par appel HTTP. A mon sens pour démarrer sur cette architecture nous pouvons commencer par cette approche. Si par le suite le besoin est présent alors une utilisation d’Azure Service Bus peux être implémenter et déployer progressivement.
Voici une méthode permettant à notre application cliente d’appeler un service dans Service Fabric :
Il s’agit d’un appel d’une API REST tout à fait classique. Notre service est exposé via le port 82. Pour ce faire nous avons ouvert le port sur notre cluster lors de la création et configuré le port de notre service dans le fichier ServiceManifest.xml du projet : Verifier la section Resources/Endpoints du fichier.
Si un autre service de mon cluster Service Fabric doit réaliser le même appel, l’url sera la suivante : http://localhost:19081/OrangeTechsMicroservices/Clients/1. On remarque que l’appel se fait sur localhost (quel que soit l’environnement) et que le port utilisé est celui du reverse proxy Service Fabric.
Comme déjà évoqué, la complexité des appels HTTP est plutôt faible, nous verrons que l’utilisation de Service Bus pour effectuer des échanges asynchrones n’est pas aussi évidente et demande un peu plus de réflexion.
A bientôt !
Pour le développement de nos services, qui seront des composants de cette architecture :
Une bonne pratique consistera à implémenter le pattern Repository. Notre application se décomposera en 3 couches :
Schéma d’architecture d’un service. Les flèches en rouge représente des appels non autorisés.
Chaque couche est séparée par des interfaces pour la mise en œuvre de l’injection de dépendance dans nos projets.
A noter que Asp .Net Core supporte nativement cette bonne pratique via la classe ServiceCollection.
Au niveau des framework et outils tiers nous pourrons utiliser, en vracs :
J’en oublie surement mais j’ai cité les indispensables 🙂
A très vite pour la partie dev !
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 :
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.
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 :
Au niveau de l’application :
Pour détailler les problèmes de cet existant, nous pouvons utiliser l’approche FURPSE :
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 :
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 :
Nous allons présenter différentes possibilités pour mettre en œuvre notre architectures microservices en gardant à l’esprit nos besoins. Nous souhaitons :
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 !
Après ces trois derniers articles :
Nous pouvons conclure qu’Azure Service Fabric propose une solution clé en main pour la conception d’une architecture microservices dans Azure car il offre des réponses aux différentes problématiques de mise en œuvre de microservices.
Grâce à cette offre PAAS, les développeurs ont à leur disposition :
De plus, un des avantages majeurs de cette solution à mon sens est que les développeurs retrouveront leur marque assez rapidement par rapport au développement d’API REST en ASP .Net Core.
A contrario une solution comme Azure Container Service implique la montée en compétence sur :
Maintenant que nous en avons terminé avec l’analyse de cette solution nous allons passer à la mise en oeuvre 🙂
Hello !
Suite à ce précédent article je vais aujourd’hui évoquer la gestion des erreurs et la tolérance aux pannes.
Cet article est une “réponse” aux questions soulevées ici !
Le monitoring et la gestion des logs sont intégrés a Azure Service Fabric grâce à deux composants Azure :
Ces deux modules doivent être activés à la création du cluster Azure Service Fabric et configuré dans la solution Visual Studio.
WAD permet de :
Pour cela WAD collecte des « journaux » :
Application Insights quant à lui permet de :
AI nous offre également un langage de requête, inspiré de LinQ (Analytics pour Application Insights) pour extraire les données qui nous intéresse et les présenter sous forme de graphiques par exemple.
Insight analyse :
Insight est un outil complet et très puissant que nous aurions tort de ne pas utiliser avec Service Fabric de même qu’avec une Web App d’ailleurs 🙂
Dans cet article nous avions identifié ces besoins :
Azure Service Fabric répond à ce besoin car la plateforme tente d’apporter la plus grande fiabilité possible à notre application en nous proposant nativement :
Mais nous détaillerons ces points précisément lors de la mise en oeuvre concrète de cette solution PAAS !