Loading...Au premier abord, il n’existe pas une grande différence entre un acteur et un microservice tant que l’on n’observe que leurs propriétés intrinsèques. Chacun de ces composants logiciels possède une interface, un jeu de responsabilité limité, est faiblement couplé aux autres et est localisable dans un système d’exécution. La différence notable est qu’un acteur peut « décider » de modifier son comportement en fonction d’événements extérieurs et créer d’autres acteurs, deux caractéristiques qui ne sont pas requises de la part d’un microservice. Bien entendu, si l’on restreint le comportement d’un acteur à réagir à des messages sans créer d’autres acteurs et sans modifier son propre comportement, il n’y aura plus grand-chose pour le distinguer d’un micro-service bien que ceci soit sujet à caution : nous parlons ici des acteurs et des services vu de l’extérieur. Il y a fort à parier que le structure interne de chaque type de composant sera bien différente !
Acteurs : de l’analyse au calcul, il y a loin de la coupe aux lèvres ?
On peut dès lors se poser la question de la faible adoption du modèle d’acteur comme modèle de traitement par rapport au modèle de micro-services. Cela tient selon moi justement aux deux propriétés particulières que possèdent les acteurs : créer d’autres acteurs et modifier leur comportement dynamiquement.
Permettre à un acteur d’en créer d’autres, dans un système distribué a un impact non négligeable sur l’état global du système et, par voie de conséquence, sur sa scalabilité et ses performances. Plus précisément, c’est la décision de déterminer où ces nouveaux acteurs vont être stockés et exécutés qui va avoir cet impact majeur sur l’architecture d’exécution du système. De plus, le fait de devoir garder une trace de chaque acteur, de sa localisation et de son hôte d’exécution induit un réseau distribué de données sujet à des erreurs de cohérence et à de la latence.
L’autre propriété des acteurs, l’évolution dynamique de leur comportement, outre les problèmes de causalité et de localité d’état qu’elle engendre (et qui sont étudiés d’un point de vue formel et théorique) possède également des conséquences concrètes. En effet, implémenter l’évolution dynamique est relativement complexe, surtout lorsqu’on utilise un langage fortement typé. Additionnellement, le langage d’implémentation doit posséder des propriétés d’introspection et d’intercession de manière à être réflexif. Ce n’est plus un problème à l’heure actuelle puisque la plupart des langages fortement typés comme Java (mais pas comme C/C++) et tous les langages dynamiques sont considérés comme réflexifs. Outre cette contrainte qu’elle fait peser sur le choix du langage d’implémentation, l’évolution dynamique des acteurs rend également le code plus difficilement optimisable.
Des acteurs comme modèles
Le plus grand intérêt du modèle d’acteur reste cependant sa promotion de l’isolation totale entre les composants d’exécution. Comme nous l’avons vu dans le premier article de cette série, les acteurs ne partagent jamais leur état (mais en possèdent un). Dans l’esprit des concepteurs du modèle, cet état est l’état interne de l’acteur. On peut imaginer qu’il en va de même de l’état externe, celui qui va, par exemple, être persisté dans une base de données. Et on reconnaît là une propriété bien connues des microservices : ne jamais partager leur état externe et les entités dont ils ont la charge.
De cet autre point de vue, la différence ontologique qui sépare l’acteur du microservice tend à se réduire et la frontière entre les deux modèles à devenir plus floue. A-t-on pour autant le loisir de plus les distinguer ? Eh bien, non. Les deux modèles servent encore des buts différents dès qu’on les considère comme des outils d’architecture.
Le service, l’unité fonctionelle de base
Un service est avant tout caractérisé par son interface dont la conception est basée sur la sémantique des opérations que l’on veut confier au service. Cette interface comprend aussi bien des spécifications de structure (l’URI ou le format d’échange des données par exemple) que de comportement. Un bon exemple est donné par des services web RESTful qui acceptent des requêtes HTTP bien formées, spécifiées selon les règles sémantiques du protocole HTTP elles mêmes étendues par les règles qui gouvernent le contenu de la requête. Le service fournit une réponse qui suit les mêmes règles mais qui peut également fournir des indications de comportement au client par le biais du mécanisme de Hypermedia as the Engine of Application State (HatEoAS). Un tel service possède une interface uniforme composée des quatre verbes de base du protocole HTTP (get, post, put et delete).
Bien entendu, un acteur idéal possède également une interface mais celle-ci ne fournit aucune indication sémantique particulière si elle se limite à une primitive de passage de message. En effet, l’acteur le plus simple expose une méthode pour accepter des messages asynchrones sans réponse et éventuellement une autre pour les messages exigeant une réponse (souvent donnée sous la forme d’une continuation).
Il est bien entendu possible d’exposer des services dont l’API est aussi rudimentaire mais une propriété des architectures de services étant l’interopérabilité, de telles API difficilement utilisables sans documentation seront sous-employées ou mal employées. On tombe dans l’excès inverse de la SOA version SOAP/XML où les API de services exigeaient d’être documentées et décrites en utilisant un formalisme plus complexe qu’elle ne l’étaient.
Dans ces conditions, il semble assez illusoire que le modèle d’acteurs détrône celui des micro-services pour la conception de systèmes ouverts et interopérables. Cela ne veut pas dire qu’il y ait une exclusion mutuelle des deux approches. Un micro-service peut très bien exposer son API RESTful et être implémenté au moyen d’acteurs, l’API n’étant plus qu’une passerelle. Nous parlerons de cette technique de conception dans le prochain article.
Si vous avez des problématiques similaires sur vos projets, n’hésitez pas à prendre contact avec Sébastien ou l’un des consultants Pentalog Institute !
