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!
The more I watch your videos, the more I want to go the PHP route for web development; as I’m a beginner just about finished up with HTML CSS moving to JS
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.
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!)
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.
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!
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.
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
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.
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.
On multiple lambda functions or did you created one for each Job? I'm very interested your idea
The more I watch your videos, the more I want to go the PHP route for web development; as I’m a beginner just about finished up with HTML CSS moving to JS
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.
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.
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!
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.
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
LOVE THIS VIDEO! THANKS!
Obrigado pelo conteúdo.
De nada!
❤
Am I the only one thinking PHP was already serverless, just upload your code to any hosting via ftp
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"
it's not needed....