Bonjour,

Je droppe juste un mot:
Je recommende OpenTracing/Jaeger pour suivre les transactions à travers la stack (avec du sampling bien sur).

Merci pour vos retours en tout cas.
Cela alimente pas mal mes réflexions.

Merci rdlp pour OpenTracing, je me posais justement des questions sur comment suivre l'info au coeur du système.

Et du coup, ça donne quoi au final ?

C'est en cours :)
On doit faire un PoC sous peu sur une petite partie du projet. On laisse faire le front en angular par un presta, on se charge de la gateway et d'un microservice de test.
Les deux en PHP 7, Symfony 4, MariaDB avec docker pour gérer tout ça.

Pas plus mal de pouvoir se faire les mains sur un poc du coup

yaugOn laisse faire le front en angular par un presta

Tout ça à cause de l'infographie sur la roadmap pour devenir développeur web

GuybrushTout ça à cause de l'infographie sur la roadmap pour devenir développeur web

haha
Nan, c'est surtout une question de délai. On va ensuite réinternaliser les compétences en angular mais pour des raisons de calendrier, si on doit attendre d'être à l'aise en angular, on ne pourra pas respecter les délais.

yaugsi on doit attendre d'être à l'aise en angular, on ne pourra pas respecter les délais.

Je suis réceptif à cet argument
J'avais eu l'occasion de jouer un peu avec Angular 2 et de parler (beaucoup) avec des devs qui s'en servaient au quotidien, et tous étaient du même avis : il est impossible de se sentir réellement à l'aise avec Angular

C'est encourageant :D
J'étais plus parti sur du vuejs, c'était aussi l'idée originale dans la boite, mais on a racheté un logiciel dont le front est en angular (1 en migration vers la 2), et du coup par pragmatisme technique, on va garder la même techno front.
J'ai testé un peu angular durant une journée pour un test technique chez Jamendo, il faudra que je me fasse un mini projet dessus voir vraiment ce que ça peut donner.

yaugY'a un topic pour ça à côté

krapouOuais, mais c'est tellement particulier chez nous que à part vous faire rire (et peur) que je ne suis pas sûr que vous pourrez en tirer un quelconque bénéfice.

yaugbah au pire c'est un "ce qu'il ne faut pas faire" :p
Et du coup c'est toujours intéressant comme retour aussi.

krapouPromis, je ferai un retour à côté.

Yaug voulait du retour d'expérience sur les migrations vers du micro-service.

Je vais tenter de partager la façon dont ça a été fait chez nous.

Pour placer le contexte, je bosse sur un gros site (~30 millions de pages vues chaque mois), je suis développeur front, et je suis dans cette entreprise depuis 3 ans.

Le site existe depuis les débuts d'internet, donc il doit être pas loin d'avoir le même âge que la Lexpage

Donc quand je suis arrivé, nous avions plusieurs monolithes, notamment un site web, un site web pour les mobiles (déployés sur des applications IIS différentes) et pour quelques autres sites (les serveurs frontaux devaient de mémoire servir 5 sites différents).

Pour déployer ces sites, on utilise – car ils sont encore en partie utilisés – une interface web qui nécessite de cliquer partout pour faire toujours la même chose mais en ajoutant plein d'erreurs humaines potentielles partout (on a hier – pour un clic oublié lors du processus de déploiement – fait un revert de la prod à la version précédente en voulant livrer la version suivante).

Au niveau de la stack, on avait un back-end en .NET avec des bases relationnelles en SQL Server, et un front-end avec une solution propriétaire maison, qui était une sorte de Smarty, plus vieux, moins performant, moins documenté et beaucoup moins simple d'utilisation.

L'organisation du travail était à l'ancienne, avec deux équipes d'une vingtaine de développeurs, l'une pour le développement des fonctionnalités, et une autre de taille équivalente pour assurer la maintenance.

L'arrivée d'un nouveau manager et les départs du CEO et d'un CTO à l'ancienne ont été le déclic pour commencer à changer les choses. De nouvelles notions ont été injectées dans l'entreprise, comme la qualité et les performances ont été de nouveaux combats. Les deux équipes qui travaillaient sur le site ont été dissoutes, on est passé à l'Agilité en implémentant Scrum, et on a créé des équipes avec chacune un périmètre précis. On a maintenant 7 équipes qui travaillent sur le site, toutes avec une petite dizaine de personnes.

Une fois cette restructuration effectuée, toutes les équipes ont eu à travailler sur le découplage des différentes applications. Un des sites annexex pouvait par exemple appeler une méthode d'un autre directement (au hasard le site mobile qui utilisait le même back-end que le site desktop). Le site mobile a été supprimé et réintégré au site classique en responsive (on est en 2017, on était pas en avance sur le reste du monde), les autres sites – gérés par des équipes dédiées – ont tous été refait au propre from scratch et utilisent leur propre back-end et front-end, entièrement découplé du site principal.

Si nous, sur le gros site n'avons pas terminé, les autres sont pour certains partis dans le cloud AWS, avec un front-end refait entièrement avec des technos un peu plus modernes que ce fameux framework propriétaire. Les échanges de données entre les différents sites et les différentes équipes se font dorénavant via des webservices – généralement des appels GET ou POST. Je ne parle pas de REST parce qu'on ne fait pas vraiment autre chose que de la lecture – et chaque équipe est donc autonome et à la pleine responsabilité d'assurer la maintenance et la disponibilité des endpoints qu'elle gère.

On va passer à un peu moins macro et je vais parler un peu plus de mon équipe, qui est responsable de tout ce qui à trait à la recherche. Le backend était attaqué par plein d'équipes différentes avec du code Legacy qui nous avait été confié lors de la création des différentes équipes. Du .NET avec des macros qui vont chercher la data, nous les balancent telles qu'elles dans des templates de notre moteur de rendu, et les devs front se démerdent. Comme on était très limité pour pousser de nouvelles fonctionnalités et également pour maintenir l'existant¹ nous avons réécrit entièrement le backend pour utiliser des versions plus récentes du .NET framework, fournir les résultats via des endpoints et pas via le système dégueulasse d'avant, rendre ces endpoints accessibles aux différentes équipes, etc… Et le front end a été également – pour le moteur de recherche en lui même – été entièrement découplé du reste du site. On a un module NPM qui permet d'intéragir avec les endpoints.

Une fois tout ça fait, on a commencé à réécrire l'intégralité de nos pages. Un choix technologique a été imposé (une sorte de consensus), et on est parti sur une notion de sites autonomes. Le monolithe était partagé par tout le monde, changer un wording nécessitait de tout relivrer, ce qui prenait quelques heures (oui, oui, des heures). Chaque équipe va donc réécrire les sites à sa charge à partir de zéro, avec un front-end en React/Redux, du Server Side Rendering, de la migration vers Github et vers AWS (depuis respectivement bitbucket et des serveurs à nous dans un data center). On doit donc tout découper pour faire de l'intégration continue avec Teamcity, du déploiement via Octopus et de l'injection à la volée avec un reverse proxy NGINX (une url correspondant donc à l'aggrégation par NGINX de plusieurs sites indépendants : Le menu appartient à une équipe, le cœur de page à une autre, les webservices à une troisième, etc…).

Dans les faits, c'est horrible. Quand je fais une modification, je dois livrer mes modifications à plein d'endroits différents.

L'équipe qui gère le footer fait une mise à jour ? Ils doivent aller voir les 6 autres équipes et leur demander de modifier la version de leur paquet NPM, de générer un package-lock.json, de pousser et tagguer leurs modification, faire passer la QA pour une phase de TNR, générer ensuite un package Octopus et déployer en prod, avant de faire un smoke-test pour s'assurer que tout va bien.

Bref, c'est long, et ça c'est si c'est un package simple à implémenter. On peut imaginer également que le NPM qui fournit toute l'UI est modifier, là il faudra modifier à la main tous les NPM qui l'utilisent, puis générer de nouveaux tags, les incorporer dans les NPM qui l'utilisent, etc, etc…

Pour synthétiser : Le passage aux micro-services s'est donc fait, mais peut-être pas de façon assez globale : Presser les équipes dans leur migration pour casser le monolithe sans anticiper sur une façon pérenne de travailler nous fait recommencer cycliquement tout le travail. Dans notre cas c'est malheureusement une façon de penser propre à l'entreprise.

Mais tout ce que je vous souhaite, c'est de voir grand, mais de penser simple.

- Est-ce que votre structure est compatible avec votre workflow ?
- Comment allez-vous répartir les responsabilités des différents micro-services ?
- Etc…

1. C'est une longue histoire.

Merci pour le retour !

Je me demande s'il existe une seule expérience de passage aux micro-services qui se soit réellement bien passée

Bah de rien.

C'est pas très clair et précis, et c'est que des choix technos que je n'aurait pas fait, mais j'ai tendance à mettre des notions éthiques dans mes choix.

Je ne ferai jamais un choix pour du propriétaire ou pour de l'Open Source par des boites du Gafam.

Donc j'évite d'imposer ma vision, car mon «éthique» ne sert pas forcément les intérêts et la vision de la boite.

Mais pas sûr pour le coup que leurs choix sont mieux que ce que j’aurais fait