BT

Accueil InfoQ Actualités "Wait, What!? Our Microservices Have Actual Human Users?" L'importance de l'architecture IHM

"Wait, What!? Our Microservices Have Actual Human Users?" L'importance de l'architecture IHM

Favoris

Durant la conférence microXchg, qui se tenait à Berlin en Allemagne, Stefan Tilkov a présenté “Wait, what!? Our microservices have actual human users?” ("Attends, Quoi!? Nos microservices ont des utilisateurs humains?" - NdT). Tilkov explique que les discussions actuelles autour des microservices semblent pluôt centrées sur les sujets backend, comme les styles d'API, les analyses de services et la montée en charge. Or, il défend qu'il est primordial de recentrer la perspective sur ce qui est certainement le sujet principal des microservices - l'interface utilisateur.

Tilkov, co-fondateur et consultant principal chez innoQ, commence sa présentation en examinant le rôle des composants fronts dans une architecture microservice, et présente la première hypothèse d'une série, "l'orchestration est bon marché". Tandis que la latence de communication d'un backend microservice se compte en micro-seconde (c'est à dire au sein du trafic d'un datacenter), la latence typique de la communication sur internet (du client vers le backend) se mesure en millisecondes. Ceci a conduit les développeurs à positionner l'orchestration et l'aggrégation des données dans le backend.

Le pattern "backend pour frontend" (BFF) connaît une popularité grandissante ces derniers temps, comme un antidote aux complexités d'orchestration du frontend, mais Tilkov suggère que les propriétés inhérentes à ce pattern ne conduisent pas à la création d'implémentations idéales.

Je ne pense pas que [ce pattern backend pour frontend] est ce que vous voulez. Je pense que c'est une chose qui vous arrive, parce que vous réparez un élément déjà cassé. C'est parfois un bon choix et parfois un choix rationnel, mais je ne pense pas que ce pattern soit à suivre.

Ceci mène à l'hypothèse suivante, les "canaux sont importants", le pattern BFF semble être implémenté pour chaque canal, comme pour le web, les tablettes et applications natives, ce qui peut mener à la création de plusieurs connections inter-services (et des dépendances fragiles). Tilkov justifie que les canaux ne sont pas importants, et que les utilisateurs attendent plutôt "une expérience sans couture entre les canaux". Par conséquent, construire des services qui "font vraiment quelque chose" est une pratique recommandée. Ceci reprend l'idée que "le SOA est le pêché original" - les services sont plus importants.

La quatrième idée présentée est que "la technologie front est un détail d'implémentation". Cette section de la présentation commence par une explication des objectifs typiques du backend d'une plateforme microservice : pas de dépendances dans l'implémentation, des surfaces réduites d'interface, la construction sur des standards, des déploiements indépendants et des opérations autonomes. Tilkov demande au public quelle analogie il y a avec la plateforme frontend, et argue que des technologies comme les liens, les redirections et la transclusion, en combinaison avec la perception du navigateur comme plateforme, s'alignent sur les objectifs présentés pour le backend.

Tilkov repasse sur l'hypothèse que "les frontend monolithiques sont OK" et "parfois valides". Les fronted natifs ressemblent typiquement à des serveurs monolithiques, avec des objectifs et des contraintes similaires, et les techniques de structure d'organisation (“la loi de Conway”), les interfaces de plateforme, les trains de release et la discipline requise pour limiter les problèmes classiques de développement et de déploiement.

La dernière idée présentée, "les apps web centrées JS peuvent faire de bonnes apps natives", est réfutéé avec la réponse "elles ne devraient pas être aussi mauvaises !". Tilkov demande au public de remettre en cause le choix d'une approche d'architecture monolitique si elle n'est pas requise. En présentant des excuses à Phillip Greenspun, Tilkov utilise une citation et met en garde le public pour éviter de réinventer l'intégration des fonctionnalités d'un navigateur, d'accepter des niveaux d'inefficacité, et d'éviter la modularité à la Java EE ou OSGi, etc.

Toute application cliente JavaScript suffisamment compliquée contient une implémentation ad hoc, non spécifiée, pleine de bugs et lente d'un demi navigateur.

En conclusion, Tilkov expose que peu d'organisations vendent vraiment une fourniture d'API - UI qui compte. Par conséquent, les monolithes frontend sont juste aussi bons, ou mauvais, que les monolithes backend, et rien ne bat un navigateur au regard de la modularité de livraison d'un frontend. Toute personne pensant, ou impliquée, dans un passage vers des applications micro-services devrait considérer que les architectures frontend sont aussi importantes que celles du backend.

La vidéo de la présentation de Stefan Tilkov “Wait, what!? Our microservices have actual human users?” est sur le channel YouTube microXchg, et les slides de la présentation sur le site d'innoQ.

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Votre profil est-il à jour? Merci de prendre un instant pour vérifier.

Note: en cas de modification de votre adresse email, une validation sera envoyée.

Nom de votre entreprise:
Rôle dans votre entreprise:
Taille de votre entreprise:
Pays/Zone:
État/Province/Région:
Vous allez recevoir un email pour confirmer la nouvelle adresse email. Ce pop-up va se fermer de lui-même dans quelques instants.