Spring Cloud, ça sert à rien !

< Les 3 avantages d'une architecture orientée événements pour une plateforme IT

J'ai récemment eu l'occasion de participer à un atelier de travail, à propos de la mise en place de contrats d'échange entre microservices, dans une architecture distribuée donc. Sachant que ces services s'appuient sur Spring Boot, j'ai posé la question de savoir si l'abstraction Spring Cloud Contract avait été envisagée pour ce faire. Mais j'ai été surpris de me voir répondre qu'il avait été décidé que les modules de Spring Cloud n'avaient aucune utilité ; en somme, que l'on n'avait pas besoin d'abstraire la technologie dans les projets. Et j'avoue rester très perplexe par rapport à cette position de principe… En effet, si l'abstraction n'a pas de valeur, alors pourquoi Spring Boot ? Pourquoi Spring framework ? Pourquoi même utiliser Java et sa JVM ??

Selon une enquête menée par DZone en 2021, plus de 90% des développeurs Java ont utilisé Spring Framework à un moment donné, et environ 50% ont utilisé Spring Boot et Spring Cloud pour leurs projets. Les développeurs citent des avantages tels que la réduction du temps de développement et de la complexité, la meilleure productivité, la facilité de mise à l'échelle et l'amélioration de la qualité et de la stabilité du code.

Une étude menée par Pivotal en 2019 a montré que les développeurs qui ont utilisé Spring Boot pour leurs projets ont déclaré une réduction significative du temps de développement et de déploiement. Selon l'étude, les développeurs ont déclaré une réduction de 50% à 90% du temps de développement et de déploiement par rapport à des projets Java classiques.

Abstraction technologique et validation des échanges

Spring Cloud Contract est un module implémentant le pattern CDC (pour Consumer-Driven Contract) qui vient compléter un autre module, Spring Cloud Stream visant lui-même à abstraire les message brokers du marché. Un peu à la manière dont JDBC abstrait le SQL pour Java (et JPA) ; sauf qu'on parle de binders au lieu de drivers. Ainsi est-il possible de définir des listeners, dans un système distribué événements (ou des controllers REST dans un système orienté services) qui soient validés par un contrat fixant la structure des données échangées. La génération et la connexion au dépôt des contrats, qui sont typiquement au format Apache Avro, se fait par configuration uniquement ; aucune intrusion programmatique exagérée n'étant à déplorer. Tout le mécanisme est abstrait, à la sauce Spring IO.

Je ne dis pas, loin d'être un early adopter patenté, qu'il faille se précipiter sur toutes les nouveautés. Les équipes de développement ont besoin que les technologies incorporées dans les projets soient soigneusement évaluées. Mais je suis vraiment étonné que l'on trouve toujours des architectes logiciels pour dénigrer l'idée même d'une introduction de couches d'abstraction dans les projets applicatifs… Spring Cloud est un portefeuille de tout premier ordre, qui va de l'intégration des environnements cloud (Kubernetes, AWS, GCP, Azure, etc.) à la consolidation de processus métiers (avec Spring Cloud Data Flow), en passant par l'abstraction des déploiements (y compris serverless, avec Spring Cloud Function). Je considère qu'il n'est pas possible aujourd'hui de le balayer d'un revers de main. Il s'agirait là, à mon avis, d'une faute culturelle majeure.

Post-scriptum :

J'espère que vous connaissez WireMock, qui est une bibliothèque pour simuler des clients et des services web. Elle charge un serveur HTTP auquel on peut se connecter, notamment lors de tests d'intégration sur une application REST. Lorsque le serveur WireMock est déployé, on peut définir des attentes, appeler le service, puis vérifier son comportement. Ce qui est magnifique, à n'en pas douter, c'est que cet outil soit parfaitement pris en charge par Spring Boot... et plus spécifiquement Spring Cloud Contract ! Un outil à ranger sans hésitation aux côtés de H2 et Testcontainers.