DevOps life (English)

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

A healthy development environment in 2021: hello Docker, goodbye virtual machines

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

Background

In May 2015, Yproximité dropped its “spend 1/2 a day installing everything locally by hand” model in favor of a virtual machine provisioned with Ansible playbooks, so that a single command would get the development environment up and running within a few minutes.

To run our Symfony projects, you had to install:

Make, to run the commands
VirtualBox, for the VM
Vagrant, to drive the VM
Vagrant Landrush, a DNS server to reach the development URLs
mkcert, to generate the local TLS certificate

All you then had to do was run make setup in your terminal: about twenty minutes later, the project was fully up and running, the database data imported and the whole team on the same minor versions of PHP, Nginx and PostgreSQL.

❤️ I’d like to take this opportunity to thank the contributors to manala.io, a project run by my former web agency, Elao, and especially Nervo, who maintains the various Ansible roles. Thank you for your open source contributions, and for keeping our development setup running for 6 years.

Fast forward to 2021. What pushed me to plan a new development setup and walk away from the virtual machine (VM) model?

Why move away from virtual machines?

Several arguments made the case for dropping VMs:

Docker keeps maturing and is well adopted by the web community for development environments.
Performance lags a little behind a local install of the project (especially on Linux, if my team is to be believed).
The size of the virtual machines (count on several GB per project).

Even so, I was very reluctant to adopt a development setup based solely on Docker. With a small team and no particular Docker expertise (especially on the macOS vs Linux performance issues), that choice is a risky one for the stability of the development environment, which is there to help developers be as productive as possible, not to frustrate them or slow them down.

I knew VMs would soon be shown the door, but was that enough to set a deadline for moving to something else? To plan training? To move our dozens of projects to a new, Docker-based development environment? Not quite…

What finally tipped the scales towards “something else” was a low-key announcement from the VirtualBox team saying they can’t technically port VirtualBox to ARM processors. VirtualBox, which runs the VMs, is a hypervisor, not a CPU emulator, so it can’t emulate an x86 processor.

Why is that a problem? Well, you may have missed Apple’s announcement of its plan to move to the ARM architecture within roughly 2 years, starting with its “M1” chip (which packs a serious punch) in the 13-inch MacBook Pro, the MacBook Air and the Mac Mini. Given the extremely positive feedback from users, the company even seems to have sped up the rollout of the new ARM architecture, announcing the 24-inch iMac and the iPad Pro with the M1 chip just a few days ago. On the consumer side, only the 16-inch MacBook Pro and the 27-inch iMac have yet to make the jump.

Apple's ARM-based processor, the M1

I can see the Apple trolls coming from a mile away, but in my team I’ve always made a point of giving developers the choice between Linux and macOS (see the OS breakdown in the AFUP survey of French PHP developers). So please redirect the trolling to the only ones who deserve it: PHP/JS devs on Windows.

A Docker-powered solution, but not just Docker!

Given my company and my team, a Docker-only solution is a non-starter until the performance problem on Mac is fixed for good, or as long as it takes a Docker/Linux expert to implement it.

So I chose to push for a hybrid solution that avoids shared volumes (and with them, the performance problems). If I remember SymfonyLive correctly, that’s also what Fabien Potencier went for.

On the host machine (macOS/Linux):

PHP and Composer
NodeJS
Docker Desktop
Symfony CLI. It provides a web server with TLS handling, Docker support and per-project PHP versions.
The Manala binary (it generates your docker-compose.yaml from a template; see going further)

⚠ For all its benefits, Symfony CLI is not open source. Worth keeping in mind, especially if you rely on it for your development setup.

In Docker:

Database (MySQL, PostgreSQL, MariaDB…)
Redis server

List of Docker containers

Developing on this new hybrid stack is genuinely pleasant and fast: I get my machine’s native performance back.

Going further

Hugo Alliaume took over the POC I built in August 2020 and cleared every blocker. He tackled the problem head-on and saw the transition through across all of the R&D team’s projects.

He covers the more technical parts on his blog, including:

A deeper look at the limits of VMs and the workarounds they require
Why replace your web server / reverse proxy and local DNS with Symfony CLI
An example docker-compose.yaml
How to make the most of this development stack in CI, with GitHub Actions
How to go further with the manala binary to make management and maintenance easier (e.g. Makefile)

📖 I recommend reading his post (in French): migrating our development stack to Docker.

Installing the prerequisites on macOS

This section is for macOS users 🍎 who’d like to find all the steps for installing the tools on their machine in one place.

Prerequisites

Install brew, the package manager for macOS.

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

Install Zsh.

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

Installing 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

If your projects run on different PHP versions, no problem: install every PHP version they need, and Symfony will use the right one thanks to the .php-version file at the root of your project.

The PHP versions installed on your machine, as detected by the Symfony binary

Installing 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

Same idea for NodeJS: if your projects run on different versions, install every version they need. We’ll use nvm, which picks the right Node version for each project (the version lives in the .nvmrc file at the project root).

brew install nvm

Finally, so you don’t have to run nvm use to select the right NodeJS version before your yarn install or yarn dev-server, you can add this block to your ~/.zshrc (then restart your terminal, or run source ~/.zshrc). It checks whether your current directory has a .nvmrc with a project-specific Node version, and uses that version if it’s installed.

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: mux and tmuxinator

If you’re working on a Symfony project with JS that needs compiling, you’ll probably need 3 terminal tabs:

One session running symfony serve, the web server
One session at the root of your project
One session running yarn dev-server, to compile your JavaScript whenever it changes.

For extra comfort, I suggest using iTerm2 with the tmux terminal multiplexer. It lets you split a terminal window into several virtual terminals. In practice, when I run mux start <nom_du_projet> in my terminal, my containers start automatically, my terminal gets split, and yarn dev-server runs in a virtual tab, as shown below.

The Symfony CLI binary at work: on the left, the various steps to boot the project; on the right, the web server started by `symfony serve`, which will handle your requests

To get the same setup:

brew install tmux
brew install tmuxinator

Then add the alias to your ~/.zshrc:

alias mux=tmuxinator

Setting up a project is then pretty basic (with your project’s name in place of <nom_du_projet>):

mux open <nom_du_projet>

Then configure your project using the tmuxinator documentation, for example:

# /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

All that’s left is to remember mux start <nom_du_projet> and mux stop <nom_du_projet>, and you’re all set.

Spotted a typo? The original post (in French) is on my GitHub repository.

Test-driving Hidora, a Swiss PaaS

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

This post follows on from a series sharing hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In the original series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Although my quest to host our WordPress fleet came to an end in late 2019, I decided to try out Hidora, a Swiss PaaS 🇨🇭.

Hidora

Skip to the summary if you’re in a hurry

Building the application on Hidora

Hidora offers prebuilt installs for the main CMSs. However, you can’t choose which edition of WordPress you want: the only one on offer is the basic edition, not Bedrock.

So how do we build our WordPress, which needs its composer and javascript dependencies installed?

We ran into several difficulties getting our WordPress (Bedrock) project deployed:

Hidora’s PHP environments don’t ship with any Node.js runtime, so you can’t run yarn install && yarn build there to generate the css and js files. We had to identify which distribution the scaler runs on (CentOS), then install Node.js and then yarn by hand on the PHP node over SSH, after first asking support to give us root access to our environment.
When customizing the “post deploy” script to add our composer install, we expected to be at the root of the folder containing our deployed application. We weren’t. It wasn’t easy to figure out where to go to get into our application directory (cd $WEBROOT/app).
Unfortunately, there’s no bulk editing of environment variables. I had to enter 30 of them by hand, one by one: it takes ages. An editable text area where we could paste all our variables would have been quicker.

I think the frustration caused by all these problems and questions could be solved by publishing “cookbooks” that answer the questions new customers are bound to ask when they arrive on Hidora (e.g. how do I deploy a Symfony or WordPress application…). The only guides I found were those for the platform Hidora chose to run its cloud: Jelastic.

Screenshot of the admin interface:

Performance at Hidora

Here’s one of the infrastructure topologies running the WordPress site. The visuals make it easier to understand the setup and the resources allocated.

Example: I send 5 unique visitors per second to the home page for 2 minutes. No optimizations, except for pm.max_children set to 10.

For €10.8/month at Scalingo, I get an average response time of 492ms.

For €15.7/month at Hidora, I get an average response time of 2,048ms.

So performance isn’t good out of the box. I think better performance would be possible, but since I didn’t have to apply any other improvements on the other platforms I tested, I didn’t do it here either.

For more details, see:

Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Note that Hidora bills for the resources you actually consume. We can reserve 2GHz of CPU and 2GB of RAM, and allow consumption of up to 6GHz and 6GB of RAM. If your application sometimes uses 3.4GHz of CPU, you’re only billed for that consumption, not for the maximum you chose (6GHz), which helps keep costs under control during load spikes.

Hidora summary (TL;DR)

👎 Cons

Interface based on Jelastic: it’s complex and not very sexy.
The Jelastic interface could have been more UX-oriented.
The flexibility can lead to bad practices (= editing config files by hand on the servers)
Not really a 100% “PaaS”: you end up installing things manually over SSH with apt
The application is built on the same machine that runs the code. I had to increase the platform’s available RAM just for the build, even though the run didn’t really need it.
No easy (1-click) way to offload the application build to a separate, bigger scaler so you only pay for that scaler while you actually need it.
Weak out-of-the-box performance (without any optimization work)
Support doesn’t offer a “live chat” channel

👍 Pros

Interface based on Jelastic: in-house resources go to something other than building the UI.
Very flexible (root, sFTP, ssh access). That’s great if you have lots of integrations that other PaaS providers don’t support.
Lots of supported technologies, including Docker
Support took the time to work through some of our issues over video call, with screen sharing.
The data is hosted in Switzerland.
With flexible resources, you’re billed for what you actually consume.

Verdict

I’m not sure I can recommend Hidora in a scenario where a developer is in charge of configuring and deploying an application (as can be the case in small teams). The UI layer provided by Jelastic is, in my view, fairly hard to get to grips with, and the experience calls for more “infra / ops / run” skills than the other 100% PaaS hosts I’ve covered in this series.

You can end up doing a hybrid of operations: configuration through the UI, as you’d expect from a PaaS, but also, more surprisingly, editing configuration files (php.ini, vhost.conf) over sFTP or SSH, which feels like configuring a dedicated server or a VPS.

For customers discovering the Jelastic interface that Hidora uses, a screen-sharing session with support is a must to make sense of it all.

⚠️ My opinion of this host only covers the way I used it. Honestly, I’m not sure my use case gets the most out of this host ⚠️

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.

PaaS benchmark: Clever Cloud vs Scalingo vs Hidora

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

This series of posts shares hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In this series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

EDIT 01/21 The performance tests have been rerun. The first batch, from 2019, is available here: all ~80 tests from the 2019 PaaS performance comparison between Scalingo and Clever Cloud; it contained 80 tests. In 2021, I kept the tests much more concise; they’re available in this spreadsheet.

Measured performance

Included in this benchmark:

✅ Clever Cloud
✅ Scalingo
✅ Hidora
⛔️ OVH Cloud Web (couldn’t get the project running, see Part II)
⛔️ Platform.sh (too expensive for our WordPress use case)

The tests were run under real-world conditions. I took a “representative” WordPress site that’s already in production with us. These aren’t tests on a plugin-free WordPress with a single blank page.

I ran the tests with a load testing tool (k6.io) from a server in Paris, FR: 5 unique visitors per second for 2 minutes.

The tests were run under the same conditions on every PaaS: same versions of WordPress and the plugins, same page tested. No optimizations, except for tuning the pm.max_children variable to handle request concurrency in php-fpm.

Before recording the results, I spent some time finding the optimal value for the pm.max_children setting, which tells each scaler how many concurrent PHP requests it can handle.

Set it too high, and performance tanks because there isn’t enough RAM (it swaps). Set it too low, and the scaler is throttled, and so is your performance.

⚠️ Note that the number of unique visitors varies, even when the test is set to 5 unique visitors per second for 2 minutes. I never got 5x60x2 = 600 requests. So remember to look at the number of requests the server actually had to handle. ⚠️

Test results (excerpts)

5 clients per second over 2 minutes

	Price/month	Details	DB	Average (ms)	Number of requests
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	1,110	237

Test setup

The Bedrock edition of WordPress, which makes WP compatible with PaaS hosting, on top of providing modern tooling (configuration through environment variables, WordPress plugins managed with composer…)
PHP 7.4.x
Site 1
- WordPress 5.6.x
- List of dependencies and plugins: composer.json
pm.max_children is set to 10

French PaaS providers are in a boat: Platform.sh lies at anchor

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

This post is part of a series sharing hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In this series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Platform.sh

Skip to the summary if you’re in a hurry

Our custom Symfony projects are hosted at Platform.sh (~7 projects).

I quickly ruled it out for hosting 120+ WordPress projects, because the pricing doesn’t fit our situation at all.

€40 for 0.8GB of memory, and that memory is shared between the application containers. So 800MB of memory split between the web container and the database container: not exactly the stuff of dreams…

Memory allocation across Platform.sh plans. For a service with PHP and a database, the S plan won't be enough.

The next plan up is €100/month. At that point, we’re multiplying our spending by 10, even though, in our case, we had no use for the feature that lets you run different environments.

Managing environment variables is, how shall I put it… complicated. You’d think the variables tab on the branch in question would be enough? Actually, no: those variables are only available at runtime, not at build time.

To add build-time variables, you have to click on a 20 by 20 pixel area that isn’t highlighted at all, then add the variables there. So you often end up adding the variables in the project configuration, then duplicating them in the master environment’s configuration so that the other branches inherit them.

Note that there’s no “Bulk Edit/Add” mode for environment variables.

The UI and UX/DX need work, because the interface is a regular source of frustration (on top of being slow).

Incidents are frequent (or else I’m just unlucky, and on the rare occasions I need Platform.sh, there’s an incident…), along the lines of “huh, my builds are stuck” or “the application isn’t auto-deployed anymore, so the fixes I thought went to prod 7 days ago never made it”. Fortunately, production never went down on our projects, but these recurring problems when using the PaaS wear you down.

To illustrate: from December to January, there were 10 incidents listed on their status page, some of them major (not counting maintenance). As I write this post, my team tells me they’re still blocked from deploying some environments.

Platform.sh summary (TL;DR)

👎 Cons

Expensive
No automatic scaling
No way of knowing how many resources you’re using
Very slow, unsexy interface
Environment variable management
Recurring incidents
A deployment hook that you regularly have to delete and re-add to keep the project deploying automatically
No monitoring tool in the interface for creating alert rules (e.g. post a message in Slack if RAM >90%). There’s only a disk space check
Backups aren’t automated, or even offered as an automatic option. You have to set up a snapshot cron yourself

👍 Pros

You can easily deploy branches as environments for demos or staging
Environment variable inheritance, which makes it easier to create other environments
The production database is copied when a new environment is created

⛔️ VERDICT: ELIMINATED ⛔️

I didn’t run any WordPress benchmarks, since the projected cost of migrating to them was already a dealbreaker.

Read part VI

Part 6. PaaS comparison: performance, Clever Cloud VS Scalingo

French PaaS providers are in a boat: Scalingo stays afloat

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

This series of posts shares hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In this series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Scalingo

Skip to the summary if you’re in a hurry

Scalingo is a PaaS I had never heard of (not even on my Twitter timeline), so I added it to my list of “candidates” somewhat reluctantly.

Here, onboarding is very simple. I didn’t have to go and negotiate a budget just to test the service: everything is billed by the minute. That alone makes every service that bills by the month look badly dated.

If your site gets featured on Capital, the prime-time French TV show, you can order XX extra scalers so the application handles the load, and only get billed for the 20 minutes during which the segment talks about you. The same goes for the database, to raise the infamous concurrent connection limits (though in that case, you’d be better off switching the site to read-only and putting a reverse proxy in front of it) and the RAM.

The interface isn’t in step with current trends: it looks a bit old-fashioned, but it’s pleasant to use and very snappy. Better that than a very “pretty” interface that’s poorly thought out and slow.

Building the application on Scalingo

You need to create a .buildpacks file at the root of the project, containing the URL of a Git repository that tells the PaaS how to build the application. In our case, it was: https://github.com/Scalingo/php-buildpack

The composer.json is then detected and, bonus, since they support the Bedrock edition of WordPress, I didn’t have to do anything to configure the NGINX vhost: it just worked (list of auto-detected PHP frameworks). That wasn’t the case at Clever Cloud, for example, where I had to specify where the application’s front controller was (web/index.php).

The application builds quickly, and I was able to move on to the tests.

Performance at Scalingo

The tests will speak for themselves in the dedicated chapter. Note that Scalingo crushes Clever Cloud, which doesn’t even pass some of the tests at an equivalent price.

A few times, we got much better performance at Scalingo on tests run on different dates. According to support, this comes down to the neighbors: scalers can move from machine to machine depending on their load. If we have neighbors whose scalers have a very high CPU priority (so they pay more) and who happen to be very busy at that moment, then less CPU time gets allocated to our lower-priority containers.

Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Scalingo summary (TL;DR)

👎 Cons

The UI isn’t very sexy, though it’s not a disaster either.
Autoscaling (in closed beta) that still needs a bit of fine-tuning
The log management interface could be improved visually
No GitHub Server support (for the deployment app)
No “big picture” view (yet) for portfolios with lots of projects
No reverse proxy (e.g. Varnish) that’s easy to configure from a .vcl file dropped at the root of the application, to boost application performance by taking advantage of the HTTP cache
EDIT 12/20 At least 2 major platform incidents in 2020, following DDoS attacks

👍 Pros

Competitive pricing
Everything is billed by the “minute”, even the database
Horizontal auto-scaling
Responsive support. EDIT 12/3/20 Still very responsive, and there’s often a developer on the other end who gets the problem right away and comes up with a solution quickly. That’s much appreciated.
Pleasant, snappy interface (UX/DX)
Easy control of pm.max_children from the UI (the MAX_CONCURRENCY variable)
Separate environments for the same application (prod/staging…), though not as easy as what Platform.sh offers, for example
Simple, fairly complete monitoring rules for your scalers, across several channels (Slack, email…)
EDIT 12/3/20 A more flexible environment than some PaaS providers when it comes to certain extensions: compatible with Blackfire, Datadog…

✅ VERDICT: SELECTED ✅

For me, Scalingo was THE pleasant surprise of this comparison. Its pricing is competitive for the market, with no compromise on performance. The main features you’d expect from a PaaS are there, and they work well!

Read part V

Part 5. PaaS comparison: Platform.sh

Disclaimer: the Scalingo links use a referral program tied to my personal account. If the other PaaS providers tested here had offered the same kind of referral program, I would have used it for their links too (for future POCs or small side projects).

French PaaS providers are in a boat: Clever Cloud rights the ship

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

This series of posts shares hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In this series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Clever Cloud

Update, January 2021: during 2020, Clever Cloud changed its database pricing, which considerably reduces the costs I talked about in this post.
What’s more, after a new performance test using the same project as in December 2019, default performance is much better than before (see the update to PaaS comparison: performance, Clever Cloud VS Scalingo).

Skip to the summary if you’re in a hurry

Clever Cloud is another French PaaS that kept popping up in my Twitter timeline whenever people asked where to host their projects. So I was keen to try it out.

On paper, the offering is sexy: vertical and horizontal (auto)scaling.

The database

When you sign up, first bad surprise: the database is billed by the full month, and it can’t be scaled yet, either automatically or manually, though that should change (soon).

	Clever Cloud	Scalingo
Max connections	75	62
Max DB size	10 5 GB	5 GB
Memory	1 GB	1 GB
Type	Dedicated	Dedicated (Software + RAM)
CPU	1 vCPU	Shared
Price	~~€45~~ €22/month	€14.4/month (billed by the minute)

Another red flag: Clever Cloud openly nudges you toward PostgreSQL, since for strictly equivalent resources, database containers are more expensive for MySQL.

We’re talking about a difference of ~~€180~~ +€54 a year.

They justify the difference by saying that a MySQL instance costs more to run than PostgreSQL, and their tech team prefers maintaining PostgreSQL.

For a Symfony application, switching to PostgreSQL makes no difference to me (or almost…), but with WordPress, we have no say in which database the CMS supports. So in the end, it’s the user who pays the extra cost.

EDIT 12/20 ~~Apparently, they’re reworking the pricing of their database scalers.~~ That’s now done, hence this update to the post.

Configuring the application on Clever Cloud

As with any application hosted on a PaaS, you go through the “environment variables” step. At Clever Cloud, it’s not very convenient. When I ran my tests a few weeks ago, there was no way to edit or add variables in bulk. When you have 20 variables to enter, what a waste of time! Fortunately, that was fixed recently with the addition of a bulk edit/add.

You can’t reference another variable (e.g. DATABASE_URL=$MYSQL_ADDON_URI), which is a shame.

Next, I wanted to deploy my WordPress. Unfortunately I couldn’t, because a dependency (wp-cli) required the PHP extension ext-readline, which wasn’t available on Clever Cloud.

I had to ask support, and as luck would have it, it was a Friday, so no production release possible before I left on vacation.

NB (not aimed at Clever Cloud): this absurd policy has to stop. I fully agree with the tweet below: at our company, Friday is a day like any other for deployments, because we made sure it would be (tests, automation, 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) December 19, 2018

When I got back from vacation, I still couldn’t build because of a mix-up: “the feature is enabled but not the extension”. Anyway, it came through a few hours later: the application could finally be built.

Building the application on Clever Cloud

So, how do you build on their platform?

Since the project has a composer.json, the PaaS fetches the dependencies automatically. But we build the theme with a yarn build task, so we need to be able to run a yarn install followed by a yarn build.

And that’s where it gets awkward, because it can’t work out “OK, I see a yarn.lock, so I’ll also run a yarn install && yarn build”. So you have to go through a Build Hook.

You set a variable telling it to use yarn as the package manager, then you tell it which commands to run and at which point of the build, for example: CC_POST_BUILD_HOOK="yarn install && yarn build"

Note that WordPress wasn’t detected automatically: I had to create a file named php.json in a .clevercloud folder so the router would know what to serve:

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

Performance at Clever Cloud

EDIT 01/21 The new pricing policies, along with many hardware/software improvements (datacenter migration + a better reverse proxy written in Rust), have let Clever Cloud drastically right the ship compared with the tests run in December 2019.

So the price gap is narrowing. My tests from January 2021 show that you no longer have to spend 5 to 9 times more money to get performance similar to one of its main competitors, Scalingo. It’s now closer to a x2 ratio. In other words: on our WordPress setup, Scalingo matches Clever Cloud’s performance for half the price.

Example: I send 5 unique visitors per second to the home page for 2 minutes.

For €10.8/month at Scalingo, I get an average response time of 492ms.

For €20.3/month at Clever Cloud, I get 588ms. That’s the minimum you have to spend to get similar performance.

Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

Clever Cloud summary (TL;DR)

👎 Cons

~~Disastrous price/performance ratio on WordPress~~
Database add-on pricing: ~~expensive, and~~ monthly commitment
No database scaling
~~No references to other environment variables~~
No GitHub Server support for automatic deployment
Interface sometimes unintuitive
Statistics (in BETA since 2019?)
No easy way to set pm.max_children from the UI (e.g. through an environment variable)
EDIT 12/20 Very little openness to the PHP ecosystem: APM / monitoring (no Datadog, blackfire.io, tideways.io)
EDIT 01/21 Good price/performance ratio

👍 Pros

Automated backups
Let’s Encrypt integration
Vertical and/or horizontal auto-scaling
Support that’s responsive when it comes to communication
Sexy, snappy interface
Clear log management
A home-grown alternative to Amazon S3, for mounting persistent storage
An optional reverse proxy (Varnish) that looks simple to manage
EDIT 12/20 Very stable (feedback from 1+ year of hosting a project with them)
EDIT 12/20 Multi-region support (with OVH’s help behind the scenes)

⛔️ VERDICT: ELIMINATED ⛔️

EDIT 01/21 Performance and price, the 2 problems that got Clever Cloud eliminated for our hosting needs in 2019, are now solved.

Read part IV

Part 4. PaaS comparison: Scalingo, staying afloat

French PaaS providers are in a boat: OVH falls overboard

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

This post is part of a series sharing hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.

In this series:

Part 1. Background to the French PaaS comparison
Part 2. PaaS comparison: OVH falls overboard
Part 3. PaaS comparison: Clever Cloud, ~~the boat is taking on water~~ the captain rights the ship
Part 4. PaaS comparison: Scalingo stays afloat
Part 5. PaaS comparison: Platform.sh lies at anchor
Part 6. PaaS comparison: Hidora, the Swiss cloud
Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora

OVH and its Cloud Web offering

Skip to the summary if you’re in a hurry

OVH is the latest arrival in the PaaS world with its Cloud Web offering. It’s not their area of expertise, and you can tell quickly. Very quickly.

First bad surprise: you can’t order a Cloud Web plan for less than 12 months.

If you don’t want to order a domain name with the Cloud Web plan (because you already have one), there’s no way to skip that step when ordering through the OVH web interface. You can, however, get around it by ordering the plan through the OVH API.

Apparently the teams are working on lifting these restrictions, but according to an internal source, it won’t happen for many months (no guarantees). But let’s be clear: some competitors offer per-minute billing, so shelling out ~€490 including VAT just to run a few tests on Cloud Web 3 is hard to justify. And if we project that onto our fleet of 120+ WordPress projects, it would mean an entry ticket of ~€60,000, with no guarantee that our clients stay with us for a year.

I got in touch with someone at OVH to report these issues. They offered me Cloud Web 3 free for 1 year in exchange for feedback on the product. Thanks for the offer.

As soon as I had access to the product, I wanted to switch to PHP 7.3 and create my environment variables so I could configure WordPress and run my performance tests. But I ran into problems, one of which stopped me from using the product at all:

PHP 7.3 isn’t available, even though it came out on December 6, 2018, more than a month before this post was written
No permission management (other than for the admin/technical contact), for example to let a group of people on a team manage environment variables
I created some environment variables: some were created within seconds or minutes, while others still said “Being created” after 15 minutes. I dug through the UI before finding out that the creation task for some of them had failed (with no further details)
No “bulk insert” for environment variables. Because of that, I had to repeat the variable creation process 20 times

The creation of these OVH environment variables has been 'in progress' for 14 days, with no way to delete or edit them

OVH support

With no way to edit or delete the “faulty” variables, I’m stuck in the middle of my setup, so I turn to support.

January 8, 2019: I open a support ticket to report that I can’t use the product because of my environment variable problem
January 21, 2019, 13 DAYS later: I get the first reply from support, which boils down to: “We apologize for the delay in handling your ticket; our administrators are looking into your request.”
January 23, 2019: I’m told that the failed operations have been canceled and invited to try again, with no explanation of what happened.

OVH Cloud Web summary (TL;DR)

👎 Cons

Annual commitment
No monthly payment
Can’t order without an associated domain through the web interface
Very thin, incomplete documentation
No Git deployment
No automatic deployment via a GitHub/GitLab app
No horizontal or vertical scaling
No auto-scaling
OVH support: steer clear
No permission management, for example to give a team access to environment variables
Poor UX/DX for managing variables, on top of being buggy

👍 Pros

Automated backups
Let’s Encrypt integration
OVH network
That’s about it… 🤷‍♂️😱

⛔️ VERDICT: ELIMINATED ⛔️

It’s hard to pass final judgment on OVH’s PaaS offerings when you can feel they still need to mature before they meet the market’s needs. Honestly, I was frustrated and disappointed that I couldn’t benchmark the performance of their Cloud Web 3 plan.

Unfortunately, my preconceptions about their support were confirmed, so I can’t recommend this offering to anyone for professional use: at the slightest problem, you wait weeks for support to reply (unless you hound them on Twitter), even when it’s critical for your service.

As for personal use, who can drop ~€490 in one go to host their personal “side project” on a PaaS? 🙊

Read part III

Part 3. PaaS comparison: Clever Cloud, the boat is taking on water

DevOps life (English)

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

A healthy development environment in 2021: hello Docker, goodbye virtual machines

Background

Why move away from virtual machines?

A Docker-powered solution, but not just Docker!

Going further

Installing the prerequisites on macOS

Prerequisites

Installing PHP

Installing NodeJS

Bonus: mux and tmuxinator

Test-driving Hidora, a Swiss PaaS

Hidora

Building the application on Hidora

Performance at Hidora

Hidora summary (TL;DR)

👎 Cons

👍 Pros

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

PaaS benchmark: Clever Cloud vs Scalingo vs Hidora

Measured performance

Test results (excerpts)

5 clients per second over 2 minutes

Test setup

French PaaS providers are in a boat: Platform.sh lies at anchor

Platform.sh

Platform.sh summary (TL;DR)

👎 Cons

👍 Pros

Read part VI

French PaaS providers are in a boat: Scalingo stays afloat

Scalingo

Building the application on Scalingo

Performance at Scalingo

Scalingo summary (TL;DR)

👎 Cons

👍 Pros

✅ VERDICT: SELECTED ✅

Read part V

French PaaS providers are in a boat: Clever Cloud rights the ship

Clever Cloud

The database

Configuring the application on 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`