What is Serverless?

Before we get ourselves too confused with definitions, let us address the elephant in the room. Yes, Serverless infrastructure uses servers.

Serverless just means that you don’t have to worry about software updates, security patches, monitoring, provisioning capacity, load balancing, uptime, and all other maintenance.

So how does serverless differ from what we’ve been doing for the majority of our careers? The easiest way to explain things is for me to compare a “traditional” set-up against a serverless set-up for a basic web application.

Let’s imagine we’ve got a basic Laravel application, and let’s imagine that it’s a chatroom. The features we have are register, login, logout, post message and perhaps some email notifications when you are tagged.

Traditional

With your typical, old school web application, you’d set-up LAMP or LEMP on a server. That server may be a dedicated server or a VPS. If you’re using shared hosting, this will all be set-up for you. But that’s the minority of cases when it comes to Laravel applications.

For this example, let’s imagine you have some sort of VPS from DigitalOcean or a dedicated server.

So as I said, the traditional set-up would be having it all on one server.

• Linux
• Apache
• MySQL
• PHP

So that’s how the traditional set-up looks. It’s the set-up that a lot of us came up using, and may still use.

This isn’t good though because we have all of our eggs in one basket. If that dedicated server has some software or hardware issue, we could lose data and be offline for hours. Imagine if we had to restore a 1TB backup to our database because our database was unrecoverable from an issue? It would be a headache. What about if your MySQL instance required more CPU or RAM, you might have to take everything offline to perform the upgrade. And that’s one of the reasons why this approach isn’t as common anymore.

Broken-out Traditional

With the ‘Broken out Traditional’ approach, we split our application up into pieces. Instead of having the database and the webserver together, we now have 2 servers. 1 is responsible for MySQL and the other is responsible for the webserver. This is better because it means we can control each server separately. We can switch out the MySQL server parameters easily in the event of maintenance/server upgrades without taking the web server offline.

So this is certainly a step up from traditional. There are obviously many other combinations where you can set-up your infrastructure in a custom way to add redundancy to your application, stepping up each time, but I’m not going to dive into them because we’ll be here for weeks. The downside of this is that you increase complexity/management as you scale-out. As the late Biggie Smalls once said, Mo Servers Mo Problems.

Serverless

We will jump right past the infinite other configurations and onto a serverless set-up (done with Laravel Vapor) because that’s what we’re going to be talking about in the course.

With serverless, we still use servers but you don’t manage them. Instead, we utilize services like:

• Lambda (HTTP Layer / Commands / Queue workers)
• RDS (Highly available database)
• SQS (Queue)
• SES (Email)
• ElastiCache / DynamoDB (Cache)
• Cloudfront (Content Delivery Network)
• and more.

These are the AWS services that Vapor utilizes. Because they are services, we can provision them with certain settings, without having to worry about underlying server tweaks, updates, and management. Instead, a team of experts keeps the services online for us. There are thousands of servers running these services but, as far as we’re concerned, we’re serverless because we don’t care about the servers.

So that’s the difference. By choosing serverless deployment, we choose to focus on our applications and not on infrastructure. We choose to pay $39 each month for Laravel Vapor instead of $1,000 (or more) each month for someone to manage our servers.

Some people like DevOps. If that’s you, serverless might not be for you. But for those of us who want to spend our time writing code and making our applications better, serverless is the best thing since sliced bread.

Sure, we still have to manage services occasionally, but that’s rare and easy. We stay at a high level when we use these services, and never have to dive into server problems.

We choose sleep instead of 2 AM wake-up calls from uptime monitoring solutions telling us our website is down. We choose a managed database service where database storage is decoupled from the main computation. And all the other serverless goodies.

Serverless Laravel isn’t a trend, it’s the logical next step. Less time on infrastructure and more time building our applications.