Étude De Cas  : Une Décennie De Microservices Dans Une Entreprise Financière

Les microservices sont le nouveau modèle architectural à la mode, mais le problème avec «à la mode » et « nouveau » est que cela peut prendre des années pour que les coûts réels d'un modèle architectural soient révélés. Heureusement, le pattern n'est pas nouveau, juste le nom l'est. Ainsi, nous pouvons apprendre des entreprises qui le font depuis une décennie ou plus.

Dans cette étude de cas, nous examinerons comment les microservices ont été mis en œuvre dans une entreprise financière. Lorsque j'ai rejoint l'entreprise, ils utilisaient déjà le modèle depuis cinq à dix ans et cela a continué pendant une demi-décennie sous ma supervision.

Qu'est-ce qu'un microservice ?

Étant donné que le terme « microservice » n'existait pas lorsque nous avons commencé dans cette voie, nous avons appelé nos 85+ microservices « process applications ». La caractéristique déterminante de nos microservices était que chacun effectuerait une et une seule activité. Ces activités comprenaient :

• Surveillance d'un lecteur réseau pour les fichiers à traiter.
• Écoute d'un port TCP pour les messages de partenaires commerciaux. (Imaginez que quelqu'un vous diffuse les cours des actions.)
• Agréger les messages d'autres services dans un format standardisé avant de les traiter et de transmettre les résultats aux bases de données et aux caches.
• Écoute d'une file d'attente de messages. (MSMQ à l'époque, mais de meilleures options sont disponibles aujourd'hui.)
• Hébergement d'un cache spécialisé.
• Hébergement d'un port HTTPS. (Nous avons utilisé HTTP.sys pour cela, car cela facilitait la gestion des certificats serveur et client.)
• Surveillance d'une table de base de données pour les enregistrements à traiter. (Habituellement, interrogation sur un timer, mais maintenant, je recommande d'utiliser SqlDependency à la place ; le Chain ORM intègre cette fonctionnalité.)
• Transmettre les messages WCF des applications de bureau à un port TCP connecté aux partenaires commerciaux. (Encore une fois, des technologies plus récentes telles que gRPC peuvent être plus appropriées.)

La seule chose que nous n'avons pas faite a été de diviser chaque classe de contrôleur de nos sites Web en un livrable distinct. En partie parce que MVC venait à peine de démarrer et que nous, comme la plupart des shops MS à l'époque, étions encore principalement concentrés sur les formulaires Web pour notre site Web. Mais il y avait d'autres raisons pour ne pas diviser les sites Web que je couvrirai plus tard.

Microservices et sécurité

L'une des stratégies que j'ai instituée était une règle stricte selon laquelle chaque microservice dispose de son propre compte de domaine Active Directory. Cela signifiait que le fichier de configuration de chaque application n'incluait pas les noms d'utilisateur et les mots de passe pour les ressources internes. (Nous en avions parfois besoin pour des ressources externes telles que des sites Web et des serveurs FTP gérés par des sociétés partenaires.)

Auparavant, nous avions la mauvaise habitude d'utiliser un seul login partagé entre toutes les applications. Et comme beaucoup trop d'entreprises aujourd'hui, cette connexion unique était en fait un administrateur pour les bases de données. Cela a facilité le déploiement, mais a également rendu le risque de catastrophe incroyablement élevé.

Chaque microservice doit avoir ses propres identifiants réseau.

Mon raisonnement pour faire ce changement était qu'il m'a permis de verrouiller la base de données. Chaque application ne pouvait effectuer que les actions qu'elle avait réellement besoin d'effectuer. Cela a empêché de mauvais résultats tels qu'un pirate informatique utilisant une vulnérabilité dans notre serveur de tarification pour télécharger ou détruire notre table d'utilisateurs.

Plus tard, nous avons appris que nous avions accidentellement construit un système de documentation assez robuste. Avant d'instituer la politique d'informations d'identification réseau distincte, nous devions effectuer des recherches de code exhaustives pour voir quel impact un changement aurait sur nos applications. Il ne nous reste plus qu'à interroger une base de données pour obtenir une liste complète des tables, vues et procédures stockées auxquelles elle a accès. Cela a considérablement réduit le nombre de tests de régression nécessaires lors de la modification de la base de données.

Nommer et numéroter chaque service

Bien qu'un nom unique pour chaque service soit important, les noms ne suffisent pas à éliminer la confusion, surtout lorsque vous avez de nombreuses applications avec des noms très similaires.
La façon dont nous avons résolu ce problème était d'attribuer à chaque service sa propre "clé d'application". Il s'agit d'un identifiant numérique court que vous pouvez utiliser dans des éléments tels que les fichiers de configuration et les colonnes d'audit de base de données.

Étant donné que chaque clé d'application était enregistrée dans une seule table, nous avons également obtenu un inventaire complet de chaque application, microservice, outil, etc. qui pourrait éventuellement être utilisé. Et nous ne nous sommes jamais retrouvés dans une situation où nous ne savions pas quel logiciel nous avions construit ou où il fonctionnait.

Il peut sembler que je m'inquiète pour rien, mais en tant que consultant, je me retrouve souvent à travailler avec des clients qui ne peuvent littéralement pas me dire combien de sites Web et de microservices ils ont en fonctionnement. Sans référentiel central, nous devons interroger chaque développeur, administrateur réseau et service juste pour comprendre ce qui touche la base de données.

Frameworks d'application

Si vous optez pour la voie des microservices, il est essentiel que vous développiez votre propre framework d'application spécifique à l'entreprise. Et vous devez utiliser de manière dogmatique ce framework d'application dans chaque microservice. Sinon, il n'y a aucun moyen de suivre la maintenance.

Dans le monde.NET, votre framework d'application peut consister en un seul package NuGet qui définit les éléments suivants :

• Configuration
• Journalisation
• Injection de dépendances
• Accès de bas niveau aux bases de données
• Surveillance de la santé
• Composants de sécurité
• Bibliothèques communes

Maintenant, je ne dis pas que vous devez écrire des implémentations personnalisées de tout cela. En fait, vous souhaiterez probablement utiliser des packages prédéfinis qui gèrent la plupart, sinon la totalité, de ces éléments. Mais vous avez toujours besoin d'un framework d'application pour tout assembler et définir quelle version de chaque bibliothèque sera utilisée.

Un piège commun dans lequel tombent les développeurs est la conviction qu'ils peuvent suivre l'évolution de la technologie. Et peut-être qu'ils le peuvent en utilisant une architecture monolithique. Mais lorsque le prochain incident heartbleed se produit, vous n'avez pas le temps de vérifier le numéro de version de chaque bibliothèque sur des dizaines ou des centaines de microservices. Au lieu de cela, vous souhaitez mettre à jour le framework d'application vers la version sécurisée de la bibliothèque, puis pousser cette mise à jour du framework d'application sur tous les microservices.

Ce dernier point est là où un framework d'application diffère d'un "starter kit". Un starter kit définit où vous commencez, mais les applications s'en écarteront rapidement. Et ce n'est pas acceptable lorsque vous gérez plus d'une poignée de services. Lorsque je travaillais pour cette entreprise, j'étais personnellement responsable de la gestion de plus de 50 services. Je n'aurais jamais pu faire cela si chacun avait été configuré légèrement différemment et que je devais le réapprendre à chaque fois que je le touchais.

Le framework d'application vous offre également une couche d'abstraction indispensable. Par exemple, disons que vous découvrez que SmtpClient vous pose problème et que vous souhaitez passez à MailKit. Le framework d'application peut fournir un adaptateur qui imite l'API SmtpClient, mais envoie en fait des e-mails via MailKit. Cela réduira considérablement la quantité d'efforts nécessaires pour porter tous vos microservices vers une dépendance différente.

Self-reporting Services

Les services doivent être en mesure de déclarer eux-mêmes leur statut. La surveillance externe est toujours importante, mais l'auto-évaluation vous donne un niveau d'information auquel les outils de surveillance externes n'ont pas accès.

Dans notre cas, chaque service a déclenché un heartbeat sur un timer. Cela a été enregistré directement dans la base de données car notre base de données était notre ressource la plus robuste. (Il y avait un cluster de basculement multi-sites et vraiment, s'il tombait en panne, la plupart de nos services n'allaient pas être utiles de toute façon.) Avec des produits matures tels que Azure Application Insights, vous ne voulez probablement pas définir le vôtre comme nous l'avons fait.

Notre heartbeat comprenait les informations suivantes :

• Clé de l'application
• Nom de l'application
• Version de l'application
• Version du framework
• Serveur d'hébergement (ou machine virtuelle)
• Horodatage actuel
• Heure de démarrage (lorsque le service a été redémarré pour la dernière fois)

Un autre processus surveillerait la table des heartbeats, en recherchant les services qui ne s'enregistraient pas. Il pourrait également détecter quand quelqu'un a accidentellement installé un service avec des paramètres de production sur un hôte hors production.

À partir de là, vous pouvez vous appuyer sur des informations supplémentaires telles que l'opinion du service sur sa propre santé. Par exemple, un service qui écoute les messages en streaming des entreprises partenaires peut indiquer quand il semble que trop de temps s'est écoulé depuis le dernier message. Ou un processeur de fichiers peut rapporter combien d'enregistrements il a importés pour la dernière fois et quel pourcentage d'enregistrements se sont avérés défectueux.

Cela peut être fait à moindre coût dans un premier temps avec une colonne "statut" générique. Plus tard, des métriques plus sophistiquées ont été ajoutées au besoin dans des tables de reporting dédiés.

Machines virtuelles ? Docker ? Conteneurs ? Serverless ?

Je ne vais pas parler de la façon dont vous hébergez votre service. C'est un détail d'implémentation auquel les développeurs n'ont pas vraiment besoin de penser. Votre seule question importante est « Puis-je exécuter plusieurs copies de ce service en même temps ? », toutes les autres décisions peuvent être différées.

Lorsque j'ai commencé, la moitié de nos microservices fonctionnaient en tant qu'applications de bureau. En d'autres termes, il fallait littéralement se connecter à un serveur pour les lancer. La raison pour laquelle j'ai été engagé à l'origine est que j'avais de l'expérience dans la conversion d'applications en services Windows.

Mais ils n'avaient pas besoin d'être des services Windows. J'aurais pu prendre le même code, le déposer sur un serveur Web géré par IIS. Ou packagé dans un conteneur Docker. Pour certains d'entre eux, un hôte serverless aurait tout aussi bien fonctionné. Tant que toute interaction entre le service et son hôte est abstraite par le framework de l'application, vous disposez ici d'une flexibilité plus que suffisante.

Configuration centralisée

Au fil des ans, nous avons essayé de nombreuses façons de gérer la configuration. Nous avons essayé la configuration manuelle, les scripts de construction et même le stockage de la configuration directement dans le gestionnaire de sources. En fin de compte, toutes les méthodes ont échoué pour la même raison : elles n'étaient pas évolutives. À mesure que le nombre de microservices augmente, le temps nécessaire pour modifier un paramètre partagé augmente de manière linéaire et les chances de commettre une erreur augmentent de manière géométrique.

La solution qui a finalement fonctionné pour nous était la configuration centralisée. Les applications ont été créées avec une seule valeur de configuration nommée « Environnement ». Cela l'a dirigé vers un partage de fichiers avec la liste des environnements et les noms du serveur de base de données correspondants. Par exemple : "production:MainDB.company.net".

La configuration de la base de données contenait tous les paramètres nécessaires pour chaque application. Mais il y a plus que cela. Les paramètres communs, tels que l'envoi d'alertes critiques, ont été définis en premier. Ensuite, chaque application avait la possibilité de remplacer un paramètre commun ou d'introduire un paramètre spécifique à l'application. En outre, des instances spécifiques du microservice pourraient encore remplacer le paramètre.

Cela signifiait que lorsque nous devions changer quelque chose de commun, nous n'avions qu'à modifier une entrée et chaque service chargeait le nouveau paramètre. (Lorsque cela s'est produit, c'était spécifique à l'application, car certains microservices travaillaient sur des tâches de traitement de données de longue durée.)

Ce n'était pas une solution parfaite. Il y avait toujours la possibilité qu'une instance de non-production d'un microservice puisse être pointée vers l'environnement de production. Nous avions vraiment besoin de comptes AD séparés pour les services de production et hors production, mais cela dépassait nos capacités organisationnelles à l'époque.

Et vraiment, le serveur de fichiers contenant les noms des serveurs d'environnement et de base de données était stupide. Nous aurions dû simplement mettre le nom de la base de données directement dans le fichier de configuration et nous fier au DNS si le serveur de base de données devait être déplacé.

Commander et contrôler

L'un des aspects dont je suis assez fier est le commandement et le contrôle. Chaque microservice a exposé un port WCF auquel nos outils de surveillance internes pourraient se connecter. Nous avons utilisé WCF car il prenait en charge la messagerie bidirectionnelle, permettant la diffusion en direct des données du journal.

Mais les journaux n'étaient pas la fonctionnalité importante, de nombreux outils peuvent le faire. Le port de commande et de contrôle nous a également permis de voir les métriques de diagnostic qui n'étaient pas signalées dans les journaux. Par exemple, le nombre d'éléments actuellement conservés en mémoire en attente de traitement. Nous avons également pu voir les paramètres de configuration réellement utilisés par le service, qui peuvent différer de ceux du fichier de configuration car ces services n'étaient redémarrés qu'une fois tous les quelques mois.

Auparavant, j'ai mentionné que nos microservices étaient souvent déclenchés par un timer ou un observateur de système de fichiers. Les outils de commande et de contrôle nous ont permis de dire au service, "exécuter maintenant" ou "retraiter le fichier X". Cela était particulièrement important lors du dépannage de processus qui s'exécutaient rarement, parfois seulement une fois par heure ou même une fois par jour. Personne ne veut attendre 50 minutes pour relancer un test après avoir corrigé de mauvaises données de production. Et en parlant de données...

Accès à la base de données

Comme mentionné précédemment, chaque microservice avait ses propres informations d'identification réseau. Celles-ci ont été utilisées par la base de données pour déterminer quelles procédures stockées étaient accessibles au service. Je voudrais insister sur le mot "procédure stockée". Aucun service n'avait un accès direct à la table.

Cela peut sembler étrange à l'ère des ORM, mais les ORM tels que NHibernate et Entity Framework ont ​​un problème de couplage. Ils s'attendent à avoir un accès complet et sans entrave à la base de données et à lier étroitement leur modèle objet au schéma de la table.

Cela peut fonctionner lorsque vous avez une application touchant la base de données, mais pas lorsque vous en avez une douzaine, et encore moins une centaine. Avec autant d'applications, nous devions protéger notre base de données d'un couplage excessivement étroit et nos services des modifications de rupture.

Pour ce faire, les procédures stockées créent une couche d'encapsulation. La procédure stockée elle-même forme une API et les tables ne sont que ses détails d'implémentation cachés. Lorsque des modifications des tables sont nécessaires, la procédure stockée est soit mise à jour de manière rétrocompatible, soit son numéro de version est incrémenté, ce qui permet à l'ancienne et à la nouvelle version de s'exécuter temporairement côte à côte.

Et parce que chaque procédure stockée était accompagnée de la liste des microservices autorisés à y accéder, nous disposions d'une liste toute faite de tests de régression à effectuer chaque fois que la procédure stockée est modifiée.

Vous pouvez simuler cela en lançant un ensemble de serveurs REST entre vos services réels et la base de données. Mais ce ne serait qu'une simulation et n'obtiendrait pas tous les avantages en termes de performances et d'isolation d'une base de données entièrement encapsulée. Ce qui nous amène à notre prochain sujet.

Serveurs Web et Microservices

Auparavant, j'ai mentionné que nous n'appliquions pas l'approche des microservices à nos serveurs Web. La raison en est simplement parce que nous n'y avons vu aucun avantage et beaucoup de coûts. Voici la chaîne logique que nous avons utilisée :

Facilité de déploiement

Les microservices sont censés faciliter les déploiements. Cela suppose que les déploiements sont difficiles. Alors pourquoi les déploiements sont-ils difficiles ?
Les déploiements sont difficiles car il faut du temps pour arrêter en toute sécurité les services avec état, nos « applications de traitement ». Ils doivent être correctement programmés pour ne pas perturber les employés et, dans de nombreux cas, doivent être effectués pendant la période « inactive » entre le traitement de deux tâches.

Les serveurs Web ne sont pas avec état. Si vous déployez une nouvelle version, IIS traitera correctement toutes les demandes restantes et dirigera les nouvelles demandes vers la version nouvellement chargée. Ce qui signifie que les déploiements peuvent avoir lieu à tout moment, même si nous préférons les faire après les heures ouvrables pour permettre des tests supplémentaires.

Fiabilité et évolutivité

Les microservices sont également destinés à améliorer la fiabilité et l'évolutivité. Cela a beaucoup de sens, car vous ne voulez pas que le processus A plante les processus B à Z lorsqu'il échoue. Et tandis que le processus C peut être limité à une seule instance, les processus D et E peuvent permettre une mise à l'échelle. Ainsi, diviser chacun de ces processus en services distincts a beaucoup de sens.
Mais les serveurs Web sans état sont parfaitement évolutifs. Tant que vous disposez d'un espace rack suffisant, vous pouvez continuer à ajouter de plus en plus de serveurs Web. Finalement, d'autres limitations telles que la base de données et la capacité du réseau entreront en jeu, mais les serveurs Web eux-mêmes n'ont pas de limites.

Le coût des microservices

Même s'il n'y a aucun avantage, quel est le problème ?
Eh bien, si un serveur Web doit appeler d'autres serveurs Web, c'est une latence supplémentaire et plus de points de défaillance à gérer. Les performances et la fiabilité ne peuvent qu'être réduites, car tout maillon cassé de la chaîne peut perturber l'ensemble du processus.

Ce n'est pas le problème qui nous a le plus préoccupé lorsque nous avons expérimenté des serveurs micro-web. Le vrai problème était la gestion des dépendances et les déploiements. Chaque fois que nous modifions quelque chose dans l'interface utilisateur, nous devions invariablement modifier les appels de base de données backend pour qu'ils correspondent. Mais comme l'interface utilisateur et le backend se trouvaient sur des serveurs séparés, les deux devaient être modifiés et déployés en même temps. Le serveur Web de l'interface utilisateur était fortement couplé à chaque serveur Web principal.

L'autre problème était la composition, la combinaison de données provenant de sources multiples. En fin de compte, tout provenait de la même base de données, mais avec un serveur Web principal séparé pour les clients, leurs clients, leur inventaire, leurs transactions, etc., décider quel serveur Web devait exposer une donnée particulière était devenu un véritable cauchemar. Invariablement, tout ce que nous choisirions serait « mauvais » et devrait être déplacé quelque part ou être assemblé avec des données d’autres services.

Donc, à la fin, nous avons abandonné l'expérience et avons continué à permettre au serveur Web d'avoir un accès direct à la base de données.

Appartenance des données et journalisation des modifications

Pour revenir sur le sujet des données, l'une des questions les plus fréquemment posées en ce qui concerne les microservices est « Quel service a modifié cet enregistrement ? ». Invariablement, cela est demandé des dizaines de fois par jour par d'innombrables développeurs essayant de comprendre le réseau complexe de systèmes sur lesquels ils travaillent.

Vous pensez peut-être : « J'utilise un microservice devant la base de données, donc seul ce microservice aurait pu le modifier ». Si le microservice n'a pas décidé de modifier lui-même les données, s'il ne fait que répondre aux demandes d'autres services, ce n'est pas une vraie réponse.

La façon dont nous avons résolu ce problème est le concept de "clé d'application". Chaque mise à jour de la base de données enregistre à la fois l'utilisateur qui a initié la modification et la clé d'application du serveur Web ou du microservice qui a réellement effectué la modification.

Bien sûr, il est toujours possible que plusieurs microservices apportent des modifications contradictoires aux mêmes données. Ainsi, le concept de propriétaire des données est toujours important. Alors qu'en théorie, n'importe quel microservice peut lire n'importe quel champ, chaque fois que cela était possible, nous avons conçu les systèmes de manière à ce qu'un seul microservice puisse écrire dans un champ donné. Lorsque nous avons réussi, cela a facilité le raisonnement sur les changements de conception. Lorsque nous échouions et que plusieurs services écrivaient effectivement dans le même champ, nous pouvions au moins utiliser la liste des procédures stockées comme point de départ pour planifier les étapes suivantes.

Découplage et files de messages

Un avantage souvent vanté des microservices est qu'ils "découplent" des parties de votre système. Dans certains cas, nous avons constaté que c'était vrai, dans d'autres, c'était une farce. Pour comprendre pourquoi, nous devons d'abord définir le terme "découpler".

La définition de travail que j'utilise est la suivante : " le composant A n'est pas couplé au composant B si une défaillance de B ne provoque pas une défaillance de A ". Ce n'est pas la seule définition valable, mais en termes d'estimation de la robustesse d'un système, je trouve que c'est la plus utile.

Par exemple, nous avions différents flux de nos entreprises partenaires. Chaque flux avait son propre microservice, de sorte que si un flux échouait, cela ne mettait pas les autres en panne. Chaque flux écrivait également à deux systèmes, un serveur de cotation et un serveur de prix. Le serveur de cotation était essentiellement un cache qui contenait les données brutes des flux. Il était rapide, mais d'une utilité limitée. Le serveur de prix soumettait les cotations brutes aux calculs complexes du prix des obligations nécessaires avant d'insérer les prix dans notre base de données. La base de données serait utilisée par le serveur web, tandis que le serveur de cotation était utilisé par les traders sur des terminaux en temps quasi réel.

À l'origine, chaque fois que le serveur de cotation ou le serveur de prix tombait en panne, il entraînait tous les flux avec lui. De même, un flux errant qui submergeait un serveur pouvait effectivement casser les autres flux. Ainsi, selon la définition ci-dessus, non seulement chaque flux était couplé aux serveurs, mais chaque flux était également couplé à tous les autres flux.

Il faut noter que l'engorgement se produisait plus souvent qu'on ne le suppose. Contrairement au marché boursier, où chaque action est indépendante, les obligations sont souvent rattachées au prix ou au rendement des autres. Par exemple, lorsque le prix d'une obligation du Trésor américain change, il peut entraîner des dizaines de milliers d'obligations d'entreprises et municipales à changer de prix de la même manière.
Afin de résoudre ce problème pour le serveur de cotation, nous avons simplement modifié les messages pour qu'ils soient à sens unique et en cas d'échec, le flux rejetterait simplement le message. Cela peut sembler imprudent, mais les cotations changent rapidement, donc en manquer une n'était pas vraiment un problème important car elle serait rapidement remplacée par la suivante. En outre, le serveur de cotations était un logiciel si simple que rien de moins qu'une panne matérielle ne pouvait le faire tomber.

Pour le serveur de prix beaucoup plus compliqué, nous avions besoin d'une solution plus robuste. Il lui fallait un moyen de lire les données à son propre rythme, avec des protections contre les flux qui pourraient le submerger. Pour résoudre ce problème, nous nous sommes tournés vers MS Message Queues. Bien qu'il existe aujourd'hui sans aucun doute de meilleurs produits de mise en file d'attente des messages, à l'époque, MSMQ était plus que suffisant pour briser le couplage étroit entre les flux et le serveur de prix.

Dans le cas d'un serveur web, ce découplage devient beaucoup plus difficile. Si l'utilisateur attend une information, on ne peut pas simplement envoyer un message asynchrone dans une file d'attente pour qu'il soit traité à un moment indéterminé. Dans certains cas, le serveur web peut procéder sans l'information demandée, par exemple YouTube ou Netflix n'affichant pas occasionnellement votre liste de visionnage. Mais dans notre cas, il n'y avait pas de données "facultatives" et toute défaillance d'un microservice signifierait que le site web échoue également.

Considérations sur les versions

La grande majorité de nos microservices sont véritablement indépendants les uns des autres, ne s'appuyant que sur des files de messages ou la base de données elle-même. Pour eux, le problème de versionnement a été atténué en s'assurant que les messages et les procédures stockées étaient rétrocompatibles. Si l'un ou l'autre changeait de manière non sécurisée, alors une nouvelle file de messages ou une nouvelle procédure stockée était créée au lieu de modifier l'original.

Pour les quelques microservices qui communiquaient directement entre eux, un plan plus complet était nécessaire. Chaque service exposait un endpoint qui fournissait son numéro de version et son environnement. Lorsqu'un microservice démarrait, il vérifiait les numéros de version de tous les autres services dont il dépendait. Si la vérification échouait, il refusait de démarrer.

Conclusions

Les microservices sont plus appropriés pour les processus à état, et non pour les serveurs web facilement dimensionnables. Utilisez-les dans les cas où vous pouvez isoler les composants, soit entièrement, soit via des files d'attente de messages. Évitez de les utiliser lorsque cela ne fera que créer une chaîne d'appels de services synchrones. Et surtout, concevez un moyen de cataloguer votre inventaire de microservices afin qu'ils ne vous échappent pas.

A propos de l'auteur

Jonathan Allen a commencé à travailler sur des projets médicaux pour une clinique à la fin des années 90, les faisant passer progressivement d'Access et Excel à une solution d'entreprise. Après avoir passé cinq ans à écrire des systèmes de trading automatisés pour le secteur financier, il est devenu consultant sur divers projets, notamment l'interface utilisateur d'un entrepôt robotisé, le tier intermédiaire d'un logiciel de recherche sur le cancer et les besoins en big data d'une grande compagnie d'assurance immobilière. Pendant son temps libre, il aime étudier et écrire sur les arts martiaux du 16e siècle. 

.