Aujourd'hui, les approches agiles ont le vent en poupe dans le monde de l’entreprise. L’objectif derrière cette nouvelle façon de construire des logiciels est de réduire le time-to-market des fonctionnalités proposées par ces produits. Mais aussi d'obtenir des feedbacks réguliers des différentes parties prenantes afin d'adapter en continu les produits. De cette façon, les entreprises peuvent répondre au mieux et dans de meilleurs délais au monde changeant qui les entoure.
D’un autre côté, l’explosion des services Cloud ces dernières années, et plus récemment, des approches dites Serverless offrent aux entreprises les moyens de moins se soucier de l’infrastructure de leur système d’information. Les géants du web, tels qu’Amazon, Google et Microsoft, permettent aux DSI de consommer les services d’infrastructure, logiciels qu’ils proposent. Cela leur permet de se concentrer uniquement sur leurs besoins métier. Ainsi, les entreprises gagnent en souplesse et en temps pour développer leurs propres services. Le time-to-market est mécaniquement meilleur.
Au vu de ce constat, n’y a-t-il pas un mariage à faire entre l’agilité et les architectures Serverless proposées par les Cloud Providers ? Qu’est-ce que les entreprises ont à gagner de ce mariage ?
L'architecture d'un SI doit être agile
Etre plus agile passe par une nouvelle méthodologie
Aujourd’hui, quand on parle implémentation de l’agilité en entreprise, on pense naturellement à l’adoption de nouvelles méthodologies de travail telles que Scrum, Kanban ou SAFe qui sont les plus répandues. Sans rentrer dans le détail de ces différentes approches, leur objectif est double :
Réduire au maximum les effets tunnels entre l'expression d'un besoin et sa livraison sous la forme d'un produit logiciel.
Introspection régulière du produit logiciel et la façon de travailler afin de les adapter le plus tôt possible. Et livrer un produit avec une valeur maximale pour les utilisateurs.
Les méthodologies agiles : une nécessité non suffisante
L’adoption d’une méthodologie agile est nécessaire, mais pas suffisante pour rendre le développement d’un produit logiciel agile. Comme évoqué en introduction, la capacité à adapter un produit logiciel à tout moment de son cycle de développement est la principale caractéristique des approches agiles. Par conséquent, le code, lui-même, doit avoir aussi cette capacité à s’adapter le plus facilement possible et surtout sans remettre en cause sa stabilité.
Les méthodologies agiles citées ci-dessus n’abordent pas ou peu les pratiques d’ingénierie logicielle permettant de s’assurer d’avoir un code adaptable. Elles doivent être complétées par des pratiques de conception et de développement venant des mouvements XP (eXtrem Programing) et Software Craftsmanship. Parmi ces pratiques, je citerai la plus emblématique : le TDD (Test Driven Development). Cette technique consiste à aborder l’implémentation de toute nouvelle fonctionnalité par une série de cycles regroupant les étapes suivantes :
Le développement d'un test échouant
Le développement du code de production minimum permettant de faire passer le test développé précédemment
Le refactoring du code écrit pour le rendre le plus propre possible
Ainsi, cette pratique permet d’avoir un code testable et testé en permanence. Et grâce au refactoring continu, en garantissant un haut niveau de qualité (lisibilité, maintenabilité, …) grâce au refactoring continu. Le code s’en trouve plus facilement adaptable tout au long du cycle de développement sans remettre en cause sa stabilité.
Enfin, malgré l’adoption d’une méthodologie agile et de pratiques d’ingénieries logicielles permettant d’être plus agile, les organisations peuvent encore rencontrer des freins pour rendre leur système d’information agile. N’y a-t-il pas une réflexion à avoir au niveau de l’architecture du SI pour le rendre complètement agile ? Chez INVIVOO, nous pensons que transformer une organisation pour qu’elle soit plus agile passe aussi par une réflexion sur les choix architecturaux de son SI. Certaines architectures apportant plus de modularité et de souplesse au niveau du SI dans son ensemble permettent de le rendre plus adaptable au changement. Et cela sans avoir à le repenser en grande partie à chacun de ces changements.
L'agilité au travers des architectures Serverless
L'apport de l'architecture microservices
L’architecture à base de microservices consiste à développer une solution logicielle non pas sous la forme d’un produit monolithique, mais à l’aide de plusieurs services communicant entre eux. Chacun ayant son propre cycle de vie et avec la plus petite granularité possible pour chaque service. Le but de cette architecture est de minimiser l’impact d’un changement sur le code. En effet, un changement au niveau d’une fonctionnalité impacte une liste connue de services en assurant qu’il n’y aucun impact pour les autres services. Cela est possible car le code interne de chaque service est parfaitement isolé des autres.
D’autre part, un changement sur l’environnement d’exécution d’un service n’a pas non plus de conséquences sur les autres services car chaque service peut avoir son propre environnement d’exécution, ce qui est impossible de garantir dans le cas d’une architecture monolithique. Une architecture à base de microservices est donc naturellement plus adaptable et donc plus propice à rendre un SI agile.
L'architecture Serverless : un pas de plus vers un SI plus agile
Les architectures Serverless, que ce soit le BaaS (Back-end as a Service) ou le FaaS (Function as a Service), poussent l’architecture microservice un peu plus loin. En effet, elles proposent aux développeur de ne plus se soucier de l’infrastructure de déploiement, de l’environnement d’exécution et, par conséquent, des éventuelles problématiques de scalabilité. Pour cela, elles se reposent sur les solutions Cloud. L’approche Serverless est donc aussi très proche des préceptes de l’agilité pour différentes raisons :
Elle permet d’augmenter le focus des équipes de développement sur le code métier des applications. Par conséquent sur ce qui apporte de la valeur aux utilisateurs. Les équipes de développement ont moins à se préoccuper de certaines briques techniques fournies comme des services. Les problématiques de déploiement sont gérées par le provider de la plateforme Serverless. Tout comme l’agilité, une approche Serverless favorise une livraison régulière de valeur métier.
Elle rend toute application scalable, et ceci de manière transparente pour le développeur. Comme l’agilité, une approche Serverless facilite l’adaptation au changement (surtout au niveau de l’exécution).
En se focalisant sur le code métier, la collaboration entre l’équipe de développement et les utilisateurs finaux se trouve facilitée. Comme l’agilité, une approche Serverless prône la collaboration avec le client.
Une plateforme Serverless fournit souvent des briques techniques comme des services. Ces services permettent de réaliser rapidement des POC et d’adopter une approche Fail-fast. Comme l’agilité, une approche Serverless favorise un feedback rapide sur la viabilité d’une solution.
Une approche Serverless permet de réduire le temps de mise à disposition d’une fonctionnalité en permettant aux équipes de ne pas se soucier des problématiques de déploiement. Comme l’agilité, un des objectifs des approches Serverless est de réduire le time-to-market.
Conclusion
Pour conclure, rendre une organisation plus agile, ce n’est pas uniquement introduire une nouvelle méthodologie pour gérer ses projets ; c’est aussi introduire de nouvelles pratiques de développement et de nouvelles architectures. Parmi ces dernières, les architectures Serverless sont clairement propices à plus d’agilité au niveau des systèmes d’information. Il serait donc dommage de s’en priver.
Discutons-en !
Ces sujets vous intéressent ? N’hésitez pas à venir nous rencontrer sur le stand S5 à Devoxx France du 17 au 19 avril 2019 (cf. notre agenda). Ça sera l’occasion d’en discuter plus longuement avec nous !
En attendant, n'hésitez pas à découvrir nos solutions logicielles et conseil avec lesquelles nous accompagnons nos clients.
