L’architecture 3-tiers est un modèle très connu et répandu. C’est une spécialisation du modèle multi-tiers qui propose de découper l’architecture logique en 3 couches. Ce modèle est-il toujours applicable avec une architecture serverless ?

Principe

Une architecture en 3 couches

Ce modèle d’architecture se décompose en 3 couches logiques bien distinctes qui ont chacune un rôle bien défini :

  • La couche de présentation correspond à l’interface utilisateur. Son rôle est d’afficher les données et de permettre à l’utilisateur final d’interagir avec ces dernières.
  • La couche métier est en charge d’appliquer et de respecter les règles métiers (ou actes de gestion). C’est dans celle-ci qu’est implémentée la logique applicative et la
    sécurité dans ce modèle d’architecture.
  • La couche d’accès aux données, quant à elle, assure la persistance des données qui doivent être conservées.

Cinématique

Avec ce modèle, chaque couche dialogue avec une autre au travers d’un contrat d’interface. Par convention, la couche de données est la couche la plus basse et la couche de présentation la couche la plus haute. Chaque couche expose alors des services à la couche supérieure.

Ce découpage permet de bien séparer les responsabilités. Chaque couche peut ainsi évoluer sans impacter les autres. En revanche, l’implémentation d’une nouvelle fonctionnalité peut toucher plusieurs couches.

Avec une architecture serverless

Dans la pratique

Ce modèle est transposable avec une architecture serverless. La promesse de ce nouveau type d’architecture est de faire les choses plus simplement et plus rapidement.

Pour cela, la pratique courante est d’implémenter la couche métier avec un FaaS et de l’exposer à une couche de présentation (en HTTP par exemple). L’architecture va alors s’appuyer sur un BaaS (oui, je sais, ça fait beaucoup de *aaS…) qui est l’un des piliers du serverless.

Cependant, ces services ont une approche bien différente de ce que l’on a l’habitude de faire. En effet, ils permettent d’exposer directement la couche d’accès aux données sur Internet, à la couche de présentation.

Une fois assurées les questions de sécurité (Qui peut accéder aux données ? Qui peut créer/modifier/supprimer quoi ? etc…), il faut adresser la question des traitements métiers. Et oui, c’est souvent le cœur de l’application ! Comme ce style d’architecture est orienté événement, c’est sans surprise qu’il est possible d’exécuter une fonction à partir d’un événement émis par la couche de données.

Avantages

Le premier avantage immédiat est la simplicité de l’implémentation. L’application cliente interroge directement la source de données et envoie les données à persister. Il n’y a plus besoin de faire transiter les données au travers de plusieurs couches. Plus besoin de transformer les données à chaque changement de couche.

Les autres bénéfices se mesurent à la fois en termes de performance et de coût financier. Le modèle est plus performant car la donnée est stockée directement sans traverser un certain nombre de couches (et donc sans subir un certain nombre de sérialisations/désérialisations). il est moins cher car, en “inversant” ces deux couches, on ne paie plus le temps passé dans la couche de données. En effet, pour rappel, les FaaS facturent à l’usage sur le nombre d’invocations et le temps consommé. Or si c’est la fonction qui insère la donnée, elle va devoir attendre que l’information soit envoyée à la solution de stockage, que la demande soit traitée et que le serveur retourne une réponse. Tout ce temps à attendre sera facturé avec le 3-tiers classique. Alors qu’avec le 3-tiers serverless, il n’y a pas toujours ce temps d’attente. Tout dépend si le contexte de l’événement transmet suffisamment d’information et s’il est nécessaire de mettre à jour des informations.

Inconvénients

La couche de présentation ayant un accès direct à la couche de données, tout le modèle de données est disponible. Alors, soit l’implémentation BaaS de persistance permet de masquer certaines informations, soit il faut prévoir un modèle à côté non-visible de l’extérieur.

De plus, des données non valides ou non consolidées peuvent être visibles pendant un court laps de temps. Le temps que la fonction soit déclenchée et valide la donnée. Il est possible de contourner ce problème avec un flag indiquant que la donnée a été validée et est disponible pour tous. Cependant, cela ajoute de la lourdeur à l’application.

Comment traiter les actes de gestions qui impliquent la création ou la mise à jour de plusieurs documents (ou lignes) ? Avec le 3-tiers classique, la couche métier reçoit toutes les informations en une seule fois. Mais avec ce nouveau 3-tiers, le système va recevoir plusieurs événements. Pour adresser cette problématique, une solution possible est d’implémenter l’équivalent d’un workflow qui procédera à une validation atomique après avoir récupéré tous les événements ou tous les documents modifiés.

D’un point de vue exploitabilité, on peut se demander comment gérer le non-déclenchement des événements ? Est-il possible de détecter que certains événements non pas été émis ? Est-il possible de savoir qu’un événement n’a pas été reçu ? Comment réconcilier la situation ? Que faire des données entre le moment où elles ont été persistées et le moment où les traitements ont été réconciliés ? C’est un sujet qui est très peu adressé aujourd’hui…

Dernier point, et non des moindres, est que la couche de présentation est directement impactée par les changements de la couche d’accès aux données. Cela peut s’avérer très pénalisant ou tout du moins engendrer un certain immobilisme dans le modèle de données.

Conclusion

Au premier abord, une architecture 3-tiers dans l’esprit serverless peut paraître perturbante et naïve. Pourtant, cette approche simplifie énormément l’implémentation. De même, elle permet de séparer les aspects persistance et logique métier.

Il existe un couplage fort entre la couche métier et données dans le 3-tiers traditionnel. Avec cette nouvelle version du modèle, le couplage devient plus fort entre la couche de présentation et de données.

Sur des cas d’usages basiques, il est assez évident que cette solution est intéressante. Reste à voir si elle est adaptée à des cas plus complexes… Enfin, si le 3-tiers “inversé” pose des problèmes sur certains cas, la solution serait alors un 3-tiers hybride qui mixe les deux modèles selon les services.