DevOps life

How I Used AI to Hack My CrossFit Waitlist Problem (and Why It Changed My View on AI Development)

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

As a CTO who barely codes anymore, I never thought I’d build another app from scratch - until my CrossFit addiction and AI joined forces. Here’s how I used generative AI to increase my chances of getting into popular CrossFit classes from 20% to 90%.

The Problem: CrossFit Class Booking Blues

For two years, I’ve been battling with my CrossFit box’s booking system. The classes are incredibly popular, requiring reservations up to 14 days in advance. Miss that window? Welcome to waitlist hell, often 15 people deep for the coveted after-work slots.

Here’s the kicker: I’m terrible at planning ahead. My only hope was to pounce on cancellation notifications, but even my lightning-fast thumb wasn’t enough. Why? The push notifications arrived with up to a minute delay between users. Even when I clicked within a second, I’d still miss out 80% of the time.

The Light Bulb Moment

As someone who coded for a decade before getting more hands-off, I knew there had to be a better way. The solution was clear: why wait for delayed push notifications when I could query the API directly (which is not public by the way) ? But there was a catch - while the concept was simple, the modern development landscape had evolved significantly since my coding days.

Enter AI: My Unexpected Coding Buddy

Last week, I decided to test all the “AI coding hype” I’d been seeing on social media. Armed with Cursor and Claude, I embarked on my diabolical plan to enhance my fitness journey.

The process was fascinating:

I started small, asking AI to create an interface displaying available classes, participant counts, and waitlist numbers
I extracted network calls (.HAR) from the official web app and fed them to Claude
Within an hour, I had my first “wow” moment - what would have taken me 4 hours in my familiar tech stack, I accomplished in unfamiliar territory (Astro & React)

The Reality Check: AI Isn’t Magic, It’s a Partnership

Working with AI wasn’t all smooth sailing:

Sometimes it was like working with a brilliant but distracted child
It would forget context (“You generated pure React, but we’re in an Astro project, remember?”)
Adding features could break existing functionality (turns out AI shares some human coding traits 😅)

The key was learning to provide context effectively, whether sharing specific files or the entire project scope to ensure coherent solutions.

The CTO Perspective: A Game-Changing Realization

This experience transformed my view on AI tools in development. While some of my team already uses GitHub Copilot or Cursor, this personal project revealed the true potential of AI-assisted development. It’s not about replacing developers - it’s about forming an effective partnership with AI tools.

Key Takeaways

Clear Requirements Matter: AI needs well-defined scope and expectations
Context is King: The limiting factor is often human communication - vague requests yield vague results
Embrace Evolution: Tech constantly changes; while core concepts remain, tools and frameworks evolve
AI as an Enabler: It can help experienced developers work with unfamiliar technologies more effectively.

For experienced developers, this can be a true game-changer, enabling them to work XX% faster even when dealing with unfamiliar technologies.

For junior developers, it’s a powerful learning tool, accelerating their understanding of new technologies. However, there’s a potential downside: relying too heavily on AI could hinder their ability to develop essential skills and gain a deeper understanding of what’s happening “under the hood.”

For non-technical individuals, as of 2024, it might still be a bit early to create fully functional code from scratch without a technical foundation. That said, it serves as an excellent communication aid, empowering them to convey their ideas to developers with greater clarity and precision. At this point of time (and it could change), I don’t see AI replacing developpers, because it required me using my experience and knowledge of the

P.S. Did my evil plan work? Absolutely. My success rate for getting into cancelled CrossFit slots jumped from 20% to 100%. More importantly, it freed my mind from having to constantly be prepared to jump on my phone for cancellations notifications. Sometimes the best coding projects start with a selfish need!

This post was written by Tristan Bessoussa, CTO at Wamiz (Nestlé), where I am exploring ways to blend technology with practical solutions - even if it means gaming the system for a better workout! 💪

This post was then enhanced by AI, and If you read this it until the very end, it means the AI was better at writing than me

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 ⚠️

How Serverless Saved Us For $2.

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

You’ve probably heard or seen words “serverless” or “FaaS” -Function as a Service- over the past few months asking yourself, “ok, is this hype or does it actually have some benefits” ?

Well, I’m going to share a feedback for our use case at my job that will illustrate why going serverless helped us achieved what was asked.

To achieve our goal we used the following products/framework/libraries:

My team works with PHP7, Symfony and Vue.js.

You can contribute to this article for any typos or errors you may find by submitting a pull request

The need: Generate PDF analytics reports

Here’s the user stories:

“As a customer of the CMS, I should receive each month a PDF report containing serveral analytics for my website”
“As a reseller of this group of customer of the CMS, I should receive each month a PDF report of each customer’s reports (containing a part of each)”

In two sentences, for our few customers with this feature, we’ll have to generate 2,000+ PDFs. Here’s what it looks like for one of the PDFs we have to generate:

PDF result

VPS / Dedicated server option

You could setup a cron job on one of your servers and it will take care of launching a command to generate the PDF. The main problem: it doesn’t scale.

~20 seconds (pdf generation) x 2,000 PDF = 11 hours of PDF generation

Average of generation is 2 seconds, but on a heavy PDF that contains multiple pages of multiple reports it can require up to 30 seconds.

During those 11 hours you’d need to ensure that the generation can survive that long (through app deployements, server restart etc…) and a way to monitor that the process is running, for example using Supervisor.

It would also require you to code the whole process using “defensive programming” in order to ensure the continuing function of your code under unforeseen circumstances.

Since we run a PHP app, it’s not multi-threaded, meaning, we can’t easily take advantage from all the CPU cores of our dedicated server. One of the options, if we want to achieve concurrency, is to rent more servers which we have to deploy, provision and manage.

Serverless option

Here’s the workflow of our setup.

PDF generation serverless architecture with 2 Symfony apps.
Full HD image for the serverless architecture.

PUML diagram of the PDF generation workflow

Step 1: preparing the data

Since this PDF is an aggregation of multiple external and internal data, you will want to have the data ready when you’ll generate the PDF. The CMS application (app #1, PHP/Symfony) is responsible of gathering and storing all the data that is necessary to build the PDF into a Redis instance.

Since we want to achieve scalability, you don’t want the service responsible of generating the PDF to ask via an API the data to the app #1 because it would become a bottleneck if 3,000 simultaneous lambda would send requests to your API.

Step 2: create async messages

Now that all the data is ready, the app #1 is crafting the data in a message, wrapping it inside an enveloppe using Symfony Messenger in order to send the messages to an Amazon SQS queue.

Note for Symfony users: because the messages will be read by another (Symfony) application, you must use a custom message serializer. You can read more on a RFC I opened on Symfony repository.

Step 3: store messages in a queue

As soon as the messages arrive inside an Amazon SQS queue, it triggers an action on our lambda running our code to generate PDFs.

Note: our message structure (Plain Old PHP Object) is stored in another git repository. Why ? because both app #1 and app #2 need to have this POPO, so chances that a developper would update the message structure on app #1 but not on app #2 were an unecessary risk.

Step 4: generate the PDFs

Up to 3,000 lambda instances are started, that’s some serious scalability there (in our case we limited it at 50 concurrent lambdas). Each lambda receives one message containing the data to generate 1 PDF.

Then the lambda runs our app #2 (PHP, Symfony) responsible of rendering a view inside a web page using a simple .twig templates with some javascript to render charts.

Then the code uses Browsershot, which transforms a web page to a PDF by using a headless Chrome controlled via pupetter to visit the URL that renders the .twig template which will become our PDF.

Once the PDF is generated, it’s stored in a S3 bucket.

We used Bref.sh around Symfony; It’s awesome because it provides lambda integration for your favorite PHP framework and also different PHP runtime that will run on the lambda.

All the 2,000 PDFs are generated within 2 minutes

Step 5: email the PDF to the client

The architecture image is only a part of what really happens. Because once the PDF has been generated in the bucket, we generate a new Message, send it to another SQS queue, and then, this particular queue is using app #2 again (but another part of the code) to send an email to the client with the PDF attached and notify the CMS application so clients can download their PDF through the backoffice too.

Comparison

	VPS or Dedicated server	Serverless
Complexity	Low	Medium
Cost	Expensive	Cheap
Scalability	Complex	Very scalable

Conclusion

One of the main advantage of using serverless architecture is that you get billed only for the time it was required to run the code.

You also don’t have to take care of where or how it runs. You just ship code and it runs in the cloud. The cloud provider is responsible of managing the allocation of the machine resources.

In our example, using the free tier of Amazon Lambda and Amazon SQS, generating 2,000 PDFs is costing us ~$1.63 ($1.62 for SQS, $0.01 for Lambda). You can use this serverless costs calculator to get better insights.

If you think you have some part of your code that could benefit from being moved to a serverless architecture, I would advise that you start with a very simple POC so you can get familiar with these new concepts. We did that with a small portion of our code before even attempting to solve the PDF problem to better understand the full ecosystem (queuing, lambda, notification…). We now have 5 lambdas doing specific jobs (outside the PDF needs).

You can read more on this from a more technical point of view: Generate PDFs on Amazon AWS with PHP and Puppeteer, written by Hugo Alliaume, who helped a lot on this subject. It contains a lot of details, such as how we shipped chrome into the lambda.

How not to be depressed when working with WordPress

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

Ok, so you chose to start a new WordPress project (or someone chose for you)? Well good news, it’s 2019, it doesn’t have to suck from the start anymore;

In this article, I’m not going to explain everything in details, that would require me to write a book about it. I will just point out directions: what you can do better than the broken official way of doing that was legitimate 10 years ago. It’s designed for everyone, web developers, backend developers, front-end developers…

I promise you that there is no more than 3 minutes of reading per chapter.

In the company I work for, we have 150+ WordPress sites. I made the decision for the new ones to adopt everything I wrote in this article, and slowly migrate the legacy ones. Already ~10% of them are using this architecture at the time I was writing this article.

Note: I’m accepting pull requests to fix english mistakes if you catch them.

Use Bedrock Edition

It’s THE starting point of this article. Bedrock is a WordPress boilerplate created by Roots. It leverages the use of modern development tools and embrace the 12 Factor app methodology. Some of the things WordPress can’t/won’t do because of their dinosaur 🦖 status in the PHP world.

The main advantages of this boilerplate are:

Support of environment variables

If you worked with modern software applications, you’re familiar with the concept of having your application configuration stored as environment variables.

The benefit of having environment variables is for you to have multiple environments such as production, staging and development where you can for example only enable sending emails on production, without the need of constantly changing values depending on which environment you are.

In 2019, every major frameworks has a concept of environnement variables in the PHP world: Symfony, Laravel, Yii. It’s a common practice that exists since decades on Windows and Unix world.

Environment variables can be stored as a file, for development and injected in your web server for staging and production environments. Don’t freak out, a lot of decent hosting companies provide an UI to manipulate environment variables. For example, look at what Heroku does for environment variables.

Environment variables look a lot like this:

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

Better directory structure

Everything is organized better and as a result, it’s easier to find what you were looking for. The structure look likes:

├── 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

Bonus point to security since the web root (entry point of your application) web/index.php is isolated from the rest of the structure. It means that your visitor can’t access your config/production.php file since it’s outside web/.

Reproducible builds

The concept of reproducible builds can sum up as: no matter when or where i’m going to build and deploy the application, I will always have the same version of the code (and plugins).

Since you’re going to be working on you local environment (if it’s not already the case 👀), you need to guarantee that what you have on your computer will be exactly the same that what you’ll have on your production. Let me take an example on why this is important.

Let’s say you’ve been running a website in production for like a year until there’s a nasty hardware crash on you server. Now all your files are lost. Luckily for you you did things right and had your uploads/ directory and database backup somewhere in the cloud.

The next step will be to re-install WordPress using the database and media backup. Then re-install the 20 plugins you had on that website. In one year, plugins evolve (and it’s good), but your theme, or some of your features might not be compatible with WooCommerce v3.5. It might result of a broken website.

Another example is when you’re working as a team on a project, without reproducible builds you will end up with the frontend person working with WordPress 5.1.1 while the developer still has version 4.9.10 and won’t be able to reproduce the bug you have with that setup.

Because of this concept, you’ll need to forbid any type of plugins/themes installation or updating from the WordPress backend. By default Bedrock will take care of this when you are in the production environment. Since WordPress is also a composer dependency, updating it is as simple as composer update roots/wordpress.

But how to guarantee reproducible builds? Well the answer is just below: use Composer.

Use Composer

Bedrock boilerplate allows you to manage dependencies of your project using Composer like any modern and decent PHP project should do (WordPress, I’m looking at you right now).

Do you want to install WooCommerce? Go inside your terminal and type:

composer require woocommerce/woocommerce

It’ll fetch the latest version and freeze the version you got on your composer.lock. This file is what is used to always get the same version of everything no matter where you download your project dependencies, or where you do it when you run composer install. Because of the importance of this file, it has to be committed ⚠️.

A good article can be found on how to use composer with WordPress on roots.io website.

All the plugins are also installable via composer; How? 3 scenarios are possible:

The plugin provides a `composer.json`

The developer or company behind the plugin is not locked in a WordPress thing of the past syndrome and has developed modern applications. This would mean that their plugin also ships a composer.json file that allows installation through composer. With this scenario you can search for your plugin inside packagist.org which is a repository containing all the public PHP packages in the universe ✨.

The plugin does not provide a `composer.json`

If you don’t see the plugin on packagist.org, then the plugin does not have a composer.json file. Don’t worry, wpackagist comes to the rescue. Outlandish created this project to offer a way to install 100% of the plugins and themes using the main WordPress repository. So, this particular WordPress plugin cannot be found on packagist.org, so let’s use wpackagist instead:

composer require wpackagist-plugin/cookie-law-info

The plugin is a paid/private one and does not have a `composer.json`

You’ll have multiple options from there:

Open a ticket to their support or on their Github and ask to provide a way to install their plugin via composer. You are their customer, you are paying for a product that you can’t install in a proper way. They should care.
- 👎 Bad players are ACF Pro, Elementor Pro, Formidable Forms
- 👍 Good player is Deliciours brains (Migrate DB Pro, Offload Media…).
Use alternative solutions when available.
Create a new private Github repository (it’s free), copy/paste the code there and add a composer.json like in this example, tag a new release using Github releases, and then require this package using a custom repository. All the procedure is listed in detail on roots.io website. I’d advise, if you have the budget for, to use Private Packagist to host your private packages.

Use a better templating system than PHP: “I’m yelling timber”!

What about the templating system? PHP is not a good templating system. Hard to read, hard to write, and let’s not fool ourselves, we’re no longer in the early 2010, we have tools created especially for each use case. The best PHP templating system is Twig. It is widely used in the Symfony ecosystem (but not only).

So how can we use Twig inside a WordPress project? Luckily for us, there’s a project called Timber.

Plugin to write WordPress themes with object-oriented code and the Twig Template Engine

It adds a View / Controller model that will have a huge benefit on the readability and the maintenance of your theme.

Once you start writing your themes using Twig, you won’t go back to plain PHP. Period.

Pro tip: Since you’re not designing your themes with plain PHP anymore but with Twig, the server needs to transform your .twig files into .php files. This phase is called compilation. It adds extra time to do that. Luckily there’s a cache system that stores the compiled templates on your file system so Twig doesn’t recompile your twig templates on each request that your server needs to process.

By default, Timber does not activate that cache.

Here’s how to activate it safely. You’ll save up to 40% of generation time by doing so. Inside your theme’s functions.php:

// Activate Twig caching
if (class_exists('Timber') && WP_ENV === 'production') {
    Timber::$cache = true;
}

// Replace WP_ENV === 'production' by!WP_DEBUG if you are NOT in a Bedrock structure

Difference of rendering time before/after enabling Twig cache system. More details on this Blackfire trace.

Note that it caches the the compiled php template and not the data. Any edits made to the .twig templates on the production won’t be reflected unless you clear the cache. (Who edits files on production though? 😱 Certainly not you!)

Prefer storing your assets on the cloud

Storing your assets on the local filesystem under uploads/ directory is nice, but at some point, you’ll have to synchronize this folder through all your environments, otherwise your local version will a complete different set of medias than the production and vice-versa.

Remember when we talked about reproducable builds? Wouldn’t it be nice if we can store our media remotely so we don’t use local filesystem? Spoiler alert, yes, it’s nice.

The one other major advantage of this technique is allow your website to scale to receive a huge spike of traffic load. All you have to do is to add more servers (horizontal scaling), since you have a reproducible build, the project and plugins will be the same on server number 1, 2, … 23, 24.

Services you can use to store your media on the cloud :

Amazon S3. The most famous, yet, not the cheapest one 💸.
Digital Ocean Spaces. S3-compatible, 45 locations available.
Scaleway. Cheap storage, S3-compatible but only 2 locations available (Paris and Amsterdam).

✅ Remember to always use a bucket location near where the majority of your audience live. I would advise you to choose a “S3 compliant API” since there’s not much WordPress plugin that allow you to use a remote storage that work in majority of use-case.

Here’s a list of free plugins that allow you to store your media on different cloud storage:

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

My wish for WordPress is for them to use an filesystem abstraction such as Flysystem. This way, we no longer have to rely on plugins to hack into WordPress to tell it to upload medias and assets elsewhere. Until this happens, you can use one of the plugins above.

Know tools you’re working with: ACF can hurt your website performance

If you’re a user of Advanced Custom Field, known as ACF, then you must know some of the performance bottleneck you might have if you’re abusing the get_field function.

You must only expose the variables you need per page. I’ve seen a lot of example, even in the documentation, where you are invited to do:

$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.

When you do that, it will trigger one database call per field you’re getting. So let’s say you have 35 fields under the option category, it’ll trigger 35 database call just to get those fields, but, do you really need those 35 fields on all pages?

What to do instead?

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

{# use them inside your .twig template; #}
<footer>
    <a href='{{ options.twitter_link }}'>Follow us</a>
    <img src='{{ options.logo_footer_img }}' />
</footer>

In real world project, doing this kind of optimization leads to important performance improvements.

Difference of rendering time before/after retrieving only the strict necessary ACF fields. -850 requests to the database and -37% of rendering time! More details on this Blackfire trace.

Explicit is better than implicit. It helps your colleague to provide a more accurate code review of your work. That work is harder when you don’t know what your template has access to.

And what about videos and images fields? If you are using them, you should know that if you retrieve them “as is” using the get_field('my_youtube_video'), the code will try to fetch the metadata (size, orientation, length…) of the videos and images.

What’s the matter here? Well, since you’re hosting your medias on the cloud (or a remote service, eg: YouTube in this example), the video and images has to be downloaded on the server side to allow retrieve this information you won’t need in 98% of the cases. In this situation doing external HTTP calls from your server to the internet adds precious extra time and kills your site’s performance.

I’ve seen project spending almost 1 second doing external calls, preventing the server to send HTML to the browser by fetching just 10 images information from the cloud.

In those cases you need to use get_field('my_youtube_video', null, false). The last option (false), tells to retrieve the field (in this case, the YouTube url of the video, without any formatting or additionnal treatment). One other case is to set the configuration of the field as a “URL” field, (and not oEmbed), and for images, “Image URL”

Difference of rendering time before/after configuring fields as URL fields instead of oEmbed. All the external HTTP calls the server made to fetch the metadata of images or videos were eliminated (-7) and it saved 35% of time (-846ms)! More details on this Blackfire trace.

Lint your code

Is your theme shipping CSS, Javascript and some PHP? You should lint them, make sure you write code compliant with industry standard. Use:

ESlint - Javascript
stylelint - CSS
Prettier - Javascript, CSS…
PHP-CS-Fixer - PHP (Example of our .php_cs_dist file that contains linting rules)

Use whatever building tool/task runner you feel comfortable with (Gulp, Brunch). If you don’t have picked up a tool yet, and you need a simple one, I’d suggest you take a look at yProx-CLI that we’ve been using at Yproximite for some times and just released as an open source project.

For your own sanity, please don’t open code you’re downloading from the plugins you use. You might be shocked by the poor code quality you’re dealing with and might end up re-writing a whole lot of WordPress plugins.

Use a continuous integration (CI) service

Use a CI (Travis, Gitlab, CircleCI, Jenkins). Here’s our base .travis.yml file that ensure our composer.json is valid, that our PHP Code is linted and same goes for our JavaScript files; No pull requests should be merged if you have linting errors that will never be fixed once they hit the production. This will allow your peer to review your code and focus on important things.

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;

Setup an automated dependency updates tool

Since we have 150 WordPress projects in our organization, running composer update on all of them once per week is not something we want to do, we had to figure how to handle the updates.

We were using ManageWP to update WordPress and all of their dependencies, but this option is now off the table since it breaks the concept of reproducible builds. Nothing should alter/mutate your environment. The code should be exactly the same like in your git repository.

One viable option for us was to delegate the updating process to Dependabot which job is to open a pull request when updates are available. Alternatives exists, for example, Renovate.

We configured it to automatically merge the pull requests if the package update is a major or a minor (v1.0.0 -> v1.1.4 will be merged automatically, but v1.0.0 -> v2.0.0 won’t);

⚠️ The WordPress ecosystem does not necessarily respect the SemVer, because… (I’m still looking for a reason…).

Since we choose a “Platform as a Service” (PaaS) to host all of our WordPress, as soon as a pull request gets merged on master branch, the project gets re-deployed on the production.

No matter which hosting you chose, you should have automatic deployment, otherwise, the project will be up-to-date but will never hit the production if you need to re-deploy each project if you have a huge amount of them.

Choose the right hosting

I would strongly advise to go for a PaaS. The main advantages of a Platform as a Service (PaaS) are:

No maintenance needed for the server or the software
Automated deployments
Vertical, horizontal scaling ready
Cheap
Easy
Isolated (no cross contamination from one site A to site B when hosted on the same server)

Some examples of PaaS are:

🌍 Heroku (from 14$/month)
🇫🇷 Scalingo (from 10,80€/month)
🇫🇷 Clever Cloud (from 26,50€/month)

⛔️ Don’t ever use a FTP or a SFTP to deploy to the production. Since you need to build your project by running composer install and maybe build assets by running yarn build, the long dead process of copy/paste the project on your FTP are definitely and finally dead ⛔️

What you should already be doing

Here’s a list of things you should already be doing, so they don’t deserve a chapter on their own:

Work with a Virtual Machine, that will allow everyone to have the same environment. You can use trellis or manala if you’re more technical
Use the latest version of PHP available
Work with pull request
Review, and ask reviews on your code by your peers
Configure Github to disallow pull request merging if your pull request doesn’t have reviews.

Note for WordPress plugins developers

In order to make the WordPress ecosystem a better place please, you have to respect at least 5 things:

⚠️ Don’t assume that your plugin user will stores their uploaded files on the local file system. Assume they don’t. Abstract your file manipulation by using for instance Flysystem.

The main reason behind this reasoning is:

When hosting your application on the cloud, you might want to be able to scale your application by adding new servers.
When you host your WordPress on an immutable infrastructure, which basically means
- Either you’re not able to write to the server, preventing any modifications
- Either the modifications your made are lost when the project gets redeployed. (A deploy happens each time you merge code on your code repository or when you scale (add or remove servers) on your application. Only what is on your git repository gets deployed on the server.

⚙ Provide a way to configure your plugin through environment variables, and use a fallback using the database if the environment variable is not found. Environment variables > Configuration stored inside the DB in terms of importance; This allow us to automate plugins installation and put all the configuration in one place.

🎻 Make your plugin installable with composer, it requires a composer.json file with 10 lines of code at the minimum. Just watch some examples here, here or here. The next step is to tag your releases using Github Releases respecting SemVer and submit your package to packagist.org by entering the Github URL of your repository.

🔒 Support maintained version of PHP

💅🏽 Lint your PHP code using PHP-CS-Fixer FFS! Choose between PSR2 or Symfony preset, but use one and fix your code.

Conclusion

If you want to look at a project structure implementing the majority of the point made in this article, you can take a look at my WordPress boilerplate example based on Bedrock and Timber. This repository should not be used “as is”, but it’ll help you understand how to structure your project files.

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

How I Used AI to Hack My CrossFit Waitlist Problem (and Why It Changed My View on AI Development)

The Problem: CrossFit Class Booking Blues

The Light Bulb Moment

Enter AI: My Unexpected Coding Buddy

The Reality Check: AI Isn’t Magic, It’s a Partnership

The CTO Perspective: A Game-Changing Realization

Key Takeaways

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

How Serverless Saved Us For $2.

The need: Generate PDF analytics reports

VPS / Dedicated server option

Serverless option

Step 1: preparing the data

Step 2: create async messages

Step 3: store messages in a queue

Step 4: generate the PDFs

Step 5: email the PDF to the client

Comparison

Conclusion

How not to be depressed when working with WordPress

Use Bedrock Edition

Support of environment variables

Better directory structure

Reproducible builds

Use Composer

The plugin provides a composer.json

The plugin does not provide a composer.json

The plugin is a paid/private one and does not have a composer.json

Use a better templating system than PHP: “I’m yelling timber”!

Prefer storing your assets on the cloud

Know tools you’re working with: ACF can hurt your website performance

Lint your code

Use a continuous integration (CI) service

Setup an automated dependency updates tool

Choose the right hosting

What you should already be doing

Note for WordPress plugins developers

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

The plugin provides a `composer.json`

The plugin does not provide a `composer.json`

The plugin is a paid/private one and does not have a `composer.json`