L'application du paradoxe de Thésée
L’étude de la philosophie, du moins dans le passé, a consisté à poser des questions qui, à première vue, semblent, disons, hors de propos. Après tout, est-il vraiment si important de savoir « si un navire qui a été restauré en remplaçant chaque pièce en bois » reste le même navire ? C'est la question que Plutarque a posée dans la Vie de Thésée et est devenu par la suite connu sous le nom de paradoxe de Thésée. De manière plus générale, la question est de savoir si « un objet dont tous les composants ont été remplacés reste fondamentalement le même objet . » ( Le navire de Thésée, Wikipédia )
On pourrait demander la même chose aux microservices qui, appliqués à des applications monolithiques existantes, cherchent essentiellement à restaurer l’application en remplaçant des fonctions par des services complémentaires. Les fonctions sont petites (ou devraient l’être) par conception, et le terme « micro » est donc appliqué aux services découplés qui en résultent. Les différences entre les deux peuvent être perçues en termes de communication. Dans une application monolithique, les fonctions sont invoquées en référençant une adresse spécifique en mémoire. Dans une application basée sur des microservices, les fonctions (services) sont appelées en référençant une adresse IP spécifique dans le réseau.
Conceptuellement, les deux sont identiques, seul le mécanisme d’invocation des composants fonctionnels individuels diffère. Un diagramme résultant montrerait essentiellement peu de différence, si ce n’est que la « boîte » du monolithe est un serveur unique et la « boîte » des microservices est l’ensemble du centre de données. L’un utilise l’adressage localisé, l’autre l’adressage réseau. Le code de chacune de ces fonctions pourrait être exactement le même, tout comme le bois du navire de Thésée.
Mais ses fonctions commerciales restent cohérentes et, en fait, si nous avons correctement décomposé l'application, l'utilisateur ne devrait voir aucune différence perceptible entre les deux. On pourrait soutenir que du point de vue du passager du navire de Thésée, il n’y a aucune différence entre les deux. Il ne devrait pas y en avoir.
Mais les philosophes ont tendance à creuser plus profondément, et, comme eux, nous devons le faire aussi, car la différence entre une application monolithique et une application basée sur des microservices est, en fait, assez importante pour les opérations.
La complexification des opérations de réseau
Les microservices simplifient de nombreux aspects du processus de développement d’applications, mais créent ainsi une grande complexité opérationnelle. Le nombre de connexions réseau entre les différentes parties d'une application basée sur des microservices nécessite nécessairement une surcharge associée à la gestion des différentes caractéristiques réseau requises : Adresses IP, VLAN, tables NAT et plus encore. L'évolutivité devient également un défi que même Dijkstra pourrait trouver frustrant, car le placement des microservices et du service d'équilibrage de charge a un impact très réel sur les performances en fonction du nombre de segments du réseau à parcourir.
Des politiques supplémentaires sont soudainement nécessaires, car les politiques de sécurité applicables à un service qui accède directement à une source de données sensibles ne sont pas celles qui sont nécessaires pour sécuriser un autre service qui gère les préférences ou l’état de session. Le réseau résultant de politiques de micro-sécurité offre certainement bon nombre des mêmes avantages que les microservices eux-mêmes, à savoir un contrôle plus précis et une sorte de simplicité élégante, mais devient en même temps un cauchemar opérationnel car les politiques doivent soudainement évoluer avec les services, où qu'elles apparaissent dans l'architecture.
Le déploiement devient également soudainement exponentiellement plus difficile, comme passer d'une simple danse en boîte à pas au flamenco plus compliqué, avec beaucoup plus de pas et beaucoup plus de mouvements sur la piste de danse (centre de données). L’orchestration et l’automatisation deviennent une exigence pour garantir la cohérence et la prévisibilité nécessaires pour mettre toutes les pièces en place au bon moment.
Les responsables de la fourniture de ces services de réseau et de sécurité pour les applications doivent reconnaître que le navire n’est pas le même, quelle que soit la vue à mille cinq cents mètres. Cela semble simple : une application est simplement remplacée par dix services. Voilà ! L'application a été recréée, tout comme le navire de Thésée. Mais du point de vue opérationnel, ce navire n’est pas du tout le même. Les jonctions (intégration) du nouveau navire sont complètement différentes, ce qui peut modifier la friction créée contre la mer (réseau) et avoir tendance à faire naviguer le navire plus lentement.
Les microservices sont encore émergents. Ils ne prennent pas le contrôle du monde (pour l’instant), mais il est important de reconnaître que ce n’est pas aussi simple que de démolir le navire de Thésée et de le reconstruire. Les équipes d’exploitation des services de réseau et de sécurité doivent adopter le point de vue du philosophe plutôt que celui du passager (utilisateur), car l’impact sur le réseau et sur la sécurité est très, très différent.