En piochant à droite et à gauche, on imagine que cette notion fait référence aux des
architectures verticales et horizontales.
Le modèle 3tiers
On a d'un coté des modèles d'infrastructure en 'tiers' avec généralement 3 tiers:Le serveur web , le serveur de traitement (applicatif) et le serveur de données (SGBD) .
La conception MVC
A cette spécialisation des rôles s'ajoute un découpage fonctionnel en couche MVC
Le serveur applicatif met en oeuvre un ensemble de design pattern: Model Vue Contrôleur (inventé bien avant le WEB)
Et le reste: OOP , OS
A ce mille-feuille vient s'ajouter les couches liées au développement en approche objet puis celles du système d'exploitation.
Et donc..
On se retrouve avec un empilement de module , de composant de nature et de taille hétérogène.
Or quel est l'objectif: Offrir un service de qualité à nos utilisateurs. Ici intervient la notion de scalabilité. Comment supporter un nombre d'utilisateur plus important avec des volumes de données en hausse ?.
A chaque fois le problème est botté en touche en direction des responsables d'infrastructure.
Leur seule réponse possible est d'augmenter le nombre de serveur pour doubler, tripler les composants.
Mais empiler des briques hétérogènes fragilise la stabilité de l'ensemble. C'est coûteux pour un rendement marginal décroissant. Car cet empilement ne donne pas un rendement d’échelle linéaire.
Il faut trouver des systèmes pour partager des sessions serveurs , gérer des caches à tous les niveaux, des répartiteurs etc. bref le prix à payer est élevé.
La scalabilité horizontale consiste à augmenter le nombre de machine. La scalabilité verticale vise à augmenter la puissance unitaire des machines. L'orthogonalité cherche à combiner les deux approches en par une simplification des architectures.
Vers des architectures pus simples et ... moins coûteuses.
La première règle à mettre à oeuvre est de réaliser des applications avec des architectures simples avec moins de couche.
Règle 1: simplifier les couches d'abstraction: chaque abstraction coûte et ajoute de la complexité
Avez vous besoin de faire une application métier de gestion ou un site de publication ?
Si la réponse est 'une application métier' , vous n'avez pas besoin d'un serveur web complet pour votre application.
Votre choix doit se tourner vers des serveurs applicatifs à gestion d’événement non bloquants et asynchrone (Non-bloking I/O event loops) comme Node.js pour javascript , VertX pour Java ou eventmachine pour ruby.
Dans ces technologies , le développeur travaille directement son cœur de métier: la mise à disposition de ressources. Il n'est plus tributaire de la configuration lourde d'un serveur HTTP.
Un process en attente sur un serveur = gaspillage de ressource = les serveurs vous font les poches.
Règle 2: Réfléchir en terme de conteneur autonome.
Votre application doit être l'assemblage de briques identiques autonomes. Ces briques ne doivent pas gérer ou partager des sessions. Celles ci sont prises en charge par le client (REST: les requêtes sont autonomes
Ce qui implique aussi que chaque conteneur accèdes à des données dans son contexte.
Aussi un conteneur embarque : une couche HTTP, l'application métier et le backend de stockage.
Comment passer d'une architecture 'classique' à une architecture moderne.
- Tout d'abord la partie applicative:
- Puis la partie frontale :
Pour accéder aux conteneur, il est possible de placer en frontend le serveur NGINX. Ici ,il n'est pas utilisé comme un serveur web mais comme un reverse-proxy avec des fonctionnalités de répartition de charge.
- La partie backend ou stockage:
L'usage d'une base NoSQL viendra compléter le dispositif et rendra chaque 'nœud' autonome les uns par rapport aux autres.
- La partie SSO peut elle aussi être implémentée sur chaque nœud:
Ici , il n'est plus question de SSO préemptif ou coopératif: on est dans un mode de micro-SSO
Pour aller plus loin.
L'idée générale est d'obtenir des boites identiques autonomes un peu comme ceci :
Permettant empilements à la fois verticaux et horizontaux = Orthogonaux = des constructions solides.
