DevOps life (français)

Comment j’ai hacké la liste d’attente de ma box de CrossFit avec l’IA (et pourquoi ça a changé mon regard sur le code assisté par IA)

Tristan Bessoussa — Thu, 28 Nov 2024 00:00:00 GMT

CTO, je ne code presque plus, et je n’aurais jamais cru me remettre à développer une application de zéro… jusqu’à ce que mon addiction au CrossFit et l’IA unissent leurs forces. Voici comment l’IA générative m’a permis de faire passer mes chances d’obtenir une place dans les cours de CrossFit les plus demandés de 20% à 90%.

Le problème : la galère des réservations

Depuis deux ans, je me bats avec le système de réservation de ma box de CrossFit. Les cours sont pris d’assaut : il faut réserver jusqu’à 14 jours à l’avance. Vous avez raté le coche ? Bienvenue dans l’enfer de la liste d’attente, souvent longue de 15 personnes pour les créneaux tant convoités de l’après-boulot.

Le hic : je suis incapable de m’organiser à l’avance. Mon seul espoir, c’était de bondir sur les notifications d’annulation, mais même mon pouce ultra-rapide n’y suffisait pas. Pourquoi ? Les notifications push arrivaient avec jusqu’à une minute de décalage d’un utilisateur à l’autre. Même en cliquant dans la seconde, je ratais la place 80% du temps.

Le déclic

J’ai codé pendant une dizaine d’années avant de m’éloigner du clavier, et je savais qu’il y avait forcément mieux à faire. La solution était évidente : pourquoi attendre des notifications push en retard, alors que je pouvais interroger directement l’API (qui n’est d’ailleurs pas publique) ? Seul bémol : si le principe était simple, le paysage du développement avait beaucoup changé depuis l’époque où je codais.

L’IA entre en scène : un binôme de code inattendu

La semaine dernière, j’ai décidé de mettre à l’épreuve tout ce battage autour du « code assisté par IA » que je voyais passer sur les réseaux sociaux. Armé de Cursor et de Claude, je me suis lancé dans mon plan diabolique pour optimiser ma vie de sportif.

Le processus a été fascinant :

J’ai commencé petit, en demandant à l’IA de créer une interface qui affiche les cours disponibles, le nombre de participants et la longueur des listes d’attente
J’ai extrait les appels réseau (.HAR) de l’application web officielle et je les ai donnés à Claude
En moins d’une heure, j’ai eu mon premier moment « waouh » : ce qui m’aurait pris 4 heures avec ma stack habituelle, je l’ai fait en terrain inconnu (Astro et React)

Retour sur terre : l’IA n’est pas magique, c’est un partenariat

Travailler avec l’IA n’a pas été un long fleuve tranquille :

Parfois, c’était comme travailler avec un enfant brillant mais distrait
Elle oubliait le contexte (« Tu as généré du React pur, mais on est dans un projet Astro, tu te souviens ? »)
Ajouter une fonctionnalité pouvait en casser une autre (il faut croire que l’IA a quelques travers de développeur bien humains 😅)

La clé, c’était d’apprendre à lui fournir le contexte efficacement, en partageant des fichiers précis ou tout le périmètre du projet, pour obtenir des solutions cohérentes.

Le point de vue du CTO : une prise de conscience décisive

Cette expérience a transformé ma vision des outils d’IA dans le développement. Une partie de mon équipe utilise déjà GitHub Copilot ou Cursor, mais c’est ce projet perso qui m’a révélé le vrai potentiel du développement assisté par IA. Il ne s’agit pas de remplacer les développeurs, mais de former un vrai binôme avec les outils d’IA.

Ce que j’en retiens

Des besoins clairs, ça compte : l’IA a besoin d’un périmètre et d’attentes bien définis
Le contexte est roi : le facteur limitant, c’est souvent la communication humaine ; une demande floue donne un résultat flou
Accepter le changement : la tech évolue sans cesse ; les concepts fondamentaux restent, mais les outils et les frameworks changent
L’IA comme levier : elle peut aider les développeurs expérimentés à travailler plus efficacement avec des technologies qu’ils ne connaissent pas.

Pour les développeurs expérimentés, l’IA peut vraiment changer la donne : elle leur permet de travailler bien plus vite, même avec des technologies qu’ils ne maîtrisent pas.

Pour les développeurs juniors, c’est un formidable outil d’apprentissage, qui accélère leur compréhension des nouvelles technologies. Il y a toutefois un revers : trop s’appuyer sur l’IA pourrait les empêcher d’acquérir des compétences essentielles et de comprendre en profondeur ce qui se passe « sous le capot ».

Pour les profils non techniques, en 2024, il est sans doute encore un peu tôt pour créer de zéro du code pleinement fonctionnel sans bases techniques. En revanche, l’IA est une excellente aide à la communication : elle leur permet d’exposer leurs idées aux développeurs avec plus de clarté et de précision. À l’heure actuelle (et cela pourrait changer), je ne vois pas l’IA remplacer les développeurs : ce projet m’a demandé de mobiliser mon expérience et mes connaissances.

P.-S. : mon plan diabolique a-t-il fonctionné ? Absolument. Mon taux de réussite pour décrocher les créneaux de CrossFit libérés par une annulation est passé de 20% à 100%. Surtout, je n’ai plus besoin de rester sur le qui-vive en permanence, prêt à me jeter sur mon téléphone à la moindre notification d’annulation. Parfois, les meilleurs projets de code naissent d’un besoin égoïste !

Cet article a été écrit par Tristan Bessoussa, CTO chez Wamiz (Nestlé), où j’explore des façons de marier la technologie et les solutions concrètes… quitte à détourner le système pour mieux m’entraîner ! 💪

Cet article a ensuite été amélioré par l’IA, et si vous l’avez lu jusqu’au bout, c’est que l’IA écrit mieux que moi

Un environnement de développement sain en 2021. Bonjour Docker, bye machines virtuelles

Tristan Bessoussa — Wed, 28 Apr 2021 00:00:00 GMT

Contexte

Depuis mai 2015, le modèle chez Yproximité de “tout installer à la main en local en 1/2 journée” a été abandonné pour une solution basée sur une machine virtuelle, configurée à l’aide de playbook Ansible afin qu’en une commande, l’environnement de développement soit opérationnel après quelques minutes.

Les prérequis pour faire tourner les projets Symfony consistait à installer :

Make, afin de lancer les commandes

VirtualBox, pour la VM
Vagrant, afin de piloter la VM
Vagrant Landrush, un DNS pour accéder aux URL de développement
mkcert, pour générer le certificat TLS local

L’utilisateur était alors invité alors à exécuter dans son terminal make setup, puis une vingtaine de minutes plus tard, le projet était complètement opérationnel, les données de la base de données importés et toute l’équipe sur les mêmes versions mineures de PHP, Nginx, PostgreSQL.

❤️ Je tiens d’ailleurs à remercier les contributeurs du projet manala.io porté par mon ancienne agence web, Elao et notamment Nervo qui maintient les différents rôles Ansible. Merci pour leurs contributions open source et d’avoir permis de faire tourner notre usine de développement pendant 6 ans.

Nous sommes maintenant en 2021. Qu’est-ce qui m’a poussé à prévoir ce changement d’usine de développement et à abandonner ce modèle de machines virtuelles (VM) ?

Pourquoi s’éloigner du modèle machines virtuelles ?

Plusieurs arguments étaient pour l’abandon des VM :

Docker qui devient de plus en plus mature et qui a un bon taux d’adoption dans la communauté web sur les environnements de développement.
Les performances un peu en retrait (surtout sur Linux si j’en crois mon équipe) par rapport à une installation locale du projet.
Le poids des machines virtuelles (compter plusieurs Go par projets)

Néanmoins, l’idée d’adopter une usine de développement uniquement basée sur Docker m’a énormément freiné. Avec une équipe réduite et sans compétence Docker particulière (notamment pour les problématiques de performances macOS vs Linux) ce choix s’avère risqué pour la stabilité de l’environnement de développement, qui doit être là pour permettre aux développeurs d’être le plus productif, et non pas comme étant une source de frustration, ou de ralentissement.

Je savais que les VM allaient bientôt être poussées vers la sortie, mais était-ce suffisant pour arrêter une date butoire de transition vers autre chose ? Prévoir un plan de formation ? Faire évoluer nos dizaines de projets vers un autre environnement de développement basé sur du Docker ? Pas tout à fait…

L’élément qui à permis de faire basculer la balance vers “autre chose” est l’annonce discrète par l’équipe de VirtualBox qui dit ne pas pouvoir techniquement porter VirtualBox sur un processeur ARM. VirtualBox, qui fait tourner les VM, est un hyperviseur, et non un émulateur CPU. VirtualBox ne peut donc pas émuler un processeur x86.

En quoi c’est gênant ? Et bien peut-être avez vous raté l’annonce d’Apple de leur plan de transition vers une architecture ARM sous 2 ans environ en débutant par leur puce “M1” (qui envoie du lourd), équipant les MacBook Pro 13”, le MacBook Air et le Mac Mini. Il semblerait même que devant les retours extrêmement positifs des utilisateurs, la firme ait même acceléré le déploiement de la nouvelle architecture ARM en annoncant il y à quelques jours les iMac 24” et les iPad Pro avec la puce M1. Pour le grand public, il ne reste donc plus que le MacBook Pro 16” et l’iMac 27” à sauter le cap.

Illustration du processeur d'Apple sous architecture ARM baptisé M1

Je vois venir les trolls d’Apple au loin, mais dans mon équipe, j’ai toujours eu à cœur de proposer aux développeurs/euses le choix entre du Linux et du macOS (voir baromètre AFUP pour les répartions d’OS). Donc merci de rediriger les troll vers les seuls qui le méritent : les devs PHP/JS sous Windows.

Une solution propulsée par Docker, mais pas que !

Dans mon contexte d’entreprise et d’équipe, une solution basée uniquement sur Docker est compromise tant que le problème de performance soit définitivement reglé sur Mac ou qu’il y ait besoin d’une ressource experte Docker/Linux pour implémenter la solution.

J’ai donc choisi de pousser l’adoption d’une solution hybride afin d’éviter les volumes partagés (et donc pas de problème de performances). Il semblerait, d’après ma mémoire de SymfonyLive que ça soit aussi le choix de Fabien Potencier.

Sur la machine hôte (macOS/Linux) :

PHP et composer
NodeJS
Docker Desktop
Symfony CLI. Ce dernier offre un serveur web avec gestion du TLS, le support docker, et la gestion des versions de PHP spécifiques.
Binaire Manala (Permettra de générer votre docker-compose.yaml d’après un template. Voir aller plus loin)

⚠ Malgré tous les avantages qu’offre Symfony CLI, ce dernier n’est pas open source. C’est à noter, surtout si on se repose dessus pour une usine de développement.

Avec Docker :

Base de données (MySQL, PostgreSQL, MariaDB…)
Serveur Redis

Liste des containeurs Docker

L’expérience de développement avec cette nouvelle stack hybride est vraiment très plaisante et rapide, je retrouve les performances natives de ma machine.

Aller plus loin

Hugo Alliaume a repris le POC que j’ai réalisé en Août 2020 et levé tous les points de bloquages. Il s’est saisi de la problématique à bras le corps et a mené le projet de transition à son exécution sur tous les projets de l’équipe R&D.

Il a abordé des parties plus techniques dans sur son blog, notamment :

Une analyse plus poussée des limites des VM et des workaround nécessaires
Pourquoi remplacer son serveur web / reverse proxy et gestion DNS local par Symfony CLI
Un exemple de docker-compose.yaml
Comment tirer profit de cette stack de développement pour le CI, avec GitHub Actions ?
Comment aller plus loin avec le binaire manala pour faciliter la gestion et la maintenance (ex: Makefile)

📖 Je vous invite à lire son article : migration de notre stack de développement vers Docker.

Installation des prérequis sous macOS

Ce chapitre s’adresse aux utilisateurs sous macOS 🍎 qui souhaiteraient retrouver ici toutes les procédures d’installation des outils sur votre machine.

Prérequis

Installation de brew le gestionnaire de paquets pour macOS.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Installation de Zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Installation de PHP

brew install php # installe la dernière version stable de PHP, soit la version 8.0.x à l'heure ou j'écris cet article.
brew install php@7.4 # installe php 7.4

brew install composer

Si vous avez des projets sous différentes versions de PHP, pas de soucis, installez toutes les versions de PHP nécessaires à vos projets, Symfony utilisera la bonne version grâce au fichier .php-version déposé à la racine de votre projet.

Détection des différentes versions de PHP installées sur votre machine tel que vu par le binaire Symfony

Installation de NodeJS

brew install node # installe la dernière version stable de NodeJS, soit la version 16.0.x à l'heure ou j'écris cet article.
brew install node@14 # installe la nodeJS 14

brew install yarn # si vous avez besoin du gestionnaire de dépandance JS Yarn

Sur le même schéma, si vous avez des projets sous différentes versions de NodeJS, installez toutes les versions nécessaires à vos projets, nous utiliserons nvm qui permet d’utiliser la bonne version de node selon le projet (la version étant contenue dans le fichier à la racine du projet .nvmrc).

brew install nvm

Enfin lorsque vous lancerez votre yarn install ou yarn dev-server pour éviter de faire un nvm use pour sélectionner la bonne version de nodejs, vous pouvez ajouter ce bloc dans votre ~/.zshrc (puis relancer votre terminal, ou executez source ~/.zshrc). Cela aura pour effet de regarder si dans votre chemin courant, un .nvmrc existe avec une version de node spécifique au projet, et l’utilise, si elle est installée.

export NVM_DIR="$HOME/.nvm"
[ -s "/usr/local/opt/nvm/nvm.sh" ] && . "/usr/local/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/usr/local/opt/nvm/etc/bash_completion.d/nvm" ] && . "/usr/local/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion

# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

Bonus avec mux et tmuxinator

Si vous travaillez avec un projet Symfony contenant du JS ayant besoin d’être compilé, vous allez surement avoir besoin de 3 onglet de terminal:

Une session sur symfony serve le webserveur
Une session à la racine de votre projet
Une session sur yarn dev-server pour compiler votre Javascript quand il est modifié.

Pour gagner en confort, je vous suggère d’utiliser iTerm2 avec le multiplexer de terminal tmux. Il permettra de scinder vos terminaux en terminaux virtuels et de pouvoir les splitter. Concrètement, quand je lance dans mon terminal mux start <nom_du_projet> j’ai automatiquement mes containers qui se lancent, mon split de terminal qui se fait, et yarn dev-server dans un onglet virtuel comme ci-dessous.

Illustration du binaire Symfony CLI, sur la gauche, différentes étapes pour booter le projet, sur la droite le serveur web lancé par `symfony serve` qui traitera vos requêtes

Pour profiter de la même chose:

brew install tmux
brew install tmuxinator

puis rajouter l’alias dans votre ~/.zshrc

alias mux=tmuxinator

puis la configuration d’un projet est assez basique

mux open <nom_du_projet>

et configurer votre projet à l’aide de la documentation de tmuxinator, comme par exemple :

# /Users/t.bessoussa/.config/tmuxinator/<nom_du_projet>.yml

name: <nom_du_projet>
root: ~/workspace/<mon_projet> # Chemin de votre projet

# Run on project exit ( detaching from tmux session )
on_project_exit: make halt

# Run on project stop
on_project_stop: make halt

windows:
  - php:
      layout: main-vertical
      panes:
        - make setup
        - symfony serve
  - js:
    - sleep 70 # on attends un peu vu que mon make setup va lancer un build js de dev qui rentrerait en conflit avec le dev-server
    - yarn dev-server

Il ne vous reste plus qu’à retenir mux start <nom_du_projet> et mux stop <nom_du_projet> et le tour est joué.

Une typo ? L’article est disponible sur mon dépôt Github

Essai du PaaS Suisse, Hidora

Tristan Bessoussa — Tue, 19 Jan 2021 00:00:00 GMT

Ce billet s’inscrit dans la suite d’une série d’articles visant à faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série initiale :

Bien que ma quête pour héberger notre parc de WordPress s’est achevée fin 2019, j’ai décidé de tester Hidora, un PaaS suisse 🇨🇭.

Hidora

Accéder au résumé si vous êtes pressés

Build de l’application sur Hidora

Hidora propose des installations préconçues pour les principaux CMS, néanmoins, il n’est pas possible de choisir l’édition de WordPress désirée et l’unique proposée est l’édition basique, et non Bedrock.

Comment build notre WordPress qui nécessite d’installer les dépendances composer et javascript ?

Plusieures difficultés se sont posés pour arriver à déployer notre projet avec WordPress - Bedrock:

Les environnements PHP chez Hidora n’embarquent aucune runtime Node.js, il n’est pas possible d’y faire yarn install && yarn build pour générer les fichiers css et js. Il a donc fallu identifier la distribution sur laquelle tourne le scaler (CentOS), puis installer Node.js, puis yarn à la main sur le noeud PHP en SSH, en ayant au préalable demandé au support de nous mettre les droits root sur notre environnement.
Lorsque nous devons personnaliser le script de “post deploy” pour y rajouter notre composer install, nous nous attendons à être à la racine du dossier contenant notre application déployée, ce n’est pas le cas. Il n’a pas été facile de savoir ou se rendre pour rentrer dans notre répertoire applicatif (cd $WEBROOT/app).
Il n’y a malheureusement pas de multi-edition des variables d’environnements. J’ai du en saisir 30 à la main, une par une: c’est long. Avoir une zone de texte éditable pour pouvoir coller toutes nos variables aurait été plus rapide.

Je pense que la frustration ressentie face à ces nombreuses problématiques/questions peuvent être réglées par l’édition de “cookbook” pour répondre aux questions que les nouveaux clients doivent se poser quand ils arrivent sur Hidora (ex: Comment déployer une application Symfony, WordPress…). Les seuls guides que j’ai trouvés sont ceux de la solution qu’à choisi Hidora pour exploiter son cloud: Jelastic.

Capture d’écran de l’interface d’administration :

Performance chez Hidora

Voilà une des typologies de l’infrastructure faisant tourner le WordPress. Les visuels viennent faciliter la compréhension et les ressources allouées.

Exemple : J’envoie 5 visiteurs uniques par seconde pendant 2 minutes sur la page d’accueil. Pas d’optimisations excepté le pm.max_children réglé sur 10.

Pour 10,8€/mois chez Scalingo, j’obtiens 492ms de moyenne de temps de réponse.

Pour 15,7€/mois chez Hidora, j’obtiens 2 048ms de moyenne de temps de réponse.

Les performances ne sont donc pas bonnes par défaut. Je pense qu’il serait possible d’obtenir de meilleurs performances, mais n’ayant eu à appliquer d’autres améliorations sur les autres plateformes testés, je ne l’ai pas fait ici non plus.

Pour plus de détail, voir :

Part7. Comparatif PaaS : Les performances, Clever Cloud VS Scalingo VS Hidora

Notons qu’Hidora propose une tarification à la ressource réellement consommée. Nous pouvons reserver 2Ghz/2Gb de RAM, et dire que nous autorisons jusqu’à 6Ghz/6Gb de RAM consommés. Si votre applicatif consomme par moment 3,4Ghz de CPU, vous serez facturé uniquement sur la base de cette consommation, et non la borne maximale (6Ghz) choisie ce qui permet de mieux maitriser les coûts lors de pics de charge.

Résumé Hidora (TLDR)

👎 Inconvénients

Interface basé sur Jelastic: complexité de l’interface, peu sexy.
L’interface Jelastic aurait pu être plus orienté UX.
La flexibilité peut introduire des mauvaises pratiques (= modifications à la main sur le serveurs de fichiers de config)
PaaS pas vraiment 100% “PaaS”: on se retrouve à installer des choses manuellement en SSH via apt
Le build de l’application se fait sur la même machine qui éxecute le code. J’ai dû augmenter la RAM disponible de la plateforme juste pour le build, alors que pour le run, il n’y en avait pas réellement besoin.
Pas de possibilité de déporter facilement (1 click) le build de l’application sur un scaler, plus gros, à part afin de ne payer que la consommation de ce scaler au moment où l’on en a besoin.
Performances brutes par défaut (sans avoir à faire des optimisations)
Le support ne propose pas un canal “live chat”

👍 Avantages

Interface basé sur Jelastic: les ressources internes sont dédiées à autre chose que développer l’UI.
Très flexible (accès root, sFTP, ssh). C’est top si vous avez beaucoup d’intégrations qui ne sont pas supportés par d’autres PaaS.
Beaucoup de technologies supportés, dont Docker
Le support qui à pris le temps de répondre a certaines problématiques par visioconférence, en écran partagé.
Les data sont hébérgées en Suisse.
Les ressources consommées sont celles réellement facturées lorsque l’on utilise des ressources flexibles.

Verdict

Je ne suis pas sûr d’être en mesure de recommander Hidora dans le scénario ou un développeur serait chargé de configurer et déployer un applicatif (comme on peut le retrouver dans des petites équipes). En effet la couche d’UI fournie par Jelastic est, je trouve, assez complexe à prendre en main et l’expérience nécessite plus de compétences “infra / ops / run” que d’autre hébergeur 100% PaaS que j’ai évoqué dans cette série d’articles.

On peut se retrouver à faire des opérations hybrides entre de la configuration au travers de l’UI, comme l’on peut s’y attendre pour un PaaS. Mais, de manière plus surprenante, on peut aussi avoir à modifier via sFTP ou via SSH des fichiers de configuration (php.ini, vhost.conf) ce qui donne l’impression de configurer un serveur dédié ou un VPS.

Pour les clients qui découvrent l’interface Jelastic, utilisé par Hidora, le partage d’écran avec le support est nécessaire pour y voir plus clair.

⚠️ Mon avis sur cet hébérgeur ne concerne que l’utilisation que j’en ai faite. Honnêtement, je ne suis pas sûr que mon cas d’utilisation tire le meilleur parti de cet hébérgeur ⚠️

Comment le serverless nous a sauvé la mise pour 2 $

Tristan Bessoussa — Fri, 06 Mar 2020 00:00:00 GMT

Ces derniers mois, vous avez sûrement vu passer les mots « serverless » ou « FaaS » (Function as a Service), en vous demandant : « Bon, simple effet de mode, ou il y a vraiment quelque chose à y gagner ? »

Je vous propose un retour d’expérience sur un cas concret, rencontré dans l’entreprise où je travaille : il montre pourquoi le passage au serverless nous a permis de répondre au besoin.

Pour y arriver, nous avons utilisé les produits, frameworks et bibliothèques suivants :

Mon équipe travaille avec PHP7, Symfony et Vue.js.

Une coquille ou une erreur dans la version originale ? Vous pouvez contribuer à cet article en proposant une pull request.

Le besoin : générer des rapports statistiques en PDF

Voici les user stories :

« En tant que client du CMS, je dois recevoir chaque mois un rapport PDF contenant plusieurs statistiques sur mon site web »
« En tant que revendeur de ce groupe de clients du CMS, je dois recevoir chaque mois un rapport PDF qui reprend les rapports de chacun de mes clients (une partie de chacun) »

Concrètement, pour les quelques clients qui disposent de cette fonctionnalité, cela fait plus de 2 000 PDF à générer. Voici à quoi ressemble l’un des PDF à générer :

Le PDF obtenu

L’option VPS ou serveur dédié

Vous pourriez mettre en place une tâche cron sur l’un de vos serveurs, qui se chargerait de lancer une commande pour générer les PDF. Le principal problème : ça ne passe pas à l’échelle.

~20 secondes (génération d’un PDF) x 2 000 PDF = 11 heures de génération de PDF

La génération prend 2 secondes en moyenne, mais un PDF lourd, qui contient plusieurs pages de plusieurs rapports, peut demander jusqu’à 30 secondes.

Pendant ces 11 heures, il vous faudrait garantir que la génération tienne la distance (déploiements de l’application, redémarrages du serveur, etc.), et disposer d’un moyen de vérifier que le processus tourne toujours, par exemple avec Supervisor.

Il vous faudrait aussi écrire tout le processus en « programmation défensive », pour que votre code continue de fonctionner face aux imprévus.

Comme notre application est en PHP, elle n’est pas multithread : impossible de tirer facilement parti de tous les cœurs CPU de notre serveur dédié. Pour paralléliser, l’une des solutions consiste à louer davantage de serveurs, qu’il faut ensuite déployer, provisionner et administrer.

L’option serverless

Voici comment s’enchaînent les étapes de notre architecture.

Architecture serverless de génération des PDF, avec 2 applications Symfony.
L’architecture serverless en Full HD.

Diagramme PUML du processus de génération des PDF

Étape 1 : préparer les données

Comme ce PDF agrège de nombreuses données, internes et externes, mieux vaut avoir les données prêtes au moment de le générer. L’application CMS (app #1, PHP/Symfony) se charge de rassembler et de stocker dans une instance Redis toutes les données nécessaires à la construction du PDF.

Puisque l’on vise la scalabilité, il ne faut pas que le service chargé de générer les PDF aille demander les données à app #1 via une API : elle deviendrait un goulot d’étranglement si 3 000 lambdas lui envoyaient des requêtes en même temps.

Étape 2 : créer des messages asynchrones

Une fois toutes les données prêtes, app #1 les met en forme dans un message, qu’elle glisse dans une enveloppe avec Symfony Messenger pour envoyer les messages dans une file Amazon SQS.

Remarque pour les utilisateurs de Symfony : comme les messages seront lus par une autre application (Symfony, elle aussi), vous devez utiliser un sérialiseur de messages personnalisé. Pour en savoir plus, lisez la RFC que j’ai ouverte sur le dépôt de Symfony.

Étape 3 : stocker les messages dans une file d’attente

Dès que les messages arrivent dans la file Amazon SQS, ils déclenchent notre lambda, qui exécute notre code de génération des PDF.

Remarque : la structure de nos messages (un Plain Old PHP Object) est stockée dans un autre dépôt git. Pourquoi ? Parce que app #1 et app #2 ont toutes les deux besoin de ce POPO. Qu’un développeur modifie la structure du message dans app #1 en oubliant de le faire dans app #2, c’était un risque inutile.

Étape 4 : générer les PDF

Jusqu’à 3 000 instances de lambda sont démarrées : là, on parle de scalabilité sérieuse (dans notre cas, nous nous sommes limités à 50 lambdas simultanées). Chaque lambda reçoit un message qui contient les données nécessaires pour générer 1 PDF.

La lambda exécute ensuite notre app #2 (PHP, Symfony), chargée d’afficher une vue dans une page web à partir de simples templates .twig, avec un peu de JavaScript pour dessiner les graphiques.

Le code utilise ensuite Browsershot, qui transforme une page web en PDF : un Chrome headless, piloté par Puppeteer, visite l’URL qui affiche le template .twig, lequel deviendra notre PDF.

Une fois généré, le PDF est stocké dans un bucket S3.

Nous avons utilisé Bref.sh autour de Symfony. C’est génial : Bref intègre votre framework PHP préféré aux lambdas, et fournit différents runtimes PHP qui tourneront sur la lambda.

Les 2 000 PDF sont tous générés en 2 minutes

Étape 5 : envoyer le PDF au client par e-mail

Le schéma d’architecture ne montre qu’une partie de ce qui se passe réellement. Une fois le PDF généré dans le bucket, nous créons un nouveau message, que nous envoyons dans une autre file SQS. Cette file-là fait de nouveau appel à app #2 (mais à une autre partie du code) pour envoyer au client un e-mail avec le PDF en pièce jointe, et pour prévenir l’application CMS : les clients peuvent ainsi télécharger leur PDF depuis le back-office, eux aussi.

Comparatif

	VPS ou serveur dédié	Serverless
Complexité	Faible	Moyenne
Coût	Élevé	Faible
Scalabilité	Complexe	Très scalable

Conclusion

L’un des principaux avantages d’une architecture serverless, c’est que vous n’êtes facturé que pour le temps réellement nécessaire à l’exécution du code.

Vous n’avez pas non plus à vous soucier d’où ni de comment il tourne : vous livrez votre code, et il s’exécute dans le cloud. C’est le fournisseur cloud qui se charge d’allouer les ressources machine.

Dans notre exemple, avec l’offre gratuite d’Amazon Lambda et d’Amazon SQS, générer 2 000 PDF nous coûte ~1,63 $ (1,62 $ pour SQS, 0,01 $ pour Lambda). Pour affiner vos estimations, vous pouvez utiliser ce calculateur de coûts serverless.

Si vous pensez qu’une partie de votre code gagnerait à passer sur une architecture serverless, je vous conseille de commencer par un POC très simple, pour vous familiariser avec ces nouveaux concepts. C’est ce que nous avons fait avec une petite portion de notre code, avant même de nous attaquer au problème des PDF, pour mieux comprendre tout l’écosystème (files d’attente, lambdas, notifications…). Nous avons aujourd’hui 5 lambdas, chacune chargée d’une tâche précise (en dehors des PDF).

Pour aller plus loin, sous un angle plus technique : Generate PDFs on Amazon AWS with PHP and Puppeteer, écrit par Hugo Alliaume, qui nous a beaucoup aidés sur ce sujet. Vous y trouverez de nombreux détails, comme la façon dont nous avons embarqué Chrome dans la lambda.

Travailler avec WordPress sans déprimer

Tristan Bessoussa — Wed, 10 Apr 2019 00:00:00 GMT

Bon, vous avez choisi de démarrer un nouveau projet WordPress (ou quelqu’un l’a choisi pour vous) ? Bonne nouvelle : nous sommes en 2019, et ce n’est plus forcément la galère dès le départ.

Dans cet article, je ne vais pas tout expliquer en détail, il me faudrait un livre entier pour ça. Je vais simplement vous indiquer des pistes : comment faire mieux que la méthode officielle, bancale, qui se justifiait il y a 10 ans. Cet article s’adresse à tout le monde : développeurs web, back-end, front-end…

Promis, il n’y a pas plus de 3 minutes de lecture par chapitre.

Dans l’entreprise où je travaille, nous avons plus de 150 sites WordPress. J’ai décidé que les nouveaux adopteraient tout ce que je décris dans cet article, et que les anciens y migreraient petit à petit. À l’heure où j’écris ces lignes, ~10% d’entre eux utilisent déjà cette architecture.

Remarque : si vous repérez des fautes d’anglais dans la version originale, j’accepte volontiers les pull requests pour les corriger.

Utilisez Bedrock Edition

C’est LE point de départ de cet article. Bedrock est un boilerplate WordPress créé par Roots. Il s’appuie sur des outils de développement modernes et adopte la méthodologie 12 Factor App. Autant de choses que WordPress ne peut pas (ou ne veut pas) faire, à cause de son statut de dinosaure 🦖 du monde PHP.

Voici les principaux avantages de ce boilerplate :

Prise en charge des variables d’environnement

Si vous avez déjà travaillé sur des applications modernes, le principe de stocker la configuration de votre application dans des variables d’environnement vous est familier.

L’intérêt des variables d’environnement, c’est de pouvoir disposer de plusieurs environnements, comme production, staging et development, et par exemple de n’activer l’envoi d’e-mails qu’en production, sans devoir modifier en permanence des valeurs selon l’environnement sur lequel vous vous trouvez.

En 2019, tous les grands frameworks du monde PHP ont une notion de variables d’environnement : Symfony, Laravel, Yii. C’est une pratique courante, qui existe depuis des décennies dans les mondes Windows et Unix.

Les variables d’environnement peuvent être stockées dans un fichier en development, et injectées dans votre serveur web pour les environnements de staging et de production. Pas de panique : beaucoup d’hébergeurs dignes de ce nom proposent une interface pour manipuler les variables d’environnement. Regardez par exemple ce que fait Heroku pour les variables d’environnement.

Des variables d’environnement, ça ressemble à ceci :

DATABASE_URL=mysql://john_doe:p4sSWorD@127.0.0.1:3306/db_awesome_blog
WP_ENV=development
WP_HOME=http://my-awesome-wordpress.vm
WP_SITEURL=${WP_HOME}/wp

Une arborescence mieux pensée

Tout est mieux rangé, et du coup, on trouve plus facilement ce que l’on cherche. L’arborescence ressemble à ceci :

├── composer.json
├── .env <----------------- where majority of the configuration will happen, must not be committed inside git repository
├── config
│   ├── application.php
│   └── environments
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── vendor  <-------------- where the 3rd party code lives
└── web
    ├── app
    │   ├── mu-plugins
    │   ├── plugins
    │   ├── themes
    │   └── uploads
    ├── wp-config.php <-- do not touch this file
    ├── index.php <------ entry point of your application, each web request are send through this file
    └── wp <------------- WordPress files

Point bonus pour la sécurité : la racine web (le point d’entrée de votre application), web/index.php, est isolée du reste de l’arborescence. Vos visiteurs ne peuvent donc pas accéder à votre fichier config/production.php, puisqu’il se trouve en dehors de web/.

Des builds reproductibles

Le principe des builds reproductibles peut se résumer ainsi : peu importe quand et où je construis et déploie l’application, j’obtiendrai toujours la même version du code (et des plugins).

Comme vous allez travailler sur votre environnement local (si ce n’est pas déjà le cas 👀), vous devez garantir que ce que vous avez sur votre ordinateur sera exactement identique à ce que vous aurez en production. Prenons un exemple pour comprendre pourquoi c’est important.

Imaginons que votre site tourne en production depuis à peu près un an, jusqu’au jour où une vilaine panne matérielle frappe votre serveur. Tous vos fichiers sont perdus. Heureusement pour vous, vous avez bien fait les choses : votre répertoire uploads/ et une sauvegarde de votre base de données sont stockés quelque part dans le cloud.

L’étape suivante consiste à réinstaller WordPress à partir de la sauvegarde de la base de données et des médias. Puis à réinstaller les 20 plugins qu’utilisait ce site. En un an, les plugins évoluent (et c’est tant mieux), mais votre thème, ou certaines de vos fonctionnalités, ne sont peut-être pas compatibles avec WooCommerce v3.5. Résultat possible : un site cassé.

Autre exemple : quand vous travaillez à plusieurs sur un projet, sans builds reproductibles, la personne chargée du front-end se retrouvera sur WordPress 5.1.1 pendant que le développeur en sera encore à la version 4.9.10, incapable de reproduire le bug que vous rencontrez avec cette configuration.

Ce principe implique d’interdire toute installation ou mise à jour de plugins ou de thèmes depuis le back-office de WordPress. Par défaut, Bedrock s’en charge quand vous êtes dans l’environnement de production. Et comme WordPress est lui aussi une dépendance composer, le mettre à jour est aussi simple qu’un composer update roots/wordpress.

Mais comment garantir des builds reproductibles ? La réponse se trouve juste en dessous : utilisez Composer.

Utilisez Composer

Le boilerplate Bedrock vous permet de gérer les dépendances de votre projet avec Composer, comme devrait le faire tout projet PHP moderne et digne de ce nom (oui, WordPress, c’est de toi que je parle).

Vous voulez installer WooCommerce ? Ouvrez votre terminal et tapez :

composer require woocommerce/woocommerce

Composer récupère la dernière version et la fige dans votre composer.lock. C’est grâce à ce fichier que vous obtenez toujours exactement les mêmes versions, quels que soient le moment et l’endroit où vous installez les dépendances de votre projet avec composer install. Vu son importance, ce fichier doit être commité ⚠️.

Le site roots.io propose un bon article sur l’utilisation de composer avec WordPress.

Tous les plugins peuvent aussi s’installer via composer. Comment ? 3 scénarios sont possibles :

Le plugin fournit un `composer.json`

Derrière le plugin, il y a un développeur ou une entreprise qui ne souffre pas du syndrome du « WordPress d’un autre âge » et qui développe des applications modernes. Concrètement, son plugin est livré avec un fichier composer.json qui permet de l’installer via composer. Dans ce scénario, vous pouvez chercher votre plugin sur packagist.org, le dépôt qui recense tous les paquets PHP publics de l’univers ✨.

Le plugin ne fournit pas de `composer.json`

Si vous ne trouvez pas le plugin sur packagist.org, c’est qu’il n’a pas de fichier composer.json. Pas d’inquiétude, wpackagist vient à la rescousse. Outlandish a créé ce projet pour permettre d’installer 100% des plugins et des thèmes à partir du dépôt officiel de WordPress. Ce plugin WordPress-ci, par exemple, est introuvable sur packagist.org ; utilisons donc wpackagist à la place :

composer require wpackagist-plugin/cookie-law-info

Le plugin est payant ou privé et n’a pas de `composer.json`

Plusieurs options s’offrent alors à vous :

Ouvrez un ticket auprès de leur support ou sur leur GitHub, et demandez-leur un moyen d’installer leur plugin via composer. Vous êtes leur client, vous payez pour un produit que vous ne pouvez pas installer proprement. Ils devraient s’en soucier.
- 👎 Mauvais élèves : ACF Pro, Elementor Pro, Formidable Forms
- 👍 Bon élève : Delicious Brains (Migrate DB Pro, Offload Media…).
Utilisez des solutions alternatives quand il y en a.
Créez un nouveau dépôt GitHub privé (c’est gratuit), copiez-y le code et ajoutez un composer.json comme dans cet exemple, taguez une nouvelle version avec les GitHub Releases, puis installez ce paquet via un dépôt personnalisé (custom repository). Toute la procédure est détaillée sur le site roots.io. Si vous en avez le budget, je vous conseille d’utiliser Private Packagist pour héberger vos paquets privés.

Utilisez un meilleur moteur de templates que PHP : « I’m yelling timber » !

Et côté templates, alors ? PHP n’est pas un bon moteur de templates. Difficile à lire, difficile à écrire, et ne nous voilons pas la face : nous ne sommes plus au début des années 2010, nous avons des outils conçus spécialement pour chaque usage. Le meilleur moteur de templates PHP, c’est Twig. Il est très utilisé dans l’écosystème Symfony (mais pas seulement).

Alors, comment utiliser Twig dans un projet WordPress ? Heureusement pour nous, il existe un projet appelé Timber.

Un plugin pour écrire des thèmes WordPress avec du code orienté objet et le moteur de templates Twig

Il ajoute un modèle Vue / Contrôleur, ce qui profitera énormément à la lisibilité et à la maintenance de votre thème.

Une fois que vous aurez commencé à écrire vos thèmes en Twig, vous ne reviendrez plus au PHP brut. Point.

Astuce de pro : comme vous ne concevez plus vos thèmes en PHP brut mais en Twig, le serveur doit transformer vos fichiers .twig en fichiers .php. Cette phase s’appelle la compilation, et elle prend du temps. Heureusement, il existe un système de cache qui stocke les templates compilés sur votre système de fichiers, pour que Twig ne recompile pas vos templates à chaque requête que votre serveur doit traiter.

Par défaut, Timber n’active pas ce cache.

Voici comment l’activer sans risque. Vous gagnerez ainsi jusqu’à 40% de temps de génération. Dans le functions.php de votre thème :

// Active le cache de Twig
if (class_exists('Timber') && WP_ENV === 'production') {
    Timber::$cache = true;
}

// Remplacez WP_ENV === 'production' par !WP_DEBUG si vous n'êtes PAS dans une structure Bedrock

Écart de temps de rendu avant/après l’activation du système de cache de Twig. Plus de détails sur cette trace Blackfire.

Notez que ce sont les templates PHP compilés qui sont mis en cache, pas les données. Une modification des templates .twig en production ne sera pas prise en compte tant que vous n’aurez pas vidé le cache. (Mais qui modifie des fichiers en production ? 😱 Certainement pas vous !)

Stockez de préférence vos assets dans le cloud

Stocker vos assets sur le système de fichiers local, dans le répertoire uploads/, c’est pratique, mais tôt ou tard, il vous faudra synchroniser ce dossier entre tous vos environnements. Sinon, votre version locale aura un jeu de médias complètement différent de celui de la production, et inversement.

Vous vous souvenez des builds reproductibles ? Ce serait bien de pouvoir stocker nos médias à distance pour ne plus dépendre du système de fichiers local, non ? Spoiler : oui, c’est bien.

L’autre gros avantage de cette technique, c’est qu’elle permet à votre site de monter en charge pour absorber un énorme pic de trafic. Il vous suffit d’ajouter des serveurs (scaling horizontal) : comme votre build est reproductible, le projet et les plugins seront identiques sur les serveurs numéro 1, 2, … 23, 24.

Quelques services pour stocker vos médias dans le cloud :

Amazon S3. Le plus connu, mais pas le moins cher 💸.
Digital Ocean Spaces. Compatible S3, 45 emplacements disponibles.
Scaleway. Stockage bon marché, compatible S3, mais seulement 2 emplacements disponibles (Paris et Amsterdam).

✅ Pensez à toujours choisir un bucket situé près de la majorité de votre audience. Je vous conseille de choisir une « API compatible S3 », car il n’existe pas beaucoup de plugins WordPress qui permettent d’utiliser un stockage distant et qui fonctionnent dans la majorité des cas.

Voici une liste de plugins gratuits qui permettent de stocker vos médias sur différents stockages cloud :

MediaCloud (gratuit)
humanmade/s3-uploads (gratuit)

Ce que je souhaite pour WordPress, c’est qu’il utilise une abstraction du système de fichiers comme Flysystem. Nous n’aurions alors plus besoin de plugins qui bidouillent WordPress pour lui dire d’envoyer les médias et les assets ailleurs. En attendant, vous pouvez utiliser l’un des plugins ci-dessus.

Connaissez vos outils : ACF peut plomber les performances de votre site

Si vous utilisez Advanced Custom Fields, alias ACF, vous devez connaître certains goulots d’étranglement que vous risquez de rencontrer si vous abusez de la fonction get_field.

N’exposez que les variables dont vous avez besoin sur chaque page. J’ai vu beaucoup d’exemples, y compris dans la documentation, qui vous invitent à faire :

$context['options'] = get_fields('options'); // retrieve all options fields from the database

Timber::render('index.twig', $context); // render the index.twig page with the options passed to the twig context so you can use them inside your view.

Quand vous faites ça, chaque champ récupéré déclenche une requête en base de données. Si vous avez 35 champs dans la catégorie options, cela déclenche donc 35 requêtes rien que pour récupérer ces champs. Mais avez-vous vraiment besoin de ces 35 champs sur toutes les pages ?

Que faire à la place ?

$context['options']['twitter_link'] = get_fields('twitter_link', 'options');
$context['options']['logo_footer_img'] = get_fields('logo_img', 'options');
Timber::render('index.twig', $context);

{# utilisez-les dans votre template .twig #}
<footer>
    <a href='{{ options.twitter_link }}'>Follow us</a>
    <img src='{{ options.logo_footer_img }}' />
</footer>

Sur un vrai projet, ce genre d’optimisation apporte des gains de performance importants.

Écart de temps de rendu avant/après avoir récupéré uniquement les champs ACF strictement nécessaires. -850 requêtes en base de données et -37% de temps de rendu ! Plus de détails sur cette trace Blackfire.

L’explicite vaut mieux que l’implicite. Cela aide aussi vos collègues à faire une revue de code plus précise de votre travail, un exercice bien plus difficile quand on ne sait pas à quoi votre template a accès.

Et les champs vidéo et image ? Si vous en utilisez, sachez que si vous les récupérez « tels quels » avec get_field('my_youtube_video'), le code va essayer de récupérer les métadonnées (taille, orientation, durée…) des vidéos et des images.

Où est le problème ? Eh bien, comme vous hébergez vos médias dans le cloud (ou sur un service distant, YouTube dans cet exemple), les vidéos et les images doivent être téléchargées côté serveur pour obtenir ces informations, dont vous n’aurez pas besoin dans 98% des cas. Faire des appels HTTP externes depuis votre serveur vers Internet fait alors perdre un temps précieux et tue les performances de votre site.

J’ai vu des projets passer presque 1 seconde en appels externes, rien que pour récupérer les informations de 10 images dans le cloud, ce qui empêchait le serveur d’envoyer le HTML au navigateur pendant tout ce temps.

Dans ces cas-là, vous devez utiliser get_field('my_youtube_video', null, false). Le dernier paramètre (false) indique de récupérer la valeur brute du champ (ici, l’URL YouTube de la vidéo, sans mise en forme ni traitement supplémentaire). Autre solution : configurer le champ en tant que champ « URL » (et non oEmbed), et, pour les images, en « Image URL ».

Écart de temps de rendu avant/après la configuration des champs en champs URL plutôt qu’en oEmbed. Tous les appels HTTP externes que faisait le serveur pour récupérer les métadonnées des images ou des vidéos ont disparu (-7), soit 35% de temps gagné (-846ms) ! Plus de détails sur cette trace Blackfire.

Lintez votre code

Votre thème embarque du CSS, du JavaScript et un peu de PHP ? Vous devriez les linter, pour vous assurer d’écrire du code conforme aux standards du métier. Utilisez :

ESLint - JavaScript
stylelint - CSS
Prettier - JavaScript, CSS…
PHP-CS-Fixer - PHP (exemple de notre fichier .php_cs_dist, qui contient nos règles de lint)

Utilisez l’outil de build ou le task runner avec lequel vous êtes à l’aise (Gulp, Brunch). Si vous n’avez pas encore choisi d’outil et qu’il vous en faut un simple, je vous suggère de jeter un œil à yProx-CLI, que nous utilisons depuis un moment chez Yproximité et que nous venons de publier en open source.

Pour votre santé mentale, par pitié, n’ouvrez pas le code des plugins que vous téléchargez. Vous pourriez être choqué par la piètre qualité du code auquel vous avez affaire, et finir par réécrire une bonne partie de vos plugins WordPress.

Utilisez un service d’intégration continue (CI)

Utilisez une CI (Travis, GitLab, CircleCI, Jenkins). Voici notre fichier .travis.yml de base. Il vérifie que notre composer.json est valide, que notre code PHP passe le linter, et pareil pour nos fichiers JavaScript. Aucune pull request ne devrait être mergée avec des erreurs de lint : une fois en production, elles ne seront jamais corrigées. Vos pairs peuvent ainsi relire votre code en se concentrant sur l’essentiel.

dist: trusty

language: php
php:
  - '7.3'

cache:
  yarn: true
  directories:
    - ./vendor
    - ./node_modules
    - ~/.composer/cache/files

before_install:
  - |
    if [ -f "package.json" ]; then
        set -e # properly fails Travis if one of the following commands fails
        nvm install v10
        nvm use 10
        node --version
        npm --version
        npm install --global yarn
        set +e # re-enable previous behaviour
    fi

script:
  - composer validate
  - composer install
  - vendor/bin/php-cs-fixer fix -v --dry-run --using-cache=no
  - if [ -f "package.json" ]; then yarn install; fi;
  - if [ -f "package.json" ]; then yarn lint; fi;
  - if [ -f "package.json" ]; then yarn build; fi;

Mettez en place un outil de mise à jour automatique des dépendances

Avec 150 projets WordPress dans notre organisation, lancer composer update sur chacun d’eux une fois par semaine n’est pas franchement ce dont nous avons envie : il a fallu trouver comment gérer les mises à jour.

Nous utilisions ManageWP pour mettre à jour WordPress et toutes ses dépendances, mais cette option n’est plus envisageable puisqu’elle casse le principe des builds reproductibles. Rien ne doit altérer ni modifier votre environnement. Le code doit être exactement le même que dans votre dépôt git.

Une option viable pour nous a été de déléguer les mises à jour à Dependabot, dont le rôle est d’ouvrir une pull request dès qu’une mise à jour est disponible. Il existe des alternatives, par exemple Renovate.

Nous l’avons configuré pour merger automatiquement les pull requests quand il s’agit d’une mise à jour mineure ou d’un patch (v1.0.0 -> v1.1.4 sera mergée automatiquement, mais pas v1.0.0 -> v2.0.0).

⚠️ L’écosystème WordPress ne respecte pas forcément le SemVer, parce que… (je cherche encore la raison…).

Comme nous avons choisi une « Platform as a Service » (PaaS) pour héberger tous nos WordPress, dès qu’une pull request est mergée sur la branche master, le projet est redéployé en production.

Quel que soit l’hébergement choisi, vous devriez avoir du déploiement automatique. Sinon, si vous devez redéployer chaque projet à la main et que vous en avez un très grand nombre, vos projets seront à jour, mais les mises à jour n’arriveront jamais en production.

Choisissez le bon hébergement

Je vous conseille vivement d’opter pour une offre PaaS. Les principaux avantages d’une Platform as a Service (PaaS) sont :

Aucune maintenance à prévoir, ni pour le serveur ni pour les logiciels
Des déploiements automatisés
Prête pour le scaling vertical et horizontal
Bon marché
Simple
Isolée (pas de contamination croisée d’un site A vers un site B hébergés sur le même serveur)

Quelques exemples de PaaS :

🌍 Heroku (à partir de 14 $/mois)
🇫🇷 Scalingo (à partir de 10,80 €/mois)
🇫🇷 Clever Cloud (à partir de 26,50 €/mois)

⛔️ N’utilisez jamais de FTP ou de SFTP pour déployer en production. Comme vous devez construire votre projet en lançant composer install, et peut-être compiler vos assets avec yarn build, le bon vieux copier-coller du projet sur votre FTP, qui avait déjà un pied dans la tombe, est définitivement et enfin mort ⛔️

Ce que vous devriez déjà faire

Voici une liste de choses que vous devriez déjà faire, et qui ne méritent donc pas un chapitre à elles seules :

Travaillez avec une machine virtuelle, pour que tout le monde ait le même environnement. Vous pouvez utiliser trellis, ou manala si vous êtes plus technique
Utilisez la dernière version de PHP disponible
Travaillez avec des pull requests
Relisez le code de vos pairs, et demandez-leur de relire le vôtre
Configurez GitHub pour interdire le merge d’une pull request qui n’a pas été relue.

Note aux développeurs de plugins WordPress

Pour faire de l’écosystème WordPress un monde meilleur, s’il vous plaît, respectez au moins ces 5 règles :

⚠️ Ne partez pas du principe que les utilisateurs de votre plugin stockent leurs fichiers uploadés sur le système de fichiers local. Partez du principe que non. Passez par une couche d’abstraction pour manipuler les fichiers, par exemple Flysystem.

Ce raisonnement s’explique surtout par les cas suivants :

Quand vous hébergez votre application dans le cloud, vous voudrez peut-être pouvoir la faire monter en charge en ajoutant des serveurs.
Quand vous hébergez votre WordPress sur une infrastructure immuable, ce qui veut dire, en gros :
- Soit vous ne pouvez pas écrire sur le serveur, ce qui empêche toute modification ;
- Soit les modifications que vous avez faites sont perdues quand le projet est redéployé. (Un déploiement a lieu chaque fois que vous mergez du code dans votre dépôt, ou quand vous faites varier le nombre de serveurs de votre application, en en ajoutant ou en en retirant. Seul ce qui se trouve dans votre dépôt git est déployé sur le serveur.)

⚙ Proposez un moyen de configurer votre plugin par variables d’environnement, avec un repli sur la base de données si la variable d’environnement est introuvable. Variables d’environnement > configuration stockée en base de données, par ordre d’importance. Cela nous permet d’automatiser l’installation des plugins et de regrouper toute la configuration au même endroit.

🎻 Rendez votre plugin installable avec composer : il faut pour cela un fichier composer.json de 10 lignes minimum. Regardez quelques exemples ici, ici ou là. L’étape suivante consiste à taguer vos versions avec les GitHub Releases en respectant SemVer, puis à soumettre votre paquet sur packagist.org en saisissant l’URL GitHub de votre dépôt.

🔒 Prenez en charge les versions maintenues de PHP

💅🏽 Lintez votre code PHP avec PHP-CS-Fixer, bon sang ! Choisissez entre le preset PSR2 et celui de Symfony, mais choisissez-en un et corrigez votre code.

Conclusion

Si vous voulez voir une structure de projet qui met en œuvre la plupart des points abordés dans cet article, jetez un œil à mon exemple de boilerplate WordPress basé sur Bedrock et Timber. Ce dépôt n’est pas fait pour être utilisé « tel quel », mais il vous aidera à comprendre comment structurer les fichiers de votre projet.

Le benchmark PaaS de Clever Cloud vs Scalingo vs Hidora

Tristan Bessoussa — Thu, 24 Jan 2019 00:00:00 GMT

Cette série de billets a pour but de faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série :

EDIT 01/21 Les tests de performances ont été ré-actualisés. La première fournée de tests en 2019, accessibles ici: exhaustivité des ~80 tests du comparatif 2019 de performances de PaaS entre Scalingo et Clever Cloud contenait 80 tests. En 2021, j’ai été beaucoup plus concis sur les tests, disponibles sur cette feuille de calcul.

Les performances mesurées

Sont retenus pour ce benchmark :

✅ Clever Cloud
✅ Scalingo
✅ Hidora
⛔️ OVH Cloud Web (impossible de faire tourner le projet, voir Partie II)
⛔️ Platform.sh (trop cher pour notre contexte WordPress)

Les tests ont été réalisés dans des conditions réelles. J’ai pris un WordPress “représentatif” déjà en production chez nous. Il ne s’agit pas de tests sur un WordPress sans plugins qui ne comporte qu’une page vierge.

J’ai effectué les tests avec un outil de test de montée de charge (k6.io) depuis un serveur à Paris, FR : 5 visiteurs unique par seconde pendant 2 minutes.

Les tests chez les différents PaaS ont été réalisés dans les même conditions : Même versions de wordpress et des plugins, même page testée. Aucune optimisation apportée excepté la variable d’ajustement pm.max_children pour gérer la concurrence des requêtes à php-fpm.

Avant de consigner les résultats obtenus, j’ai passé quelques temps à trouver la valeur optimale pour la configuration pm.max_children qui permet de dire aux scalers combien de requêtes PHP concurrentes il est capable de traiter.

Une valeur trop haute, et ce sont les performances qui sont plombées à cause du manque de RAM (qui swap). Une valeur trop faible, et le scaler est alors bridé, et vos performances aussi.

⚠️ Notez que le nombre de visiteur unique est variable, même si l’on règle le test sur 5 visiteurs uniques par secondes pendant 2 minutes. Je n’ai jamais obtenu 5x60x2 = 600 requêtes. Pensez donc à regarder le nombre de requête que le serveur à eu à traiter. ⚠️

Résultat des tests (extraits)

5 clients par seconde sur 2 minutes

	Prix/mois	Détail	BDD	Moyenne (ms)	Nombre de requêtes
Scalingo	10,8€	1x S	256M	492	335
Scalingo	18,0€	1x M	256M	451	342

Clever Cloud	11,9€	1x nano	XXS-Med (512Mb)	884	279
Clever Cloud	20,3€	1x XS	XXS-Med (512Mb)	588	313

Hidora	15,78€	2gb	256mb	2 042	239
Hidora	28,70€	2gb	512mb	1110	237

Configuration des tests

Edition Wordpress Bedrock afin que WP soit compatible avec un hébergement PaaS, en plus de proposer des outils modernes (gestion de la conf par variables d’environnement, gestion des plugins WordPress par composer…)
PHP 7.4.x
Site 1
- Wordpress 5.6.x
- Liste des dépendances et plugins : composer.json
pm.max_children est reglé sur 10

Les PaaS Français sont sur un bateau : Platform.sh au mouillage

Tristan Bessoussa — Wed, 23 Jan 2019 00:00:00 GMT

Ce billet s’inscrit dans une série d’articles visant à faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série :

Platform.sh

Accéder au résumé si vous êtes pressés

Pour nos projets Symfony sur mesure, nous sommes chez Platform.sh (~7 projets).

Je l’ai rapidement éliminé dans le contexte d’une offre d’hébergement de plus de 120+ projets Wordpress car le pricing n’est pas du tout adapté à notre contexte.

40€ pour 0.8GB de mémoire, sachant qu’elle est partagée entre les containers applicatifs ; donc 800Mo de mémoire divisé entre le container web, et le container de la base de données, ça ne fait pas vraiment rêver….

Répartition de la mémoire sur les plans Platform.sh. Pour un service avec du PHP et une base de données, le plan S ne suffira pas.

Le plan supérieur est à 100€/mois. Et là, on fait x10 sur nos dépenses, sachant que dans notre contexte, la fonctionnalité pour utiliser différents environnements ne nous intéressait pas.

La gestion des variables d’environnement, comment dire… c’est compliqué : on pense que l’onglet variable sur la branche en question suffirait ? En fait non, car elles ne sont accessibles qu’au runtime et pas au build.

Pour rajouter des variables au build, il faut aller cliquer sur une zone de 20 par 20 pixels pas du tout miss en avant et rajouter les variables. On se retrouve souvent alors à rajouter les variables dans la configuration du projet, puis à les dupliquer dans la configuration de l’environnement master afin de bénéficier de l’héritage sur les autres branches.

Notez qu’il n’y a pas d’édition de variables d’environnement en mode “Bulk Edit/Add”.

Des efforts sur l’UI et l’UX/DX sont à prévoir car l’interface génère régulièrement des frustrations (en plus d’être lente).

Les incidents sont fréquents (ou alors je n’ai pas de chance et le peu de fois où j’ai besoin de Platform.sh, il y a un incident…), du type “ah tiens, mes builds sont bloqués”, “l’application n’est plus auto-deployée, donc mes correctifs que je pensais être déployés en prod il y a 7 jours ne sont jamais arrivés”. Heureusement, la prod n’est jamais tombée sur nos projets, mais ces problèmes à répétition sur l’utilisation du PaaS sont usants.

Pour illustrer mes propos, de décembre à janvier, il y a eu 10 incidents répertoriés, certains majeurs, sur leur statuspage (hors maintenance). A l’heure où j’écris cet article, mon équipe me signale qu’elle est encore bloquée pour déployer certains environnements.

Résumé Platform.sh (TLDR)

👎 Inconvénients

Cher
Pas de scalabilité automatique
On ne sait pas combien de ressources on consomme
Interface très lente et pas sexy
Gestion des variables d’environnement
Incidents à repetition
Hook de déploiement qu’il faut régulièrement supprimer et rajouter pour que le projet continue à se déployer automatiquement
Aucun outil de monitoring depuis l’interface pour aller créer des règles d’alertes (ex : Poster un message dans Slack si la RAM >90%). Il y a uniquement un check sur l’espace disque
Backups pas automatisés, ni proposés de manière automatique. Il faut s’occuper soi-même de créer un cron de snapshot

👍 Avantages

On peut déployer des branches comme environnements pour faire des démos ou de la préprod facilement
Système d’héritage des variables d’environemment qui facilite la création d’autres environnements
Copie de la base de données de production lors de la création d’un nouvel environnement

⛔️ VERDICT : ELIMINÉ ⛔️

Aucun benchmark n’a été réalisé avec Wordpress, tant que la projection d’une migration chez eux bloquait au niveau tarifaire.

Lire la partie VI

Part6. Comparatif PaaS : Les performances, Clever Cloud VS Scalingo

Les PaaS Français sont sur un bateau : Scalingo reste à flot

Tristan Bessoussa — Tue, 22 Jan 2019 00:00:00 GMT

Cette série de billets a pour but de faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série :

Scalingo

Accéder au résumé si vous êtes pressés

Scalingo est un service PaaS dont je n’avais jamais entendu parler (ni sur ma timeline Twitter), c’est un peu à reculons que je l’ai ajouté dans ma liste de “candidats”.

Ici, l’onboarding est très simple, je n’ai pas dû aller négocier un budget pour tester le service : tout est facturé à la minute. De ce fait, tous les services qui facturent au mois prennent un gros coup de vieux.

Si vous possédez un site qui passe sur Capital, vous pourrez commander XX scalers supplémentaires afin que l’application tienne la charge, et n’être facturé que sur les 20 minutes durant lesquelles le reportage aura parlé de vous. Et ce même pour la base de données, afin d’augmenter les fameuses limites de connexions simultanées (même si dans ce cas, il serait préférable de passer le site en lecture seule, et mettre un reverse proxy) et de RAM.

L’interface ne colle plus aux tendances actuelles : elle fait un peu vieillotte, mais elle est agréable à l’utilisation et très réactive. Il vaut mieux ça qu’une interface très “belle”, mais mal pensée et lente.

Build de l’application sur Scalingo

Un fichier .buildpacks doit être créé à la racine du projet contenant l’URL d’un dépôt git afin de dire au PaaS comment construire l’application. Dans notre cas c’était : https://github.com/Scalingo/php-buildpack

Le composer.json est alors détecté, et bonus, l’édition de Wordpress Bedrock étant supportée chez eux, je n’ai rien eu à faire pour configurer le Vhost NGINX, ça a fonctionné de manière automatique (liste des framework PHP auto-détectés), ce qui n’a pas été le cas par exemple chez Clever Cloud où il a fallu indiquer où était le front controller de l’application (web/index.php).

L’application se build rapidement et j’ai pu procéder aux tests.

Performance chez Scalingo

Les tests parleront d’eux-mêmes dans le chapitre dédié. Notez que Scalingo écrase Clever Cloud qui ne passe même pas certains tests à tarif équivalent.

Quelques fois, nous avons obtenu des performances bien meilleures lors de tests réalisés à des dates différentes chez Scalingo. Après avoir contacté le support, cela s’expliquerait par le voisinage. En effet, les scalers peuvent bouger de machine en machine selon leur charge. Si nous avons des voisins qui possèdent des scalers avec une très forte priorité CPU (donc qui payent plus cher) et qui sont très actifs sur le moment alors moins de temps CPU sera alors alloué à nos containers avec une priorité plus faible.

Part7. Comparatif PaaS : Les performances, Clever Cloud VS Scalingo VS Hidora

Résumé Scalingo (TLDR)

👎 Inconvénients

UI pas très sexy sans être catastrophique non plus.
Autoscaling (en BETA fermée) qui demande encore d’être un peu ajusté
Interface de gestion des logs qui pourrait être améliorée visuellement
Pas de support de Github Server (pour l’app de déploiement)
Pas (encore) de vision “d’ensemble” pour les portefeuilles avec beaucoup de projets
Pas de reverse proxy (ex : Varnish) facilement configurable depuis un .vcl déposé à la racine de l’application afin d’augmenter les performances applicatives en tirant parti du cache HTTP
EDIT 12/20 Au moins 2 incidents majeurs de la plateforme sur 2020 suite à des attaques DDOS

👍 Avantages

Tarifs compétitifs
Tout est facturé à la “minute”, même la base de données
Auto-scaling horizontal
Support réactif. EDIT 3/12/20 Toujours très réactif, et souvent un développeur est à l’autre bout qui comprends tout de suite la problématique et apporte une solution rapidement. C’est très appréciable.
Interface agréable à utiliser et réactive (UX/DX)
Gestion facilitée du pm.max_children depuis l’UI (variable MAX_CONCURRENCY)
Gestion d’environnements différents pour une même application (prod/préprod…), mais pas aussi facile que ce que peut proposer Platform.sh par exemple
Gestion simple et assez complète des règles de monitoring de vos scalers sur différents cannaux (slack, mail…)
EDIT 3/12/20 Environnement plus flexible que certains PaaS sur certaines extensions: compatible avec Blackfire, Datadog…

✅ VERDICT : RETENU ✅

Scalingo a été pour moi LA bonne surprise de ce comparatif. Les tarifs sont compétitifs par rapport au marché, sans compromis sur les performances. Les principales features que l’on peut attendre d’un PaaS sont là et fonctionnent bien !

Lire la partie V

Part5. Comparatif PaaS : Platform.sh

Disclaimer : les liens Scalingo sont câblés sur un système de parrainage rattaché à mon compte personnel. Si les autres PaaS testés ici avaient eu ce même système de parainage, j’aurais aussi utilisé ce système sur leurs liens (pour faire des futurs POC ou petits projets persos).

Les PaaS Français sont sur un bateau : Clever Cloud redresse la barre

Tristan Bessoussa — Mon, 21 Jan 2019 00:00:00 GMT

Cette série de billets a pour but de faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série :

Clever Cloud

Mise à jour Janvier 2021: Clever Cloud à changé courant 2020 sa politique de prix sur les bases de données ce qui lui permet de réduire considérablement les coûts, dont je parlais dans cet article.
De plus, après un nouveau test de performance, en utilisant le même projet qu’en décembre 2019, les performances par défaut sont bien meilleures qu’avant (voir mise à jour de l’article Comparatif PaaS : Les performances, Clever Cloud VS Scalingo.

Accéder au résumé si vous êtes pressés

Clever Cloud est aussi un PaaS français qui apparait souvent dans ma timeline Twitter dès que des twittos demandaient où héberger leurs projets. C’est avec enthousiasme que j’ai voulu tester leur PaaS.

Sur le papier, l’offre est sexy (auto) scaling vertical, horizontal.

La base de données

Au moment de prendre le service, première mauvaise surprise : la base de données est payante au mois complet, et il n’est pas encore possible de la faire scaler de manière automatique ou manuelle, mais cela devrait (bientôt) changer,

	Clever Cloud	Scalingo
Connexion max	75	62
Taille max BDD	10 5Gb	5Gb
Mémoire	1Gb	1Gb
Type	Dédié	Dédié (Software + RAM)
CPU	1 vCPU	Partagé
Prix	45 22€/mois	14,4€/mois (découpé par minute)

Autre point d’alerte, chez Clever Cloud, ils vous incitent à vous orienter vers du PostgreSQL et ce de manière assumée, puisqu’à ressource strictement équivalente, les containers de base de données sont plus chers pour du MySQL.

On parle d’une différence de ~~180~~ +54€ par an.

Ils justifient cette différence par le fait qu’une instance MySQL coûte plus cher à gérer que du PostgreSQL et l’équipe technique chez eux préfère maintenir du PostgreSQL.

Autant pour une application Symfony, ça ne me fait ni chaud, ni froid (ou presque…) de mettre un PostgreSQL, autant pour du WordPress, nous n’avons pas le choix sur la base de données compatible avec le CMS. Donc au final, c’est l’utilisateur qui paye le coût supplémentaire.

EDIT 12/20 ~~A priori, ils seraient en train de retravailler le pricing des scaler de base de données.~~ C’est maintenant chose faite, d’ou la MAJ de cet article.

Paramétrage de l’application sur Clever Cloud

Comme toute application hebergée sur un PaaS, on passe par la case “variables d’environnement”. Chez Clever Cloud, c’est peu pratique. Lors de mes tests, il y a quelques semaines, il n’y avait pas de gestion de l’édition/ajout des variables en masse. Quand on doit saisir 20 variables : quelle perte de temps ! Heureusement, ça a été corrigé récemment par l’ajout d’un bulk edit/add.

Il n’est pas possible de faire référence à une autre variable (ex: DATABASE_URL=$MYSQL_ADDON_URI), et ça, c’est dommage.

J’ai voulu déployer ensuite mon Wordpress. Je n’ai malheureusement pas pu puisqu’une dépendance (wp-cli) nécessitait la présence de l’extension PHP ext-readline qui n’était pas disponible sur Clever Cloud.

Il a fallu faire une demande au support, et manque de pot, c’est tombé un vendredi, donc pas de mise en prod possible avant mon départ en vacances.

NB (non dirigée contre Clever Cloud) : il faut arrêter avec cette politique absurde, je suis tout à fait d’accord avec le Tweet ci dessous : chez nous le vendredi est un jour comme les autres pour les déploiements parce qu’on a fait en sorte que ça soit le cas (tests, automatisation, reviews…).

"No deploys on friday" is cancer philosophy that enforces fear to deploy and slow down the dev cycle. Stop repeating this crap as if it's cool, and improve processes and tests, for god's sake.
— SergiGP 🎗 (@SergiGP) 19 décembre 2018

A mon retour de vacances, toujours pas possible de build, suite à un couac, “la feature est activée mais pas l’extension”. Bref, ça arrive quelque heures plus tard : l’application peut enfin être build.

Build de l’application sur Clever Cloud

Alors, comment on build chez eux ?

Comme le projet possède un composer.json, le PaaS va récupérer les dépendances de manière automatique. Seulement, nous “buildons” le thème depuis une tâche yarn build. Il faut donc que l’on puisse lancer un yarn install suivi d’un yarn build.

Et la ce n’est pas hyper pratique puisqu’il n’est pas capable de dire “Ok, je vois un yarn.lock donc je vais lancer aussi un yarn install && yarn build”. Donc on est obligé de passer par un Build Hook.

On lui définit une variable pour lui dire d’utiliser yarn comme package manager, et puis on va lui dire quelles commandes lancer et à quel moment du build, exemple : CC_POST_BUILD_HOOK="yarn install && yarn build"

Notez que Wordpress n’a pas été detecté automatiquement, et il a fallu que je crée un fichier dans un dossier .clevercloud nommé php.json afin que le routeur puisse savoir quoi servir :

{
  "deploy": {
    "webroot": "/web"
  },
  "configuration": {
    "pm.max_children": "20"
  }
}

Performance chez Clever Cloud

EDIT 01/21 Les nouvelles politiques tarifaires, ainsi que de multiples améliorations hardware/software (migration datacenter + meilleur reverse proxy en Rust) permettent à Clever Cloud de redresser la barre de manière drastique par rapport aux tests réalisés en décembre 2019.

Ainsi, l’écart de prix se réduit. Mes testent réalisés en Janvier 2021 montrent qu’il ne faut plus avoir à débourser 5 à 9 fois plus d’argent pour obtenir des performances similaires à l’un de ses principaux concurrents, Scalingo. On est plus sur un ratio de x2. Comprendre ici, pour 2 fois moins cher sur Scalingo, on a des performances similaires à Clever Cloud sur notre environnement WordPress.

Exemple : J’envoie 5 visiteurs uniques par seconde pendant 2 minutes sur la page d’accueil.

Pour 10,8€/mois chez Scalingo, j’obtiens 492ms de moyenne de temps de réponse.

Pour 20,3€/mois chez Clever Cloud, j’obtiens 588ms. C’est la somme minimum à débourser pour avoir des performances semblables.

Part7. Comparatif PaaS : Les performances, Clever Cloud VS Scalingo VS Hidora

Résumé Clever Cloud (TLDR)

👎 Inconvénients

~~Ratio prix/performances sur du WordPress catastrophique~~
Gestion du pricing des add-ons de base de données : ~~prix important, et~~ engagement au mois
Pas de scaling sur la base de données
~~Pas de références à d’autres variables d’environnement~~
Pas de support de Github Server pour déploiement auto
Interface parfois peu intuitive
Gestion des statistiques (en BETA depuis 2019 ?)
Pas de gestion facilitée du pm.max_children depuis l’UI (ex : par une variable d’environnement)
EDIT 12/20 Très peu d’ouverture sur l’écosystème PHP: APM / Monitoring (pas de Datadog, blackfire.io, tideways.io)
EDIT 01/21 Ratio prix/performances bonnes

👍 Avantages

Backup automatisés
Intégration avec let’s encrypt
Auto-scaling vertical et/ou horizontal
Support réactif sur l’aspect communication
Interface sexy & réactive
Gestion des logs claire
Une alternative à Amazon S3 “maison”, pour monter un espace de stockage non volatile
Une gestion optionelle d’un reverse proxy qui a l’air simplifiée (Varnish)
EDIT 12/20 Très stable (Rex sur 1an+ d’hébergement d’un projet chez eux)
EDIT 12/20 Gestion multi-régions (avec l’aide d’OVH en coulisse)

⛔️ VERDICT : ELIMINÉ ⛔️

EDIT 01/21 Les problèmes de rapport performance/prix, maintenant résolus, ont été les 2 raisons de l’élimination de Clever Cloud pour notre problématique d’hébergement en 2019.

Lire la partie IV

Part4. Comparatif PaaS : Scalingo, on reste à flot

Les PaaS Français sont sur un bateau : OVH tombe à l’eau

Tristan Bessoussa — Sun, 20 Jan 2019 00:00:00 GMT

Ce billet s’inscrit dans une série d’articles visant à faire un retour d’expérience sur les différents PaaS français dans une problématique d’hébergement d’un parc de 120+ WordPress.

Dans la série :

OVH et son offre Cloud Web

Accéder au résumé si vous êtes pressés

OVH est le dernier arrivé dans le monde du PaaS avec son offre Cloud Web, ce n’est pas son domaine d’expertise, et ça se ressent vite, très vite.

Tout d’abord, première mauvaise surprise, il est impossible de commander une offre Cloud Web pour moins de 12 mois.

Si vous ne souhaitez pas commander un nom de domaine avec l’offre Cloud Web (car vous en avez déjà un), il est impossible de sauter cette étape lors de la commande de l’offre par l’interface OVH. Il est cependant possible de contourner cette étape si vous commandez l’offre par l’API d’OVH.

A priori, les équipes travailleraient à lever ces contraintes, mais de source interne, ça ne sera pas traité avant de longs mois (sans garanties). Mais soyons clairs, certains concurrents proposent de la facturation à la minute, donc débourser ~490€ TTC pour faire quelques tests sur du Cloud Web 3, ou même si l’on se projette sur notre parc de Wordpress de 120+ projets, cela reviendrait à un ticket d’entrée de ~60,000€ sans garantie que nos clients restent un an chez nous.

Je suis rentré en contact avec une personne de chez OVH pour lui faire remonter ces problèmes. On m’a proposé de m’offrir l’offre Cloud Web 3 pour 1 an, en échange de feedbacks sur le produit. Merci pour cette proposition.

Dès que j’ai eu accès au produit, j’ai voulu mettre PHP 7.3 et créer mes variables d’environnement afin de pouvoir configurer le wordpress et faire mes tests de performances. Mais je me suis heurté à des problèmes, dont un qui m’a empêché toute utilisation du produit :

PHP 7.3 n’est pas disponible, il est pourtant sorti le 6 Décembre 2018, soit depuis plus d’un mois lors de la création de cet article
Pas de gestion de permissions (autre que pour le gestionnaire/contact technique) pour donner par exemple accès à la gestion des variables d’environnement pour un ensemble de personnes d’une équipe
J’ai créé des variables d’environnement, certaines se sont créées en quelques secondes/minutes, et d’autres, rien après 15 minutes de “En cours de création”. Je me suis mis à fouiller l’UI avant de découvrir que la tâche de création de certaines variables était en erreur (sans plus de détails)
Pas de gestion de “bulk insert” des variables d’environnement. J’ai dû répéter les opérations de création de variable 20 fois à cause de ce manque

La création de ces variables d'environnement sur OVH sont 'en cours' depuis 14 jours sans possibilité de les supprimer ou de les modifier

Le support d’OVH

Sans possibilité de modifier ou de supprimer les variables “fautives”, je suis bloqué dans ma configuration, je me tourne donc vers le support.

Le 8 janvier 2019, ouverture du ticket au support pour signaler que je ne peux pas utiliser le produit à cause de mon problème de variables d’environnement
Le 21 janvier 2019, soit 13 JOURS après, je reçois la première réponse du support qui peut être résumé à : “Nous sommes désolés pour la prise en charge tardive du ticket, des administrateurs sont en train de vérifier votre demande.”
Le 23 janvier 2019, on m’informe que les opérations en erreur ont été annulées, et on m’invite à réessayer sans m’expliquer ce qu’il s’est passé.

Résumé OVH Cloud Web (TLDR)

👎 Inconvénients

Engagement annuel
Pas de paiement mensuel
Impossible de commander sans domaine associé par l’interface web
Documentation très pauvre et incomplète
Pas de déploiement par Git
Pas de déploiement automatique via app Github/Gitlab
Pas de scaling horizontal, vertical
Pas d’auto-scaling
Le support d’OVH : à proscrire
Pas de gestion de permissions pour donner les droits d’accès à une équipe sur les variables d’environnement par exemple
UX/DX pauvres sur la gestion des variables, en plus d’être buggées

👍 Avantages

Backup automatisés
Intégration avec let’s encrypt
Réseau OVH
C’est à peu près tout… 🤷‍♂️😱

⛔️ VERDICT : ELIMINÉ ⛔️

Difficile d’émettre un jugement définitif quant aux offres PaaS d’OVH tant que l’on ressent qu’elles ont besoin de maturer encore afin de répondre au besoin du marché. Honnêtement, j’étais frustré et déçu sur le fait de ne pas avoir pu benchmarker la performance de leur offre Cloud Web 3.

Mes aprioris sur le support se sont malheureusement confirmés, de ce fait, je ne peux conseiller à personne cette offre dans le cadre professionnel, où au moindre souci, vous attendez des semaines la réponse du support (à moins de les harceler sur Twitter), et ce, même si c’est critique pour le service.

Quant à une utilisation personnelle, qui est capable de sortir ~490€ d’un coup pour héberger son “side project” personnel pour une offre PaaS ? 🙊

Lire la partie III

Part3. Comparatif PaaS : Clever Cloud, le bateau prend l’eau

DevOps life (français)

Comment j’ai hacké la liste d’attente de ma box de CrossFit avec l’IA (et pourquoi ça a changé mon regard sur le code assisté par IA)

Le problème : la galère des réservations

Le déclic

L’IA entre en scène : un binôme de code inattendu

Retour sur terre : l’IA n’est pas magique, c’est un partenariat

Le point de vue du CTO : une prise de conscience décisive

Ce que j’en retiens

Un environnement de développement sain en 2021. Bonjour Docker, bye machines virtuelles

Contexte

Pourquoi s’éloigner du modèle machines virtuelles ?

Une solution propulsée par Docker, mais pas que !

Aller plus loin

Installation des prérequis sous macOS

Prérequis

Installation de PHP

Installation de NodeJS

Bonus avec mux et tmuxinator

Essai du PaaS Suisse, Hidora

Hidora

Build de l’application sur Hidora

Performance chez Hidora

Résumé Hidora (TLDR)

👎 Inconvénients

👍 Avantages

Verdict

Comment le serverless nous a sauvé la mise pour 2 $

Le besoin : générer des rapports statistiques en PDF

L’option VPS ou serveur dédié

L’option serverless

Étape 1 : préparer les données

Étape 2 : créer des messages asynchrones

Étape 3 : stocker les messages dans une file d’attente

Étape 4 : générer les PDF

Étape 5 : envoyer le PDF au client par e-mail

Comparatif

Conclusion

Travailler avec WordPress sans déprimer

Utilisez Bedrock Edition

Prise en charge des variables d’environnement

Une arborescence mieux pensée

Des builds reproductibles

Utilisez Composer

Le plugin fournit un composer.json

Le plugin ne fournit pas de composer.json

Le plugin est payant ou privé et n’a pas de composer.json

Utilisez un meilleur moteur de templates que PHP : « I’m yelling timber » !

Stockez de préférence vos assets dans le cloud

Connaissez vos outils : ACF peut plomber les performances de votre site

Lintez votre code

Utilisez un service d’intégration continue (CI)

Mettez en place un outil de mise à jour automatique des dépendances

Choisissez le bon hébergement

Ce que vous devriez déjà faire

Note aux développeurs de plugins WordPress

Conclusion

Le benchmark PaaS de Clever Cloud vs Scalingo vs Hidora

Les performances mesurées

Résultat des tests (extraits)

5 clients par seconde sur 2 minutes

Configuration des tests

Les PaaS Français sont sur un bateau : Platform.sh au mouillage

Platform.sh

Résumé Platform.sh (TLDR)

👎 Inconvénients

👍 Avantages

Lire la partie VI

Les PaaS Français sont sur un bateau : Scalingo reste à flot

Scalingo

Build de l’application sur Scalingo

Performance chez Scalingo

Résumé Scalingo (TLDR)

👎 Inconvénients

👍 Avantages

✅ VERDICT : RETENU ✅

Lire la partie V

Les PaaS Français sont sur un bateau : Clever Cloud redresse la barre

Clever Cloud

La base de données

Paramétrage de l’application sur Clever Cloud

Le plugin fournit un `composer.json`

Le plugin ne fournit pas de `composer.json`

Le plugin est payant ou privé et n’a pas de `composer.json`