Serverless PHP is pretty good
Vložit
- čas přidán 23. 07. 2024
- The serverless architecture and platforms like AWS Lambda have revolutionized the ease of hosting and maintaining web applications, but most lack support for PHP.
In this video, I use a package called Bref, which helps scaffold out configurations for the serverless framework and provides a custom runtime in order to deploy PHP applications to AWS Lambda instances.
The result? Zero-downtime deployments with a single command line and the ability to handle massive amounts of requests with ease. All with virtually zero changes in your actual application source code!
Watch the full video to see how PHP on Lambda compares against the same application hosted on a VPS with a traditional LAMP stack.
Interested in learning how to build real-world practical apps with Laravel and PHP? Preorder my latest course at selfmadesaas.com for 25% off until launch!
Some helpful links:
bref.sh
serverless.com
- 0:00 Intro
- 0:40 Adding Bref
- 2:27 Serverless Config
- 3:39 Deploying Our App
- 4:33 Fixing The Stateless Problem
- 7:11 Running CLI Commands
- 8:47 Comparing Lambda vs VPS
- 10:44 What's Next?
Send me new video ideas and vote on what's coming next: suggest.gg/aschmelyun
Follow me on Twitter! / aschmelyun
Join my newsletter, where I send out new information about twice a month in the PHP, JavaScript, and Docker realms: aschmelyun.substack.com - Věda a technologie
Great video!! for anyone out there: Be mindful of the Lamda serverless cost and the egress costs, they are billed separately
100%, despite the free tier you're still using AWS Gateway and that's billed separately. It can be easy to go over the request limit (or have yourself open to bad actors that slam your website). Usage alerts are a must!
We have migrated all sqs job workers from EC2 to Lambda and we are very happy with the result.
LOVE THIS VIDEO! THANKS!
Thanks for the video. A very interesting one and useful for most of my needs.
Just a question, maybe a stupid one, since I have used AWS services just to give a try with Laravel Vapor. Suppose I want to connect to an external database (MySQl, Mariadb etc.) that has IP policy in place how do I know the IP address (maybe a pool of IP addresses) to estabilisha a connection outside AWS lambda?
That is an interesting question. I suppose you'd have to either deploy first without that db connection to get the IP address, or maybe AWS (or the Serverless framework) has a way of assigning a set IP before you actually make the deployment that you can configure with your db provider.
Sorry that thumb-up button is toggle. I would keep clicking if it is incremental. One question hits me. what should I put for APP_URL? I can get url after deploy.
great video! what about an application that uses websockets? how do you host those?
You can use the same method if you want! AWS Gateway allows for WS connections, and the Bref package lets you accept them in your application. There's a whole documentation section for it on their site (although it's a little sparse) bref.sh/docs/use-cases/websockets
Cool video and interesting to see this work that easily. But I am wary of the unpredictable nature of the costs though. Could you say a bit more about this?
It's probably the #1 thing I've seen mentioned in the comments about running PHP (or any language) on Lambda. The best advice I can give is to ensure you have billing notifications set up and be vigilant about monitoring traffic.
If you can, implement something like Cloudflare as an intermediary to prevent high traffic spikes from DDOS and implement cached responses from specific routes.
Obrigado pelo conteúdo.
De nada!
the way you said cli hurts my heart
see-el-eye, is that better? :D
I would love to see a video on how laravel hosts its websites with all the CD CI tools setup 😊
Not with bref. Laravel has it's own serverless offering. It's called Laravel Vapor and it is built for and runs on AWS.
Correct! It's similar in fashion though, they use a custom runtime for Lambda that executes the PHP code. As far as I know it's all proprietary though, so finding out how it works for sure would be pretty tough!
soooo the bottleneck will still remain "the database connection" since, if my understanding of serverless is correct, let AWS decide when to spawn the server and where automatically but the DB still remain on a fixed point
but i assume that if you have a presentation website with data that doesn't change that much or use SQLite you will not have a problem
at least for Laravel apps I don't think this is going to get lots of usage
also from what I remember doesn't Serveless does auto caching on the execution files while on a traditional stack (i prefer to use nginx instead of Apache) you need to configure OPcache extension on PHP side, and have caching set to Redis for some speed improvement? I don't know if these facts might affect benchmarks.
Costs might also be a big factor to go the traditional way. If your client doesn't care about this part them yolo.
Valid comments all around. You're right, the db connection is still the weak spot. The cool thing is that you can actually serve a read-only sqlite database with this setup through the Lambda instance. So if you're displaying a mostly-static site you can really ramp up the concurrency and slash response times.
This is likely overkill for most pet projects, but I do have a few microservices running on this stack that cost practically nothing. Might be easier to build them in Node or Python but I'm just comfortable with PHP (and it's fun!)
@@aschmelyun i also make my bread money using PHP :D
and yes i do find lamba more at home using JS, but that's mostly because of the JS ecosystem
❤
I'd actually feel that this benchmark is just a half of the coin. I would like to see the total duration (as a median value) in ms. I say this because I discovered that Laravel paired with modern server such as Swoole outperforms your VPS example by a ten fold.
This is of course isolating away from all the DX that comes with the "server less" deployments. Coolify is worth a look.
Am I the only one thinking PHP was already serverless, just upload your code to any hosting via ftp
it's not needed....
This term ‘serverless’ is really stupid because.. a server is still needed somewhere or a computer hosting the necessary packages, language, required software and hardware..
The language we build around hosting from this to the cloud .. really make zero sense.
Oh agreed, what's the saying? "The cloud is just someone else's computer"