DEV Community

Carl Alexander
Carl Alexander

Posted on • Originally published at blog.ymirapp.com on

What is serverless PHP and how does it work?

Serverless computing is a new cloud computing model centred on Functions as a Service (FaaS). A serverless PHP application is simply a PHP application that runs on one of those serverless computing platforms. But what's so special about it, and why is there interest in using it instead of a regular server for PHP?

Well, as web developers, we always have to consider where we host our code. It doesn't matter whether we're using JavaScript, PHP, Python or Ruby. (Just to name a few.) They all need a hosting service where that code can run and render the HTML sent to the browser.

There are a lot of different hosting services. You can pay for a server on DigitalOcean or some other some other cloud provider. This is often the cheapest option, but then you have a server to manage.

If you don't want to do that, you can use a Platform as a Service (PaaS) like Heroku. You tell them how big of a server you want and they take care of the rest. On your end, you just need to deploy your code and that's it. WordPress hosting works similarly.

While platforms as a service help you worry less about your server, they don't completely remove all server issues. You still have to wonder if you can handle spikes in traffic. That's because most of these services won't scale automatically to handle these scenarios.

Serverless computing offers a solution to this problem. It distills your cloud computing needs to its barest essence. Your cloud provider will run your code on-demand and only charge you for that.

This lets you only pay for what you use. (If your site receives no traffic, you pay nothing.) This architecture also lets you scale infinitely. In fact, serverless computing can scale to handle thousands of visitors almost instantly.

This is a transformative change for all programming languages. But even more so for PHP, since it's a language uniquely positioned to leverage the benefits of serverless. Let's explore why that is.

How does a traditional PHP application work?

PHP differs from most other programming languages because it's an interpreted language. You don't need to compile your code. You can just upload your PHP files to a web server, and that's it.

PHP server architecture

The web server (nginx or apache most of the time) does all the magic. It figures out what PHP file you're trying to access. Often, it's just the index.php file in the root directory which then loads other PHP files. (Fun fact: Pieter Levels makes $100k/month from a single index.php file!)

The web server then sends this PHP file to the PHP interpreter. The interpreter reads the file, parses it and then executes it. Once the execution completes, it'll return some output. That output is the generated HTML that the web server sends back to your browser as an HTTP response.

What happens when you use serverless PHP

Now that we've gotten a basic idea of how a PHP application works, we can look at what happens to it when you use serverless PHP. First, serverless computing is event-driven. Your serverless PHP interpreter awaits for an event, and this triggers the PHP code to run.

In a way, it’s similar to how things work with a web server. Your web server receives an HTTP request (an event) and this event would cause the web server to tell the PHP interpreter to process your code. This is the primary reason serverless computing works so well with PHP.

So what's different about serverless PHP then? The big change is that, not only do you not have a server with serverless PHP, you don't have a web server anymore either. Instead of a web server, you use an API gateway which is a special service offered by the cloud provider. Let's look at what that looks like in more detail.

The life of a serverless PHP request

Below is a diagram showing what happens when you make a request to a serverless PHP application. As you can see, it looks very similar to what we had before.

The browser sends the HTTP request to the API gateway. The gateway receives the HTTP request, converts it to an event, and forwards it to the serverless PHP application. It reads, parses, and executes the requested PHP file and returns the result to the API gateway. The gateway generates the HTTP response and sends it back to the browser.

Of note is the serverless PHP application. It has two parts: the PHP runtime and your PHP code.

The PHP runtime contains the PHP interpreter. But it also has code to process the event sent by the API gateway and return it the response from the interpreter. Your PHP application code is the same PHP code you’d deploy to a regular server.

These two parts get packaged together as a function (this is where the name Function as a Service comes from) when you deploy your serverless PHP application to the cloud provider. This function is what the API gateway sends an event to whenever it receives a request.

What's the advantage of this?

Now that we've seen how serverless PHP application works, you might wonder, "Why would I want to use this instead of my trusty Linux server?"

Near infinite scaling

Once you've deployed a new version of your serverless PHP application, the cloud provider can create as many copies of it as necessary. It can also create these copies almost instantly. This allows your PHP application to handle large spikes of traffic without breaking a sweat. (For example, Ymir can help your WooCommerce site scale to handle hundreds of customers instantly.)

With a normal server setup, you need to have the server capacity already provisioned and ready to go. Otherwise, you need to have a horizontally scaling setup ready to handle these traffic spikes. But these types of setup take a few minutes to scale which can make the application unavailable until then.

No need to manage servers

This is a good way to bring up the next advantage of using serverless. You don't have a server to manage anymore. If you've ever had to manage servers, you know the responsibilities that come with managing one. (Being on call when it goes down, handling updates, keeping it secure, etc.)

With serverless, all that you have to do is deploy your PHP code to your serverless platform and you're good to go! This gives you a peace of mind that's hard to put a price on. But once you've experienced it, it's hard to go back. (It's why I built Ymir.)

Pay per use

The server doesn't just change how we host our code. It's also changes how we pay for hosting it. Before you'd pay for a server that had to stay on at all times. This was true regardless that you had a droplet on DigitalOcean or code deployed to a Heroku dyno.

With serverless, you only pay when your code runs. (For example, AWS Lambda charges you by the millisecond!) In a lot of cases, this offers significant cost saving. One case study shows how external.io went from paying $50/month on platform.sh to ~$17/month on AWS.

The tradeoffs

If serverless sounds too good to be true, that's because it generally is! That said, it's not the ideal solution in all situations. Here are some the tradeoffs you have to consider if you're looking to use serverless,

Harder to predict costs

When you pay for a server, you know it'll be $X/month. It's simple and easy to plan for. If you need a larger server, you know you'll go from paying $X/month to $Y/month.

With serverless that whole cost calculation is more complicated, you have to think, "How many requests do I get? How long do they last on average?" So while pay per use pricing model offers great cost saving potential, you might prefer the predictability of regular hosting costs. Even if you might pay 2-3 times more for it.

Not cheaper than a low-end VPS

If you're running your PHP application on a $5/month VPS, serverless won't offer any cost saving. In general, serverless PHP becomes cost competitive when you're paying $25/month for hosting. $25/month isn't that expensive for hosting, but a lot of us just host projects on smaller VPCs.

That said, it's also disingenuous to just compare server costs like this. You should also consider how much it costs to manage that server. Either it costs your time or you have to pay someone to do it.

Generally limited to AWS

While serverless computing exists on all the major cloud providers, your serverless architecture is very provider dependent. An API gateway on Microsoft Azure won't work the same as the one on Google Cloud.

The reality is that, at this time, most of the energy around serverless PHP is focused on one provider: AWS. Not everyone can use AWS for a wide range of reasons. That said, if you can't use AWS, you're going to have a harder time finding resources or services (Laravel Vapor and Ymir are both AWS only) to create a serverless PHP application.

A great alternative to servers

The point of this article wasn't necessarily to show you you shouldn't host a PHP application on a server. Hosting a PHP application on a server still has a bright future ahead of it. It's sometimes more cost effective to do so. You can choose which provider you want to use, and there are countless resources and tools to help you manage one.

But if you're using an expensive hosting provider or a platform as a service or some complex horizontally scaling setup, serverless might be the thing you're waiting for. It's easier to manage and deploy to while often costing less.

And that's something to be excited about.

Top comments (7)

Collapse
 
andreidascalu profile image
Andrei Dascalu

Wrong. The only cloud provider that natively supports PHP as of now is Google.
AWS sort of supports a workaround where you can package Docker containers to be triggered as functions.
This works but it's not as fast as a native sercerless runtime as provided by GCP.

Collapse
 
lito profile image
Lito

AWS support PHP natively: aws.amazon.com/blogs/compute/intro...

Also, support PHP as functions as containers: aws.amazon.com/blogs/compute/build...

Collapse
 
andreidascalu profile image
Andrei Dascalu

I guess it depends on what do you mean by natively. You need a custom runtime definition to make PHP work with Lambda. It's been the case for a while - in fact ever since AWS introduced custom runtimes (but you need to provide your own_.

That's not the case in GCP. In GCP, PHP is provided as a first-citizen runtime (PHP 7.4 at the moment).

Basically, if you go to their respective consoles, is PHP listed? If no, then it's not "natively supported".

Collapse
 
carlalexander profile image
Carl Alexander

The point I was making with AWS is how much information is out there. GCP might have PHP as a first class citizen. It's still not something you'll find a lot of information about. There's a lot more information out there about using a custom runtime with Lambda than using native PHP with GCP.

Collapse
 
andreidascalu profile image
Andrei Dascalu

That's also kindof the point. Do you need that much documentation for Lambda? Should you? The whole selling point of sercerless functions is that you have a function and it's executed on a trigger.
The whole idea that you need several pages of documentation to setup something that by definition doesn't need setup (particularly, say for a "hello world") is a but ridiculous.
You don't need pages of documentation to run Node code, do you? In the case of a Python application you might given the vendoring particularities but that's about it.

Collapse
 
christianyates profile image
chrisyates

As you point out, when comparing costs it's important to look at both the raw costs of infrastructure (as you do here with AWS), the cost of your own time, and the added features you don't get with AWS. Yes, Platform.sh cost $50 for this project … but also came with built-in CI/CD, instant cloning to three dev environments, automated TLS, backups, etc., all without messing with IAM rules. (I work for Platform.sh)

Collapse
 
carlalexander profile image
Carl Alexander

Agreed, I think it's always important to factor in those types of costs as well!