Des fois de bonnes idées peuvent tourner à la catastrophe
Le pattern BFF, de quoi s'agit-il?
J'ai eu récemment une discussion sur la pertinence ou non de ce pattern dans la construction d'une plateforme de services santé. S'il est sur le papier intéressant, je vais expliciter ici les raisons pour lesquelles je le déconseille de prime abord.
Quelques blogs de qualité détaillent ce pattern de manière relativement simple et efficace, par exemple ici or ici.
Il faut envisager ce pattern comme l'inverse d'ATAWAD (Any Time, Any Where, Any Device). Ou tout du moins l'inverse de la conception qui en a petit-à-petit été faite. Si ce grand principe se voulait à l'origine une ouverture des frontières techniques en "se mettant en capacité de pouvoir proposer des fonctions" sur n'importe quel terminal, n'importe quand... Les solutions techniques trouvées ont malheureusement trop souvent été réduite à "proposer les mêmes fonctions sur tous les canaux". C'était l'avènement puis la chute du "responsive UI".
> Article en anglais sur les erreurs d'interprétation du "digital", notamment ATWAD
Les besoins entre les différents front-ends pour une population donnée sont hétérogènes : des fonctionnalités différentes (on en fait pas la même chose sur son mobile dans le métro et sur sa tablette dans son canapé), des besoins en performance différents ou bien encore une connectivité variable. Utiliser les mêmes services pour tous les canaux (les mêmes pages et les mêmes APIs) est un non-sens.
Le pattern "Backends for Frontends", propose de prendre celà en compte en introduisant une couche intermédiaire dédiée à chaque front entre les services métiers et les applications clientes :
De l'utilisation des mauvais outils ou de la mauvaise utilisation des bons outils...
Le concept est très clairement intéressant et n'est de surcroit pas nouveau en réalité. J'ajouterais même qu'il peut s'avérer nécessaire si nous devons faire face à un nombre élevé de transactions ou à l'exposition d'un nombre important de services "Back-end". La complexité et le risque ne viennent pas du concept en tant que tel mais de son implémentation probable.
"Back-end", y es-tu?
Je n'ai pas coutume d'adresser les problématiques d'architecture applicative. Je me concentre habituellement sur les questions d'architecture d'entreprise. J'en suis cependant venu à traiter ce point justement à cause du flou introduit par ce principe, dans lequel réside pour moi le risque majeur :
- d'un point de vue du développeur web ou mobile, nous parlons bien de back-end (synonyme de "reste du monde")
- d'un point de vue architecture globale (ayant une vision sur ce reste du monde...), nous sommes au niveau du middle (dont c'est d'ailleurs la définition)
Accéder directement depuis les fronts à des microservices métier peut s'avérer complexe. Si l'on ajoute à cela le fait qu'un système informatique tend à se complexifier avec le temps (si si, je vous assure), ce pattern qui pouvait sembler être une bonne idée risque fort de se transformer en un anti-pattern célèbre : La grande boule de boue (en anglais Big Ball of Mud). D'aucuns diront qu'il s'agit là du pattern standard de conception informatique...
Le problème ne vient en réalité, dans ce cas, pas du nombre important de services exposés, mais du nombre important de choses exposées qui ne devraient pas être des services.
La définition adéquate des bons services requiert une gestion des domaines métier. Par "gestion" j'entends bien sûr non seulement la définition claire des frontières entre les différents domaines et de leurs responsabilités, mais aussi la mise en place d'une structure (humaine) s'assurant de la cohérence globale des solutions et des trajectoires d'évolution. J'évoquerai probablement le Domain Driven Design dans un autre post.
Attention au syndrôme "pas de ça chez moi"
Lorsque l'on parle d'introduire ou modifier un front (application mobile, site web, interface vocale...) et également une couche de service dédiée au dit front, se pose la question de la responsabilité de l'implémentation. Je ne parle même pas ici de la question de maintenance. Vont se présenter trois défis majeurs :
- La mise en place d'un nouveau composant vient généralement d'un besoin métier spécifique : faire une application de simulation de crédit, une application de saisie de ses prises de médicaments... Les évolutions se retrouvent ainsi naturellement sous la responsabilité des pôles métier spécifiques.
- Les équipes "front" gèrent les "fronts". Ce qui parait évident est en fait un problème dans notre cas. Les équipes front ne disposent pas des outils, compétences ni même de la légitimité pour adresser la question de couches plus proches des services métier.
- La réponse devrait venir d'une équipe indépendante. Une équipe en charge par exemple de la définition et de la cohérence d'une architecture d'entreprise globale; de l'équipe d'architecture donc. Or celle-ci ne dispose que rarement d'un budget en propre pour la constitution decomposants spécifiques (et encore moins si ceux-ci embarquent un tant soit peu de logique métier).
Repositionner le "Backend spécialisé" comme une couche d'abstraction infra
Forts de ces constats, nous devons autant que possible limiter les développements spécifiques pour implémenter le pattern BFF. Prenons un peu de recul avant de partir bille en tête sur du développement. Que cherchons-nous à atteindre? une couche d'abstraction entre les services métier et leurs consommateurs, une couche de filtrage et éventuellement de redirection. Si l'on parle infrastructure d'ensemble c'est exactement l'objectif d'un composant d'API gateway (petit exemple ici).
Les solution D'API gateway répondent donc à un premier ensemble de besoins de performance, sécurité et de throttling (limitation des accès concurrents et totaux). Elles sont ainsi une extension de la notion de DMZ au delà des questions de sécurité pure :
Ces solutions peuvent aussi servir d'aggrégateurs de services entre des SI hétérogènes. Le marché des mutualistes français par exemple est en pleine mutation et les fusaqs se multiplient. Les besoins de digitalisation et de proposition de nouveaux services aux adhérents sont croissants alors que l'effort de rationalisation des systèmes devrait prendre l'intégralité de la Capacité A Faire de la DSI. Les solutions d'API gateway permettent la mise en place de trajectoires de rationalisation, certes plus longues, mais ne bloquant pas le métier :
Lorsque nous évoquons le pattern BFF, nous rencontrons exactement ces deux besoins :
- assurer les contraintes de performance et de sécurité par canal
- tout en permettant un couplage lâche avec les services des domaines métier :
Le pattern BFF seul est inutile
Ce pattern doit bien être vu comme un plan de remédiation technique. Il doit obligatoirement être combiné à une identification globale des risques et des contraintes (d'un point de vue métier). Et il doit enfin s'appuyer sur un premier niveau de réponse adapté à chacun de ces risques :
- Nous supposons qu'un front va être utilisé pour une consultation massive de certaines données : mettons en place une couche dédiée d'accès aux données et de cache
- Au contraire une application front doit faire des updates ou inserts en masse et ce au détriment potentiel de processus critiques back-office : mettons en place le pattern CQRS
- Enfin, votre crainte est une question de résistance aux pannes et de scalabilité de vos services métier : partons sur la conception de microservices et l'utilisation de containers.
Une solution apportée uniquement par l'IT est souvent un futur problème pour le métier
Une solution répondant à un besoin métier peut devenir un standard IT (prenons par exemple les solutions Big data). Par contre, une solution pensée purement IT s'avère rarement pérenne.
Un couplage lâche réel et efficient entre les frontaux (les canaux d'interaction de manière plus large) et les services métiers ne passe donc pas uniquement par une couche technique intermédiaire.
Comme nous avons commencé à l'entrevoir dans le paragraphe précédent, les véritables solutions ne proviennent que d'études métiers détaillées : étude des interactions digitales et des comportements utilisateurs, étude des besoins non fonctionnels... La définition des Domaines métiers sous-jacents et des services associés est la clef du succès.