Dans beaucoup de projets, sortir une brique dans un microservice est devenu un réflexe. Ceci n'est pas une mauvaise pratique, c'est même très souvent pertinent. Cependant, cela ajoute une frontière, un coût, en plus entre notre service et notre microservice détaché ( appels HTTP internes, sérialisation, latence, logs distribués, déploiements multiples, complexité DevOps ).
Cette conférence part d’une question simple :
Et si, parfois, nous ajoutions ces frontières par habitude plus que par nécessité ?
Je viens d’un écosystème (Golang) où l’on fait très attention aux frontières réseau et à leur coût. Tout peut et doit être optimisé pour délivré une réponse le plus rapide possible.
J’ai donc construit une expérimentation simple :
une application de gamification orientée event sourcing, implémentée de deux façons strictement équivalentes :
- une version avec un service externe appelé en HTTP
- une version où la logique vit directement dans le même processus ( via FrankenPHP )
Les services executent le même code et font la même chose, la seule différence entre les deux est l'architecture et donc l'analyse du fameux coût du rajout d'une frontièere lié à l'ajout d'un microservice
Le but ici est de montrer que cette frontière existe toujours et de poser la question sur les nouveaux outils comme FrankenPHP qui permettent d'apporter une nouvelle réponse à cette question d'architecture
