Last year Tylor Otwell, the creator of the Laravel PHP framework, made an announcement about the new deployment platform named Laravel Vapor.
It was a huge game-changer for the whole PHP/Laravel ecosystem. It allows developers to set up on-demand auto-scaling with zero server maintenance without having any in-depth SysAdmin or DevOps knowledge.
Laravel Vapor allows people to focus on developing their Laravel applications and not worry about the underlying server infrastructure. Things like server maintenance, server monitoring, security patching, manual scaling during busy periods, manual disaster recovery and etc. are things of the past thanks to Vapor.
With all that in mind, it almost sounds like it's too good to be true right? I decided to check this myself and share some of the issues that I came across along with the things that really impressed me!
What is Serverless?
According to the Serverless Stack website, Serverless computing (or serverless for short), is an execution model where the cloud provider (AWS, Azure, or Google Cloud) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code. The code is typically run inside stateless containers that can be triggered by a variety of events including http requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), etc. The code that is sent to the cloud provider for execution is usually in the form of a function.
What is Laravel Vapor?
Laravel Vapor is an auto-scaling, serverless deployment platform for Laravel.
Vapor abstracts the complexity of managing Laravel applications, as well as interfacing those applications with SQS queues, databases, Redis clusters, networks, CDN, and more.
In short, you can think of Vapor as Laravel Forge for serverless technology.
Getting Started with Laravel Vapor
To get started with Vapor, all you need is Vapor account, you can create one through here:
View Website
View Website
View Website
https://vapor.laravel.com/
You also need an AWS account, and you have to add your AWS credentials to your Vapor account.
After you have this configured you need to install the vapor-cli package along with the vapor-core package:
composer require laravel/vapor-cliAfter that login to your Vapor account:
./vendor/bin/vapor loginInstall the vapor-core package:
composer require laravel/vapor-coreFinally initialize your Vapor project:
./vendor/bin/vapor initYour Vapor configuration file is called vapor.yml, and there you can specify different settings like your Database, PHP version, different environments and etc.
Once you've created a database via your Vapor control panel, and added it to your vapor.yml, you can proceed with a deployment with the following command:
vapor deploy stagingDepending on the size of your project, it would not be long before you have your project deployed and up and running!
A couple of things that you need to keep in mind are:
- Make sure that you have less than 300 static assets in your public folder otherwise the deployment will fail
- If your vendor directory is larger than 50MB make sure to set "separate-vendor: true" in your vapor.yml as described here: https://blog.laravel.com/vapor-reusable-vendors
My Vapor Journey
After playing with Vapor for some time now, I think that the main pros and cons are:
Pros and things that I was impressed with:
1. Fairly easy to learn - As everything is done in the background automatically for you, it is really easy and intuitive for a Laravel Developer to start using Vapor. Compared to some other technologies that allow you to scale on demand like Kubernetes for example, where you have a much more steep learning curve.
2. Brilliant documentation - The documentation is top-notch! You can easily find all of the information that you need.
3. Support - I was having some problems with my deployment (I'll talk about this a bit further in this post), so I decided to get in touch with Vapor's support. Within 2 minutes I had a reply and some handy suggestions on what could be wrong.
4. Low infrastructure maintenance - You configure your infrastructure once and let it autoscale depending on your traffic
5. Scaling - Vapor is great of critical applications handling millions of requests and unexpected bursts in traffic
6. Worry-free Deployments and Zero-downtime deployments and rollbacks - You get a nice dashboard, where you can see your deployments and even trigger new redeployments. It is incredibly easy to deploy and roll back in case that you need to, you can even easily integrate it with your CI:
Cons and problems that I encountered
Main downside that I've noticed is the AWS cost and the troubleshooting.
1. Cost - I'm not referring to the Vapor cost, it is just a small monthly fee and it is definitely worth it, but it is the AWS bill that you need to keep an eye on. There are many things that could cost you a fortune if you are not careful, here are a few things worth mentioning:
- Services that are possibly not needed: There are some services that Vapor provisions by default like SQS for queues, SES for mails and CloudFront for static files. If you do not need those you can disable them to lower your monthly AWS bill. To do that add the following to your vapor.yml file:
queues: false
mail: false
scheduler: false- As you pay per request, you need to make sure that you have some kind of DDoS protection, otherwise, a small DDoS attack could cost you a fortune and have a real negative impact on your business or project. One way to do that is to have a mechanism in place to reduce the number of concurrent Lambda requests.
- Aurora Serverless - If you want to go truly serverless, you need a serverless database right? But this also comes at a cost and you need to be careful. So if you decide to use AWS Aurora as your database rather than a standard RDS, you need to keep in mind that you are going to be charged per I/O so you need to carefully calculate how many DB queries your application makes and calculate the cost in order to prevent any nasty surprises for your AWS bill at the end of the month. Another thing that you need with Aurora is a NAT gateway, which also would cost you a nice extra $32 month.
- Monitoring: of course, you can do this with CloudWatch but again you need to be careful with the costs.
There are some other things but I feel like that this is enough about the cost.
2. Troubleshooting: in case something is wrong with your deployment, you would like to check your logs right? Vapor allows you to do that, but it does not always work as expected, sometimes the logs take ages to load, and if they do load the formatting is not perfect. So unless you have access to the underlying AWS account in order to check the logs there, you might not be able to really troubleshoot your deployment. I noticed that I was getting a 502 in my web console:
For example, I deployed an existing project, the deployment went through all fine, no errors or anything, but then when visiting the site in my browser I was getting a 504 error:
This, combined with the fact that my logs were not loading in Vapor made the troubleshooting nearly impossible and I had to shoot in the dark.
There was obviously something wrong with my deployment as even my commands were timing out as well.
With some help from support, I was able to get my project up and running! But it was not as straight forward as I expected it to be and I definitely needed access to the AWS console as well.
Should you migrate to Laravel Vapor?
It is fascinating what the Laravel team has managed to build, a single tool that allows you to deploy your Laravel project and not have to worry about your infrastructure is simply amazing.
But I would say that it's not for everyone and not for every project. Is your application absolutely critical getting millions of hits and you can't afford any downtime? Does your server management make you anxious? Do you think that Kubernetes is too complicated and hard to manage? If the answer to all of those is yes, then I would say that you should definitely try Vapor!
But for my personal needs, I would say that I would prefer to stick with DigitalOcean and standard Droplets for smaller projects, and DigitalOcean managed Kubernetes for larger projects. With the DigitalOcean Managed Kubernetes (DOKS for short) you still can autoscale, rollback and etc. even though this requires some overhead during the initial setup, it would definitely be cheaper in the long run and you would actually know how much you would be paying compared to AWS and their unclear pricing policy.
Conclusion
The idea behind Laravel Vapor is brilliant. The Laravel team have done a brilliant job with the integration with AWS. But you should carefully consider all of the pros and cons and your individual needs.
But as a person with SysAdmin and DevOps background, my personal opinion, based on my own needs and experience, is that DigitalOcean and their managed services like the Managed Kubernetes and the Managed Databases, is the way to go!
Comments (0)