Cet article s’insère dans la série “microservices” écrite par François Berthault dans le cadre de la participation de Talan Labs à Devoxx 2017, du 5 au 7 avril prochains au Palais des Congrès de Paris.
Même si au démarrage des microservices les équipes de développement peuvent travailler en mode “NO OPS”, les limitations se feront vite ressentir. Il est essentiel d’impliquer les OPS dans un processus DEV-OPS.
Pour mettre en place ce type d’architecture, le “métier” doit aussi avoir une place centrale dans les réflexions. Et c’est par une approche de type DDD (domain-driven-design) que l’application sera fractionnée.
Attention toutefois : pousser le modèle trop loin reviendrait à créer des nanoservices en lieu et place de microservices !
Généralement, les organisations sont composées d’équipes indépendantes et spécialisées (le MOA, les développeurs, les administrateurs de bases de données ou DBA, les administrateurs système et les testeurs). Un microservice a besoin des mêmes compétences impliquées en son sein, afin d’éviter de créer un nouveau monolithe.
_« Un microservice est un produit et non pas un projet en tant que tel. » _Martin Fowler
À titre d’exemple, le modèle d’organisation le plus souvent cité est celui de Spotify.
Avec l’avènement du cloud computing comme nouveau paradigme d’hébergement (merci à Netflix et à Amazon !), on a vu apparaître de nombreux frameworks légers adaptés au développement rapide de microservices, comme Dropwizard, Spring Boot, Spotify Apollo, Spark (Java), Kumuluzee (J2EE), Flask (Python), Sinatra (Ruby) ou Vert.x (Polyglotte).
Les directeurs des systèmes d’information n’ont plus qu’à bien se tenir, l’air des microservices est bien en marche !
Pour ceux qui, en 2016, n’auraient pas encore essayé les microservices, il est grand temps de s’y mettre !
Et pourquoi pas aller découvrir les architectures sans serveur (serverless) comme AWS Lambda d’Amazon ?
Cette première série d’articles vous aura permis de découvrir les principes fondamentaux de l’architecture en microservices et les conditions nécessaires à réunir avant de commencer.
Si vos orientations stratégiques sont d’augmenter la scalabité de votre application pour augmenter le nombre de client, d’assurer un service et une expérience utilisateur de haut niveau, d’acquérir de nouveau marché et de rester compétitif, les microservices sont la solution.
Cependant, la route est encore assez longue avant de faire le buzz « microservice ». Commencez par créer un ou deux microservices à forte valeur ajoutée fonctionnelle. Éprouvez différents frameworks s’il le faut. Par la suite et avec de la maturité sur le sujet, vos prochains sujets d’études seront le « service discovery » et ensuite l’« event-driven data management ou CQRS/ES». Affaire à suivre…
Vous avez aimé cet article ? Découvrez ou redécouvrez les autres épisodes de la série « Les microservices pour une architecture orientée web » :
Partie 1 Les microservices pour une architecture orientée web n°1 : Définitions et caractéristiques
Partie 2 Les microservices pour une architecture orientée web n°2 : Un changement de point de vue
