Rise of Serverless services such as AWS Lambda, Fargate, Google cloud run has paved the way for highly scalable architectures that required complex manual setup in the past.
The concept is pretty lucrative. You upload the code or a container, and your cloud provider takes care of everything else. If you get 10,000 visitors at the same time, your cloud provider starts 10,000 ephemeral containers to serve that traffic. Since you pay by the second, total cost for this traffic is mere cents or sometimes a dollar.
How does this work with WordPress or WooCommerce?
Well, WordPress and Lambda (Or any other FaaS) don’t really play nice. You need several hacks and workarounds to get vanilla WordPress up and running. If your site has plugins that rely on the filesystem or sessions, it makes things further complicated.
Contrast this with container services such as AWS Fargate and Google Cloud Run. These services spin up your container and assign it a URL where you can send your visitors. If you get more than 1 concurrent visitor, more containers are spun up.
Since you control the applications inside your container image, running WordPress becomes much more manageable in this case. Plus, you don’t have to use a Node.js wrapper to launch php executable as in Lambda.
So should you ditch your servers and go all-in on container services for your WordPress site?
Probably not! Here’s why.
All of these services suffer from cold-start. It’s the duration between visitors making the HTTP request and the time it takes to spin up a container and deliver the HTTP response. If your site doesn’t have a steady stream of visitors, cold-start can be 30 to 60 seconds long.
Visitors these days expect sites to load in under 2 seconds. Are your visitors going to stick around an extra 30 seconds while the containers spin up?
And even if your site has a steady stream of visitors, only some of them are served by existing containers, while others experience cold-start.
This inconsistent performance lowers the conversions and negates any cost savings introduced by per second billing.
Now I understand that there are ways to keep the containers and lambdas warm using automated pings, caches, and provisioned concurrency. But then you lose out on the cost-savings by running containers 24×7 instead of launching them on demand. Plus, you need to stay on top of warming additional containers if you anticipate additional traffic.
So does this mean that serverless is not suitable for WordPress?
In my opinion, a server+serverless hybrid approach makes more sense for WordPress for now. Tasks like image optimization, cron events, subscription renewals, email notifications are highly resource-intensive, but they can tolerate cold-starts. Offloading such tasks to containers can help you cut down on the infrastructure costs without sacrificing site performance.
As the serverless and WordPress plugin ecosystems mature, you’ll be able to migrate more and more tasks from servers to on-demand containers.