La gestion de microservices implique de s'occuper de beaucoup de petits systèmes qui dialoguent entre eux et le provisionnement automatisé ainsi que l'automatisation de l'infrastructure sont cruciaux, a déclaré James Lewis en partageant les techniques et les pratiques qui l'ont aidé à gérer la complexité apportée par l'architecture microservice.
James, consultant pour ThoughtWorks, décrit l'origine des microservices comme la réaction à la manière dont nous avons construit des grosses applications monolithiques qui sont malaisées à changer, à tester et à gérer ; essentiellement, de gros tas de boue avec du code spaghetti entremêlé. La solution est de construire de plus petites choses et de les faire communiquer d'une manière ou d'une autre.
Pour James, les microservices signifient prendre une application importante, en identifier les contextes bornés et les capacités métier, et les diviser en prenant les données avec eux, c'est-à-dire des bases de données applicatives plutôt qu'une seule base de données d'intégration. La clé est de commencer au plus haut avec une map de contexte afin de comprendre le domaine métier. James se réfère à son collègue Ian Cartwright :
Il doit exister un isomorphisme entre le métier et l'architecture. Une personne du métier devrait pouvoir regarder une carte de haut niveau de l'architecture et y voir le métier représenté et de manière similaire, comme technologistes, nous devrions pouvoir regarder le métier et y voir représentée l'architecture.
La taille est un aspect important des microservices et James voit le Principe de Responsabilité Unique (PRU) comme une bonne mesure de celle-ci. Un service devrait avoir une unique raison pour changer ce qui en pratique implique qu'il doit être petit et suffisamment recentré pour pouvoir être compris conceptuellement.
Pour James, un concept central des microservices est la possibilité de déployer et de mettre à l'échelle chaque service indépendamment ; un service peut être déployé sur plusieurs instances et des services différents peuvent être hébergés sur le même serveur. Lors de la construction et du déploiement de services distribués, James insiste sur le fait que le provisionnement automatisé est crucial, chaque service ou chaque application doit être construit, déployé et mis à l'échelle automatiquement. Avec les microservices, une grande part de la complexité vient de l'intégration mais nous pouvons employer des modèles pour résoudre ce problème et nous référer au livre Continuous Delivery pour des modèles de pipeline de construction.
L'automatisation d'infrastructure avec des outils comme Chef et Puppet aidant au provisionnement automatique de machines est centrale dans la gestion de la complexité due à une multiplicité de services. Le modèle d'infrastructure Phénix décrit comment nous pouvons recréer l'intégralité de l'infrastructure à l'aide de l'automatisation d'infrastructure, p.e. nous devrions pouvoir être capable de supprimer une boîte et de lancer un script pour la recréer complètement avec ses dépendences.
La conférence sur les microservices que James mentionne est planifiée pour fin novembre à Londres.