L’architecture Orientée Service (SOA) nous fait penser à la rupture de grands systèmes monolithiques en des services individuels, mais elle a également encouragé la construction de services trop compliqués avec le contrôle centralisé et l'orchestration. Avec les microservices, nous revenons aux notions sous-jacentes de pourquoi SOA fait sens, a revendiqué Rebecca Parsons lors de la conférence QCon Londres, dans une présentation durant laquelle elle parle de la manière dont les microservices peuvent être un catalyseur pour la construction de systèmes plus flexibles afin de gérer la vitesse et l'ampleur attendues des changements business, ainsi que des raisons pour lesquelles le continuous delivery (CD) a été si important avec l'aptitude à s’adapter aux microservices.
Parsons, CTO chez Thoughtworks, pense également que SOA a encouragé une plus grande acceptation de la cohérence éventuelle et le remplacement de bases de données relationnelles avec d'autres types de bases de données, mais note qu'il existe encore beaucoup de résistance et d'hésitation à abandonner les transactions ACID.
Parsons souligne que lors de l'adoption d’une architecture microservice, que ce soit par la décomposition d'une solution monolithique existante ou en débutant sans héritage préalable, la granularité des services est essentielle, ce qui suggère l’utilisation d’un contexte borné de Domain-Driven Design (DDD) pour trouver les limites qui séparent les services. A noter que cela devrait être effectué à partir d'une perspective business en pensant aux capacités commerciales, et non d'un point de vue technologique. La cohésion et le couplage, ainsi que les modes de communication et de l'architecture de données sont d'autres aspects pour trouver les services. Les parties qui communiquent beaucoup ou qui partagent des données peuvent bénéficier d'être au sein du même service.
L'architecture évolutive est pour Parsons une série de principes, le plus important étant la manière de traiter avec les parties d’un système qui est le plus vulnérable au changement. En travaillant avec les systèmes monolithiques, vous avez souvent essayé de prédire comment les gens allaient agir dans les 3-5 années à venir et de construire des systèmes en réponse à ce besoin. Aujourd'hui, nous essayons plutôt d'être tolérants aux changements autant que possible, même envers les changements que nous n’avions pas prévus. L'accent sur l'évolutivité est un aspect critique et les microservices font partie de la fondation pour le support de celle-ci.
Les microservices ajoutent un fardeau supplémentaire aux opérations avec plus de choses à déployer, gérer et surveiller - activités qui évoluent avec le nombre de services. Sans une forte culture DevOps et une communication étroite entre les organisations de développement et d'exploitation, c’est une recette qui mènera droit au désastre. Heureusement, la plupart des fonctionnalités disponibles dans le continuous delivery (CD) visent à simplifier la gestion d’architecture microservice pour les équipes d'exploitation.
Parsons conclut en soulignant que les microservices ne sont pas une solution miracle et que tous les problèmes ne devraient pas être résolus en les utilisant.