Drupal
15/05/2017

L'avenir de Drupal - Part 2 sur 3 - La fin du monolithe

Drupal la fin du monolithe - Photo Penyaskito
La suite des réactions suscitées par la publication du post de Dave Hall intitulé "Drupal, we need to talk" (19/04/2017). Seconde partie de réflexion : La fin du monolithe. - Par @lcoullet :)

Cette suite d'article participe au déferlement de réactions suscitées par la publication du post de Dave Hall intitulé "Drupal, we need to talk" (19/04/2017). Les commentaires sur le blog de Dave ont été nombreux. Les discussions en interne aussi. Voici quelques éléments de nos échanges ventilés en 3 posts : 

Partie 2/3 : La fin du monolithe

In the five years Drupal 8 was being developed there was a fundamental shift in software architecture. During this time we witnessed the rise of microservices. Drupal is a monolithic application that tries to do everything.

Treaduction : Pendant les 5 années de développement de D8, il y a eu un changement de paradigme fondamental dans l'architecture logicielle. Durant cette période nous avons été les témoins de la progression des microservices... (Alors que) Drupal est une application monolithique qui essaye de tout faire.

Nous entrons ici dans le vif du sujet.

Pour revenir au marketing, rappelons-nous tout d'abord que nous avons tous vendu Drupal comme le monolithe ultime. Si si rappelez-vous, schématiquement c'était quelque chose de ce type :

  • Wordpress est très bien pour faire un blog ;
  • Avec SPIP (Joomla, etc.) vous pouvez faire un portail d'information ;
  • Avec Prestashop et Magento, un site e-commerce ;
  • Mais avec Drupal mes amis, quel régal, vous pouvez faire tout cela à la fois ! Commencez par l'un des 3, rajoutez des modules et soyons fous avec Workbench, Rules et Services vous l'aurez votre application métier, portail communautaire, e-commerce en 26 langues…

Nous ne sommes pas les seuls responsables, nous avions aussi en face des institutions ou des entreprises qui y croyaient également dur comme fer et qui avaient de bonnes raisons de ne pas s'éparpiller avec plusieurs technologies différentes.

D'ailleurs, historiquement nous avons fait le choix de Drupal car sa couverture fonctionnelle était bonne dans un peu tous les domaines.

Et puis le monde a changé et la réalité s'est révélée quelque peu différente.

Construire une machine à tout faire avec Drupal c'est réalisable. On vous épargne les errances liées au choix des modules, à leur stabilité, les bugs, les patches et les forks, mais nous avons des développeurs compétents. Cela demande du temps mais ce n'était pas de la publicité mensongère.

Néanmoins, une paille, un grain de sable, une trop forte montée en charge dans cette mécanique bien huilée, l'ajout de nouvelles fonctionnalités et souvent c'est le drame.

Ce n'est pas la faute de Drupal en soit. C'est un magnifique système, largement configurable par des sites builders en back-office, reposant sur des dizaines de milliers de lignes de codes pour tout gérer via une interface graphique agréable.

A chaque requête HTTP, que ce soit en back ou en front-office, toutes ces lignes de codes vont être exécutés. Chaque module va y aller de sa vérification, de ses appels à d'autres modules et

et

et…

et ???

A pardon, on vient d'avoir un timeout, il faut peut-être augmenter la limite du temps d'exécution ou la RAM allouée à PHP…

Les utilisateurs se plaignent d'avoir un back-office aussi réactif qu'une tortue anesthésiée et parallèlement votre administrateur système vous dit que non on ne peut pas augmenter toutes ces valeurs juste pour que cela fonctionne (et pourquoi pas faire un chmod 777 sur l'ensemble des répertoires tant qu'on y est ?).

Et c'est là que les ennuis commencent.

Première solution : la planche à billets ! Augmentons la RAM, rajoutons des fronts, rajoutons des serveurs MySQL. Cela peut marcher un temps, et il vaut mieux ne pas être celui qui paye la facture.

Avec un peu d'expérience vous auriez pu prévoir cela, séparer le BO et le front sur 2 domaines distincts, utiliser Varnish, invalider le cache selon certaines règles, passer par du JS pour afficher le nombre d'items dans un panier, etc. etc. Et puis tant qu'à faire inclure l'admin-sys dès les premières phases de la conception pour anticiper les problèmes. Bref vous auriez pu scinder l'application en… Ah pardon on avait dit monolithe !

Enfin dans tous les cas, ce joli monolithe de la V1 sera mis à mal à chaque rajout de features et très vite toute l'équipe aura l'impression de jouer avec le site comme avec un chateau de cartes qui avance à la vitesse d'un TGV (lui).

Le Web aussi a changé (attention défonçage de portes-ouvertes en approche) :

  • Auparavant pour une institution / entreprise : tout passait par son site internet et de l'e-mailing. Maintenant le site n'est qu'un élément parmi d'autres : réseaux sociaux, appli mobiles, plateformes de diffusion.
  • Vous vous souvenez des commentaires sur les articles ? Maintenant on passe généralement par un service tiers (type Disqus) pour qu'ils apparaissent aussi ailleurs.
  • C'est devenu rare que la gestion d'un catalogue ou d'une médiathèque trouve sa source dans le site internet lui-même, mais généralement la gestion des produits est déportée car le site n'est plus le seul canal de vente.
  • Vous diffusez vos mails via le même serveur que celui qui héberge votre site ? Non, vous passez par un tiers comme Mailjet ou MailChimp et même chose pour le push vers votre application mobile.etc. etc.

Et tout ceci nous amène logiquement aux :

Microservices

APIs

Les premiers sont les blocs constitutifs de votre application, les seconds, les messagers et le ciment qui assurent la cohésion et la bonne communication entre toutes les parties.

Place aux jeunes ?

Today it is more common to see an application that is built using a handful of Laravel micro services, a couple of golang services and one built with nodejs. These applications often have multiple frontends; web (react, vuejs etc), mobile apps and an API. This is more effort to build out, but it likely to be less effort maintaining it long term.

Traduction : De nos jours il est courant de voir qu'une application est construite à l'aide de plusieurs microservices en Laravel, quelques services en Go et un autre en NodeJS. Ces applications ont souvent plusieurs fronts : web (react, vues, etc.), applications mobiles et API. C'est plus compliqué à construire mais au final plus facile à maintenir sur le long terme.

Nous nous y somme mis également. Nous avons dans les tuyaux une application avec :

  • Drupal 8 pour la gestion de contenu et des actualités ;
  • Un applicatif Phalcon (PHP) pour la couche métier ;
  • Plusieurs APIs en entrée et en sortie (ex : e-mailing) ;
  • Plusieurs fronts avec VueJS / Volt (template Phalcon) et Drupal.

Oui c'est la tendance et notre quotidien. Il est de plus en rare de ne pas trouver un projet conséquent sans interfaces avec d'autre systèmes. Drupal n'étant plus dès lors qu'un maillon de la chaîne parmi d'autres.

Sans vouloir casser du sucre sur Laravel (ou Symfony ou Phalcon ou mettez ici votre framework préféré), la réalité n'est pas aussi simple.

C'en est fini de Drupal, toute votre équipe de développement se met à Laravel, bon vent ! Bon vent ?

En quelques heures, vous voilà avec un petit CRUD et un back-office joliment scaffoldé.

Côté front, c'est du simple et direct, les themeurs n'ont pas à prendre leur GPS pour comprendre où se trouve telle ou telle fonction. La dernière librairie JS du moment s'intègre elle-aussi simplement dans pipeline de gestion des assets, sans interférer avec quoi que ce soit.

Pas de magie, pas de fonctions cachées, rien de plus ni rien de moi que ce que le client a demandé.

Les performances sont excellentes, un sentiment de puissance s'empare de vous…Driiiing ! Le téléphone sonne, c'est votre client. Il veut rajouter un champ supplémentaire dans son interface de saisie.

En soit rien de bien méchant, quelques minutes de développement back supplémentaire et autant pour le front.

Dring, Dring ! C'est à nouveau votre client qui veut changer l'intitulé d'un champ en back-office et rajouter une petit texte explicatif à l'intention des rédacteurs. Il ne comprend pas trop pourquoi tout doit passer par du développement (même minime) alors qu'avec Drupal il n'avait même pas à vous avertir de quoi que ce soit pour ce genre d'opérations. Ah et puis, ce serait bien d'avoir un système complet de gestion des mots de passes et d'envois de mails de bienvenue. Il pourra changer le texte à tout moment n'est-ce pas ?

Vous et vos développeurs perdez peu à peu le goût de la vie.

Eux parce qu'ils en sont réduits à des tâches peu gratifiantes et vous parce qu'il devient de plus en plus difficile de justifier le recours systématique à du développement pour ce genre de petites choses.

Bon ce n'est pas la peine de continuer non ? Vous avez compris. Il vous faut un bon CMS…

Effectivement, il y a de bons composants CMS pour Symfony et Laravel, mais franchement vous en aviez déjà un bon sous la main n'est-ce-pas ?

Reste la question de la performance.

Ici, je ne veux pas dire de bêtises, je n'ai pas assez de benchmarks en ma possession. Sans doute quelque chose de simple avec un Framework récent et un module de CMS simple devrait s'en tirer avantageusement par rapport à un site Drupal 8, mais mécaniquement plus vous rajouterez de fonctionnalités…Plus vous y passerez de temps (alors que sous Drupal 8, il y a déjà pas mal de bons modules contribués)...Plus l'écart de performance se réduira.

La morale de cette histoire c'est que si vous avez besoin d'une gestion de contenu qui n'est pas basique et/ou si le projet va évoluer vous n'avez pas énormément de ressources pour toutes les technologies nécessaires, Drupal 8 n'est pas un si mauvais cheval sur lequel parier...

@lcoullet

A suivre...