Project Description
created: July 25, 2022
Dear Fellow PHP Developer
I want you to help me help the PHP Community.
I am asking fifteen of you to fund my efforts between for the seven month period August and February to research, produce, and publish free and open source software, sample code repos, short-and-snappy videos, and blog posts about PHP serverless.
By "PHP serverless", I mean:
⦿ using Lambda with PHP
⦿ what basic CI/CD process to use? Because "deploying" to serverless is much different than deploying to a cloud server
⦿ how to manage a shit-ton of repos?
By "PHP", I mean small pieces of PHP code. When Amazon says that S3 can initiate a Lambda invocation, how exactly do I do this with our beloved PHP from soup-to-nuts? The first line of the official Lambda-with-S3 tutorial is bullshit for PHP (https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html): In this tutorial, you use the console to create a Lambda function and configure a trigger for Amazon Simple Storage Service (Amazon S3). The trigger invokes your function every time that you add an object to your Amazon S3 bucket". Well, PHP devs cannot use the console. To be precise, PHP does not work out-of-the-box in the Lambda console because PHP is not an option in the runtime dropdown. However, by performing some gymnastics, we can get PHP to work in the Lambda console.
By "PHP", I absolutely do not mean monolithic web apps. If you want to mount your Laravel Framework based app onto Lambda, then sign up for Vapor. I think it works for generic PHP apps, but I am not sure. The PHP Community does not need a sponsored FOSS project about mounting PHP apps onto Lambda.
I know that I am going to sound like an arrogant ass, but a huge reason to help me is because no one else is doing this for the PHP Community.
It is hard to believe that there is no ongoing free and open source project about PHP in the serverless sphere. Except, of course, Bref. There are one-off blog posts. There are videos and conference recordings about using Bref. But beyond that, I have found nothing. Maybe someone will reply with a link to projects that I could not find.
There is a big gaping hole that someone should step into. That someone is me.
I have enjoyed PHP as my #1 language for over two decades. I've been going to Toronto area PHP meet-ups for over a decade, and now am lead organizer of three local groups because two leads handed me the keys during the lockdowns. I am independent. There is no employer to say "hey, work a couple of days a week on this". I have no affiliations or associations to keep happy. I can take a wide survey of the PHP serverless landscape, or deep dive into a narrow rabbit hole, whatever the situation warrants. My only fealty is to PHP.
Amazon supports PHP for its other services by way of maintaining its first-party PHP SDK. The first commit was in 2010 first commit was in 2010. There is a home page for the PHP SDK. There are first-party docs on its "docs" subdomain.
So Amazon supports PHP for Lambda. Right? Wrong...
PHP does not work out-of-the-box with Lambda. There is no "PHP" selection in the console's runtime drop-down. Amazon's "docs" subdomain has no info specific to PHP, but has info specific to native languages. Amazon provides no PHP software to manage Lambda interacting with other Amazon services.
Amazon made an active decision to not support PHP for its Lambda compute service. I have not come across any explanation from Amazon, and at this point I am not sure that I care.
In my experience, the one-off blog posts and GitHub repos that Amazon has published, exhorting us to cook up our own PHP runtimes, are infuriating. Despite the fact that one of the blog posts is very good, and one of the repos, which mysteriously does not have a corresponding post in Amazon's Compute Blog, is absolutely brilliant although I counsel not to cook up PHP runtimes as outlined, these are not documentation.
I think Lambda is a powerful, and profound compute service, especially when combined with Amazon's API Gateway. However, it is damn complicated.
Interestingly, and perhaps, ironically, one generic PHP runtime will not satisfy all use cases. The PHP runtime has to suit the use case. Bref's PHP runtimes give you a sense of this.
The Bref project is fantastic. It is the only ongoing, going-concern, free and open source project devoted to using Lambda with PHP. They maintain PHP runtimes, they maintain docs explaining how to use their runtimes, they maintain PHP FOSS to manage Lambda interactions with other Amazon services, and they maintain a plugin to use the Serverless Framework as a way to deploy. We'd be screwed without Bref's off-the-shelf implementations, because there would be nothing. I am sure that I persevered with Lambda because of Bref.
There is no one-size-fits-all solution for using Lambda. You have to know your use case. One of my use cases is getting a couple of hundred lines of PHP on Lambda to process incoming emails from Twilio. I want a clean PHP only solution to get the code onto Lambda. I may or may not care about using CloudFormation. I want to optimize my runtime to run as fast as possible at the lowest possible cost.
I have found no other project that offers PHP-only software for deploying PHP code to Lambda. I have found no PHP project that gets deep into how to structure optimal runtimes -- which is important in lowering costs. I have found no PHP project that gets into CI/CD for PHP code that will deploy to serverless platforms.
The serverless architecture market is estimated to be $13 billion (usd) this year (https://www.marketsandmarkets.com/Market-Reports/serverless-architecture-market-64917099.html). Even as a minor part of this market, PHP is in the millions -- probably tens of millions. Yet, when it comes to using PHP with serverless platforms, there is just the one ongoing FOSS project, and my embryonic FOSS project. The cloud server market has peaked, the growth area is the serverless architecture.
I want to get a bunch of FOSS materials published. Just to catch up, so to speak, on what should be available to PHP devs. Lambda is the leading compute service. AWS has the leading serverless platform. Lambda is a complicated technology. Help me go deep down this rabbit hole with a shameless PHP point-of-view, and publish FOSS materials every scrap of knowledge that I find -- with an emphasis on publishing repos.
I think it will take me seven months to do these materials. If it takes less time, then we will conclude this phase of sponsorship early. However, I took into account that I would rather be thorough than fast. On the other hand, although I did not draw up a Gannt or project, my sense is that it will take seven months. If it will be longer, than we will still conclude this "phase one" sponsorship, and I will draw up a detailed plan for finishing. The only reason I can think of for elongating is scope expansion, which is likely.
By late fall, I expect that my three podcast shows will be in full swing. Right now, I am thinking that I would rather tie in project sponsorship with my podcasts. I have no idea how I will want to do that, so I will see how I feel in the late fall.
On top of Lambda+PHP, the CI/CD process for PHP serverless, and how to manage a shit-ton of repos with a handful of PHP code that deploys to serverless, I want to go deep into Digital Ocean's new serverless offering that they call "Functions". I think that all of our favourite cloud server vendors will ultimately offer serverless, and so good to see D.O. leading the way. PHP works out-of-the-box, but their sample code uses the function structure, which I find highly constraining. Reading the docs, I get a strong sense that it is important to understand Lambda, and then use Lambda as a baseline to understand new serverless entrants. This would be done within the seven months.
After the seven months, it should be just a matter of doing updates. The software that I envision publishing is straight forward and modestly featured by design, so I do not foresee doing major features after. Keeping up with AWS changes, but not complicating my software with new features. For full fledged features for deployment, there is always going to be the Serverless Framework -- so I'll be making sure to update my PHP plugin's skeleton repo (which I have not done yet).
The topic of my Bob Bloom Show and Bob Bloom Interviews podcasts will be mainly PHP serverless. Serverless is an incredible technology, and I will cover it on an going basis, along with my PHP Serverless Project.
It really does not seem like there should be so much material to do that it would take an intense, sponsored, effort to achieve.
There is a lot of info about Lambda, so what's the big deal? Lambda is not described in PHP. Repos that I took for granted would just magically be on GitHub were not. I did my own sample "Hello World" repo with Bref (https://github.com/lasallesoftware-serverless/sample-lambda-hello-world), which, incredibly, may be the first one published. It's a big time saver having the code in front of you. It's another thing to conjure up the code yourself.
Also, it takes time to make videos. Even videos where I do not give a shit about monetization, make them three minutes tops, stick to a single topic per video, and make it actionable. I will get more proficient with videos, but as I get more proficient I want to make a lot more of them. BTW, I will probably end up doing PHP code to upload videos to YouTube using Lambda, as I already have video set up for my project website, and I'll probably profile this repo and code for the project as a live case study. Another case study will be, probably, using DO Functions to process inbound Twilio emails.
I seek 15 intrepid PHP devs to sponsor $250/month for 7 months via my GitHub Sponsors. It's just a month-to-month thing, but please give it two months to start. I will probably not be publishing a lot in the first month, as I continue deep diving into PHP runtimes.
For more info, there is this project description, and this website. My August First podcast is about sponsorship.
I am asking fifteen of you to fund my efforts between for the seven month period August and February to research, produce, and publish free and open source software, sample code repos, short-and-snappy videos, and blog posts about PHP serverless.
By "PHP serverless", I mean:
⦿ using Lambda with PHP
⦿ what basic CI/CD process to use? Because "deploying" to serverless is much different than deploying to a cloud server
⦿ how to manage a shit-ton of repos?
By "PHP", I mean small pieces of PHP code. When Amazon says that S3 can initiate a Lambda invocation, how exactly do I do this with our beloved PHP from soup-to-nuts? The first line of the official Lambda-with-S3 tutorial is bullshit for PHP (https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html): In this tutorial, you use the console to create a Lambda function and configure a trigger for Amazon Simple Storage Service (Amazon S3). The trigger invokes your function every time that you add an object to your Amazon S3 bucket". Well, PHP devs cannot use the console. To be precise, PHP does not work out-of-the-box in the Lambda console because PHP is not an option in the runtime dropdown. However, by performing some gymnastics, we can get PHP to work in the Lambda console.
By "PHP", I absolutely do not mean monolithic web apps. If you want to mount your Laravel Framework based app onto Lambda, then sign up for Vapor. I think it works for generic PHP apps, but I am not sure. The PHP Community does not need a sponsored FOSS project about mounting PHP apps onto Lambda.
I know that I am going to sound like an arrogant ass, but a huge reason to help me is because no one else is doing this for the PHP Community.
It is hard to believe that there is no ongoing free and open source project about PHP in the serverless sphere. Except, of course, Bref. There are one-off blog posts. There are videos and conference recordings about using Bref. But beyond that, I have found nothing. Maybe someone will reply with a link to projects that I could not find.
There is a big gaping hole that someone should step into. That someone is me.
I have enjoyed PHP as my #1 language for over two decades. I've been going to Toronto area PHP meet-ups for over a decade, and now am lead organizer of three local groups because two leads handed me the keys during the lockdowns. I am independent. There is no employer to say "hey, work a couple of days a week on this". I have no affiliations or associations to keep happy. I can take a wide survey of the PHP serverless landscape, or deep dive into a narrow rabbit hole, whatever the situation warrants. My only fealty is to PHP.
Amazon supports PHP for its other services by way of maintaining its first-party PHP SDK. The first commit was in 2010 first commit was in 2010. There is a home page for the PHP SDK. There are first-party docs on its "docs" subdomain.
So Amazon supports PHP for Lambda. Right? Wrong...
PHP does not work out-of-the-box with Lambda. There is no "PHP" selection in the console's runtime drop-down. Amazon's "docs" subdomain has no info specific to PHP, but has info specific to native languages. Amazon provides no PHP software to manage Lambda interacting with other Amazon services.
Amazon made an active decision to not support PHP for its Lambda compute service. I have not come across any explanation from Amazon, and at this point I am not sure that I care.
In my experience, the one-off blog posts and GitHub repos that Amazon has published, exhorting us to cook up our own PHP runtimes, are infuriating. Despite the fact that one of the blog posts is very good, and one of the repos, which mysteriously does not have a corresponding post in Amazon's Compute Blog, is absolutely brilliant although I counsel not to cook up PHP runtimes as outlined, these are not documentation.
I think Lambda is a powerful, and profound compute service, especially when combined with Amazon's API Gateway. However, it is damn complicated.
Interestingly, and perhaps, ironically, one generic PHP runtime will not satisfy all use cases. The PHP runtime has to suit the use case. Bref's PHP runtimes give you a sense of this.
The Bref project is fantastic. It is the only ongoing, going-concern, free and open source project devoted to using Lambda with PHP. They maintain PHP runtimes, they maintain docs explaining how to use their runtimes, they maintain PHP FOSS to manage Lambda interactions with other Amazon services, and they maintain a plugin to use the Serverless Framework as a way to deploy. We'd be screwed without Bref's off-the-shelf implementations, because there would be nothing. I am sure that I persevered with Lambda because of Bref.
There is no one-size-fits-all solution for using Lambda. You have to know your use case. One of my use cases is getting a couple of hundred lines of PHP on Lambda to process incoming emails from Twilio. I want a clean PHP only solution to get the code onto Lambda. I may or may not care about using CloudFormation. I want to optimize my runtime to run as fast as possible at the lowest possible cost.
I have found no other project that offers PHP-only software for deploying PHP code to Lambda. I have found no PHP project that gets deep into how to structure optimal runtimes -- which is important in lowering costs. I have found no PHP project that gets into CI/CD for PHP code that will deploy to serverless platforms.
The serverless architecture market is estimated to be $13 billion (usd) this year (https://www.marketsandmarkets.com/Market-Reports/serverless-architecture-market-64917099.html). Even as a minor part of this market, PHP is in the millions -- probably tens of millions. Yet, when it comes to using PHP with serverless platforms, there is just the one ongoing FOSS project, and my embryonic FOSS project. The cloud server market has peaked, the growth area is the serverless architecture.
I want to get a bunch of FOSS materials published. Just to catch up, so to speak, on what should be available to PHP devs. Lambda is the leading compute service. AWS has the leading serverless platform. Lambda is a complicated technology. Help me go deep down this rabbit hole with a shameless PHP point-of-view, and publish FOSS materials every scrap of knowledge that I find -- with an emphasis on publishing repos.
I think it will take me seven months to do these materials. If it takes less time, then we will conclude this phase of sponsorship early. However, I took into account that I would rather be thorough than fast. On the other hand, although I did not draw up a Gannt or project, my sense is that it will take seven months. If it will be longer, than we will still conclude this "phase one" sponsorship, and I will draw up a detailed plan for finishing. The only reason I can think of for elongating is scope expansion, which is likely.
By late fall, I expect that my three podcast shows will be in full swing. Right now, I am thinking that I would rather tie in project sponsorship with my podcasts. I have no idea how I will want to do that, so I will see how I feel in the late fall.
On top of Lambda+PHP, the CI/CD process for PHP serverless, and how to manage a shit-ton of repos with a handful of PHP code that deploys to serverless, I want to go deep into Digital Ocean's new serverless offering that they call "Functions". I think that all of our favourite cloud server vendors will ultimately offer serverless, and so good to see D.O. leading the way. PHP works out-of-the-box, but their sample code uses the function structure, which I find highly constraining. Reading the docs, I get a strong sense that it is important to understand Lambda, and then use Lambda as a baseline to understand new serverless entrants. This would be done within the seven months.
After the seven months, it should be just a matter of doing updates. The software that I envision publishing is straight forward and modestly featured by design, so I do not foresee doing major features after. Keeping up with AWS changes, but not complicating my software with new features. For full fledged features for deployment, there is always going to be the Serverless Framework -- so I'll be making sure to update my PHP plugin's skeleton repo (which I have not done yet).
The topic of my Bob Bloom Show and Bob Bloom Interviews podcasts will be mainly PHP serverless. Serverless is an incredible technology, and I will cover it on an going basis, along with my PHP Serverless Project.
It really does not seem like there should be so much material to do that it would take an intense, sponsored, effort to achieve.
There is a lot of info about Lambda, so what's the big deal? Lambda is not described in PHP. Repos that I took for granted would just magically be on GitHub were not. I did my own sample "Hello World" repo with Bref (https://github.com/lasallesoftware-serverless/sample-lambda-hello-world), which, incredibly, may be the first one published. It's a big time saver having the code in front of you. It's another thing to conjure up the code yourself.
Also, it takes time to make videos. Even videos where I do not give a shit about monetization, make them three minutes tops, stick to a single topic per video, and make it actionable. I will get more proficient with videos, but as I get more proficient I want to make a lot more of them. BTW, I will probably end up doing PHP code to upload videos to YouTube using Lambda, as I already have video set up for my project website, and I'll probably profile this repo and code for the project as a live case study. Another case study will be, probably, using DO Functions to process inbound Twilio emails.
I seek 15 intrepid PHP devs to sponsor $250/month for 7 months via my GitHub Sponsors. It's just a month-to-month thing, but please give it two months to start. I will probably not be publishing a lot in the first month, as I continue deep diving into PHP runtimes.
For more info, there is this project description, and this website. My August First podcast is about sponsorship.
The Nutshell
I want to research, produce, and publish free and open source materials about using Lambda with PHP:
⦿ I want to publish repos, blog posts, and videos about PHP runtimes for Lambda, so that PHP devs can cook up their own runtimes
⦿ I want to publish repos, blog posts, and videos about PHP containers for Lambda, so that PHP devs can cook up their own PHP containers
⦿ I want to publish videos, to compliment with my existing "clone and go" repos, to on-board PHP devs to Bref
⦿ I want to publish stuff about how to set-up "micro" PHP repos that deploy to Lambda, probably using GitHub Actions
⦿ I want to publish stuff about how to manage a shit-ton of "micro" PHP repos that deploy to Lambda, probably using GitHub Actions
⦿ I want to create lightweight, PHP only, software for deploying "micro" PHP code to Lambda
There is no need to do a sponsored open source project focusing on mounting full blown, monolithic, PHP apps onto Lambda, because Laravel's commercial Vapor service has that covered.
The genesis of Lambda is as a compute service for small pieces of code that other Amazon services invoke. My main interest is executing PHP code as "stand-alone" features/processes.
By "micro" PHP, I mean developing small pieces of PHP code to execute on Lambda. Such as tiny little processes, targeted-scoped features, stand-alone forms, stand-alone form-handlers. I am not referring to "micro-services", with all that that implies. For the PHP Community, "micro" PHP is the Road Less Travelled.
I want to create a lightweight PHP plugin for the Serverless Framework, that will also be a base ("skeleton") for PHP devs to done one up for themselves.
Now that the Digital Ocean has released their new serverless offering, called "DigitalOcean Functions", I want to dig into it, as a possible streamlined alternative to using Lambda. The main thing that I want to produce for DO Functions are repos, with companion blog posts and videos.
Amazon Web Services does not directly support PHP for Lambda. Really! You may not believe me, and rightly so given AWS' terrific first-party direct PHP support for its other serveices. But, Lambda is the exception. I shit you not on this.
There is just one single ongoing, going-concern, free and open source software project devoted to providing what Amazon will not on Planet Earth: providing third-party PHP support for Lambda. This project is Bref. There is only so much a third party OSS project can cover. There is a shit-ton of shit that no one is doing. NO ONE.
I am looking for seven months of sponsorship only, to research, produce, and publish free and open source stuff, especially repos. I will be doing this project on an ongoing basis after the seven months, and I may, or may not, seek sponsorship. I am leaning on "not", funding my efforts with PHP serverless consulting gigs and my podcasts. The reason in the first place is because of my custom podcasting platform -- what a journey!!
My GitHub sponsors page is here.
⦿ I want to publish repos, blog posts, and videos about PHP runtimes for Lambda, so that PHP devs can cook up their own runtimes
⦿ I want to publish repos, blog posts, and videos about PHP containers for Lambda, so that PHP devs can cook up their own PHP containers
⦿ I want to publish videos, to compliment with my existing "clone and go" repos, to on-board PHP devs to Bref
⦿ I want to publish stuff about how to set-up "micro" PHP repos that deploy to Lambda, probably using GitHub Actions
⦿ I want to publish stuff about how to manage a shit-ton of "micro" PHP repos that deploy to Lambda, probably using GitHub Actions
⦿ I want to create lightweight, PHP only, software for deploying "micro" PHP code to Lambda
There is no need to do a sponsored open source project focusing on mounting full blown, monolithic, PHP apps onto Lambda, because Laravel's commercial Vapor service has that covered.
The genesis of Lambda is as a compute service for small pieces of code that other Amazon services invoke. My main interest is executing PHP code as "stand-alone" features/processes.
By "micro" PHP, I mean developing small pieces of PHP code to execute on Lambda. Such as tiny little processes, targeted-scoped features, stand-alone forms, stand-alone form-handlers. I am not referring to "micro-services", with all that that implies. For the PHP Community, "micro" PHP is the Road Less Travelled.
I want to create a lightweight PHP plugin for the Serverless Framework, that will also be a base ("skeleton") for PHP devs to done one up for themselves.
Now that the Digital Ocean has released their new serverless offering, called "DigitalOcean Functions", I want to dig into it, as a possible streamlined alternative to using Lambda. The main thing that I want to produce for DO Functions are repos, with companion blog posts and videos.
Amazon Web Services does not directly support PHP for Lambda. Really! You may not believe me, and rightly so given AWS' terrific first-party direct PHP support for its other serveices. But, Lambda is the exception. I shit you not on this.
There is just one single ongoing, going-concern, free and open source software project devoted to providing what Amazon will not on Planet Earth: providing third-party PHP support for Lambda. This project is Bref. There is only so much a third party OSS project can cover. There is a shit-ton of shit that no one is doing. NO ONE.
I am looking for seven months of sponsorship only, to research, produce, and publish free and open source stuff, especially repos. I will be doing this project on an ongoing basis after the seven months, and I may, or may not, seek sponsorship. I am leaning on "not", funding my efforts with PHP serverless consulting gigs and my podcasts. The reason in the first place is because of my custom podcasting platform -- what a journey!!
My GitHub sponsors page is here.
• Knowledge Gap
• On-Board Bref
• PHP Runtime Rabbit Hole
• PHP Containers
• Dev Process
• Manage Shit-Ton of Repos
• PHP-only Deployment
• Serverless FW PHP Plugin
• Digital Ocean Functions
• Two Project Phases
• FOSS Materials To Publish
• Lots Of Issues To Cover
• More Than Just Lambda
• PHP Runtimes and Layers
• Lambda Native Languages
• AWS Non-docs Docs
• The Bref Project
• Micro PHP
• Genesis Of Lambda
• PHP Ugly Podcast
• SWAG About Serverless $$
• How I Got Into Lambda
• My Project So Far
• Long Delay: Why
• My Podcast
• Sponsorship Description
Many PHP devs are going to come to the same conclusion as me about Lambda+PHP: DIY. And that will mean having a deep understanding of Lambda in purely PHP terms.
A big reason to DIY is costs. Execution times, cold start optimizing, using the proper amount of memory come into play. Knowing how to construct an optimal PHP runtime for your use case is very important. Just for PHP compilation, I want to create the leanest compiled PHP possible for my use case to speed up load times. I want to dig very very deep with this stuff to get a very intimate knowledge of it, in strictly PHP terms, and then share everything with the PHP Community as free and open source repos, blog posts, and videos.
Amazon is not keeping things about Lambda a secret. There are people who cover serverless and Lambda. The problem is that no one is doing this as an ongoing project specifically for PHP, except for Bref. Considering that the serverless architecture market is estimated at $13 billion (usd) this year "Serverless Architecture Market by Service Type, Global Forecast to 2025", it's pretty hard to believe that the PHP corner of serverless is so lightly covered. So, when it comes to learning the deep dark ways of Lambda for PHP, you are on your own. Bref -- well, the way I see it -- is an implementation of Lambda+PHP. Vapor is successful using Lambda, and does its own implementation. There is no one-size-fits-all way to use Lambda+PHP. You have to determine what is good for you. If you are like me and plan to use Lambda extensively, it is worth doing a DIY approach.
Some PHP devs will be happy to stick with Bref. Other PHP devs will get to a point where they will want to produce their own full PHP Lambda environments for production. Such as optimizing PHP code, and adapting the runtime to the use case. To do this, the need is not to reach for an off-the-shelf implementation (and, thankfully, Bref provides this), but to understand the Lambda technology itself.
Help me get this knowledge out to PHP devs with free and open source materials, because there is a big need, and NO ONE is doing it.
top
A big reason to DIY is costs. Execution times, cold start optimizing, using the proper amount of memory come into play. Knowing how to construct an optimal PHP runtime for your use case is very important. Just for PHP compilation, I want to create the leanest compiled PHP possible for my use case to speed up load times. I want to dig very very deep with this stuff to get a very intimate knowledge of it, in strictly PHP terms, and then share everything with the PHP Community as free and open source repos, blog posts, and videos.
Amazon is not keeping things about Lambda a secret. There are people who cover serverless and Lambda. The problem is that no one is doing this as an ongoing project specifically for PHP, except for Bref. Considering that the serverless architecture market is estimated at $13 billion (usd) this year "Serverless Architecture Market by Service Type, Global Forecast to 2025", it's pretty hard to believe that the PHP corner of serverless is so lightly covered. So, when it comes to learning the deep dark ways of Lambda for PHP, you are on your own. Bref -- well, the way I see it -- is an implementation of Lambda+PHP. Vapor is successful using Lambda, and does its own implementation. There is no one-size-fits-all way to use Lambda+PHP. You have to determine what is good for you. If you are like me and plan to use Lambda extensively, it is worth doing a DIY approach.
Some PHP devs will be happy to stick with Bref. Other PHP devs will get to a point where they will want to produce their own full PHP Lambda environments for production. Such as optimizing PHP code, and adapting the runtime to the use case. To do this, the need is not to reach for an off-the-shelf implementation (and, thankfully, Bref provides this), but to understand the Lambda technology itself.
Help me get this knowledge out to PHP devs with free and open source materials, because there is a big need, and NO ONE is doing it.
top
Just in case you get the impression that I do not like Bref (wrong), or that I want to replace it (wrong), I want to make it smoother for PHP Devs to use Bref. Bref is going to be just fine for many PHP devs.
When I discovered Bref, I had no idea what I was doing. I was still experiencing culture shock with Lambda, stuck as I was in the Ways Of The Cloud Server. I mis-interpreted Bref as a purely PHP stand-alone solution for Lambda -- WRONG. Incredibly, when I discovered Bref, I had not heard of the Serverless Framework. I had not a whit of the existence of CloudFormation. I was so frustrated by Amazon's non-docs docs, and then absolutely exasperated by Bref. I felt so desperate to get something working that I just went through some steps completely blind, hoping that I'd get a result. By the time I did get a result, I had some form of a "Hello World" repo, the sum effort of doing stuff I was clueless about, and adapting stuff To Make It Work. I ended up publishing a Bref+Serverless Framework PHP "Hello World" Lambda repo in GitHub. I wanted to see if a few things would work in Lambda, so I did "Hello World" repos for those. I refactored my repos into about a half-dozen "Clone and Go" repos. Hard to believe, but so far I think I am the first dev to publish such repos, based on my failure to find any -- not for lack of trying!
I have published videos about Bref, but I really need to do something better, and broader. There are videos about PHP+Bref, but, like the videos I already published, I want to focus on specific things, not do a point-by-point, step-by-step, thing. Refer to my repo and the Bref repo.
My intention is to compensate for something that AWS does not make possible: to construct and run a "Hello World" PHP Lambda function from the AWS console. We cannot do this from the Lambda console because the "runtime" dropdown in this console does not have a "PHP" option. I want to help PHP devs do their first "Hello World" PHP Lambda functions using Bref+Serverless Framework, so they can quickly get something working. One you get it working, you can then trace all the different things in the AWS console, which is a big help in understanding what the hell is going on. I want to publish a series of brief, snappy, videos to help PHP devs on-board with Bref. This is going to smooth on-boarding, reduce aggrevation, reduce frustration, save time, and motivate PHP devs to learn more.
Help me produce and publish these videos.
top
When I discovered Bref, I had no idea what I was doing. I was still experiencing culture shock with Lambda, stuck as I was in the Ways Of The Cloud Server. I mis-interpreted Bref as a purely PHP stand-alone solution for Lambda -- WRONG. Incredibly, when I discovered Bref, I had not heard of the Serverless Framework. I had not a whit of the existence of CloudFormation. I was so frustrated by Amazon's non-docs docs, and then absolutely exasperated by Bref. I felt so desperate to get something working that I just went through some steps completely blind, hoping that I'd get a result. By the time I did get a result, I had some form of a "Hello World" repo, the sum effort of doing stuff I was clueless about, and adapting stuff To Make It Work. I ended up publishing a Bref+Serverless Framework PHP "Hello World" Lambda repo in GitHub. I wanted to see if a few things would work in Lambda, so I did "Hello World" repos for those. I refactored my repos into about a half-dozen "Clone and Go" repos. Hard to believe, but so far I think I am the first dev to publish such repos, based on my failure to find any -- not for lack of trying!
I have published videos about Bref, but I really need to do something better, and broader. There are videos about PHP+Bref, but, like the videos I already published, I want to focus on specific things, not do a point-by-point, step-by-step, thing. Refer to my repo and the Bref repo.
My intention is to compensate for something that AWS does not make possible: to construct and run a "Hello World" PHP Lambda function from the AWS console. We cannot do this from the Lambda console because the "runtime" dropdown in this console does not have a "PHP" option. I want to help PHP devs do their first "Hello World" PHP Lambda functions using Bref+Serverless Framework, so they can quickly get something working. One you get it working, you can then trace all the different things in the AWS console, which is a big help in understanding what the hell is going on. I want to publish a series of brief, snappy, videos to help PHP devs on-board with Bref. This is going to smooth on-boarding, reduce aggrevation, reduce frustration, save time, and motivate PHP devs to learn more.
Help me produce and publish these videos.
top
PHP runtimes are a key thing. They are existential, in the sense that without one you cannot execute PHP on Lambda. I talk about PHP runtimes further here.
To say that I was resistent to learning how to do my PHP runtimes would be a vast understatement. I interpreted, and kind of still do interpret, Amazon's not making PHP a Lambda native language, as a way to off-load the costs of taking care of the PHP Community pertaining to Lambda on to the PHP Community. It's one thing to make money having the PHP Community use your service, but I resented what I saw as outsourcing costs of getting Lambda use-able by PHP devs to the PHP Community.
But, well, I've done a 180. Well, PHP should be Lambda native. But, even if PHP were Lambda native, we would still have to know how to cook up our own PHP runtimes. Perhaps ironically, but one Rabbit Hole of PHP Runtimes is the PHP compiling, which, strictly speaking, has nothing to do with the PHP runtime, sort of. I have spent my entire two decades of enjoying PHP as my prime language never having compiled PHP from source, ever! I took the PHP I used locally and on cloud servers totally for granted. It took a technology called "serverless" to get me to compile PHP from source. Based on the straw polls I've taken at PHP meet-ups I organize, PHP devs are not generally familiar with compiling PHP from source. It is going to make for an interesting presentation, as I plan on logging into EC2 live, and pasting lines from a repo from this project that I have not published yet, and producing compiled PHP that become PHP runtimes for Lambda. I have a lot of notes, run compiles on many EC2 instances. And am only now getting a feel for PHP runtimes. A bonus of this process is that now I am a PHP dev who has, albeit minimally, experienced PHP "internals". This is a Very Good Thing, and I look forward to promoting this perspective in my project.
One thing that dawned on me, is that you can do a custom PHP runtime for each PHP Lambda that you deploy. I am so used to cloud servers where you install PHP on it once, and then forget about it. Laravel's Forge really spoils me by having a feature that installs multiple PHP versions. But, you can cook up a runtime for each Lambda that you do. And, that is what I just might do. Which means building into my deployment process a runtime build sub-process. I suspect that this is going too far, but maybe not. Maybe, sometimes, this will be important to do. I've been contemplating how to automate new PHP compiles when new "point" versions of PHP are released, and the thought that I'd have to manually construct new PHP runtimes makes me queasy.
I have news for you: Bref has multiple PHP runtimes. So there is already a baseline of having a runtime per use case. So that gives you an indication of the Rabbit Hole to dive into. Runtimes is a critical area of Lambda, so help me go down this Rabbit Hole in its entirety, and then relay every crevice, every tidbit, every bit of knowledge to the PHP Community.
Also, seeing that DigitalOcean Functions also have something called a "runtime", I think that perhaps the Lambda runtimes are the baseline way that it is done, and the basis with which to approach alternative serverless platforms such as DO Functions.
It looks like all of AWS' exhortations to cook up my own PHP runtime had its effect on me: I took the hint.
top
To say that I was resistent to learning how to do my PHP runtimes would be a vast understatement. I interpreted, and kind of still do interpret, Amazon's not making PHP a Lambda native language, as a way to off-load the costs of taking care of the PHP Community pertaining to Lambda on to the PHP Community. It's one thing to make money having the PHP Community use your service, but I resented what I saw as outsourcing costs of getting Lambda use-able by PHP devs to the PHP Community.
But, well, I've done a 180. Well, PHP should be Lambda native. But, even if PHP were Lambda native, we would still have to know how to cook up our own PHP runtimes. Perhaps ironically, but one Rabbit Hole of PHP Runtimes is the PHP compiling, which, strictly speaking, has nothing to do with the PHP runtime, sort of. I have spent my entire two decades of enjoying PHP as my prime language never having compiled PHP from source, ever! I took the PHP I used locally and on cloud servers totally for granted. It took a technology called "serverless" to get me to compile PHP from source. Based on the straw polls I've taken at PHP meet-ups I organize, PHP devs are not generally familiar with compiling PHP from source. It is going to make for an interesting presentation, as I plan on logging into EC2 live, and pasting lines from a repo from this project that I have not published yet, and producing compiled PHP that become PHP runtimes for Lambda. I have a lot of notes, run compiles on many EC2 instances. And am only now getting a feel for PHP runtimes. A bonus of this process is that now I am a PHP dev who has, albeit minimally, experienced PHP "internals". This is a Very Good Thing, and I look forward to promoting this perspective in my project.
One thing that dawned on me, is that you can do a custom PHP runtime for each PHP Lambda that you deploy. I am so used to cloud servers where you install PHP on it once, and then forget about it. Laravel's Forge really spoils me by having a feature that installs multiple PHP versions. But, you can cook up a runtime for each Lambda that you do. And, that is what I just might do. Which means building into my deployment process a runtime build sub-process. I suspect that this is going too far, but maybe not. Maybe, sometimes, this will be important to do. I've been contemplating how to automate new PHP compiles when new "point" versions of PHP are released, and the thought that I'd have to manually construct new PHP runtimes makes me queasy.
I have news for you: Bref has multiple PHP runtimes. So there is already a baseline of having a runtime per use case. So that gives you an indication of the Rabbit Hole to dive into. Runtimes is a critical area of Lambda, so help me go down this Rabbit Hole in its entirety, and then relay every crevice, every tidbit, every bit of knowledge to the PHP Community.
Also, seeing that DigitalOcean Functions also have something called a "runtime", I think that perhaps the Lambda runtimes are the baseline way that it is done, and the basis with which to approach alternative serverless platforms such as DO Functions.
It looks like all of AWS' exhortations to cook up my own PHP runtime had its effect on me: I took the hint.
top
PHP containers are not a one-size-fits-all thing. Sometimes it will be better to not use containers, but to use regular PHP runtimes instead.
IMO, it is important to understand PHP runtimes first, as the basis of understanding Lambda+PHP. So, going down the PHP Container Rabbit Hole happens after doing the runtimes.
top
IMO, it is important to understand PHP runtimes first, as the basis of understanding Lambda+PHP. So, going down the PHP Container Rabbit Hole happens after doing the runtimes.
top
How I am supposed to set up my development process for deploying to Lambda?
Deploying to Lambda is a completely different process than deploying to a traditional cloud server. There is no server to SSH into in order to perform a "git pull" and "composer update". The actual deployment to Lambda involves neither, s you are just uploading files to AWS. Before this upload, the entire process that we would do on the cloud server has to be performed. Since we are not on a cloud server, where do we perform this "pre-build"? Where do perform the "Lambda upload" to AWS? Ironically, I am thinking of EC2 instances (a good use of the EC2 free tier instance?). But, I think a more generic, and popular, solution would be on GitHub Actions. That is kind of funny, essentially using Azure to deploy to Lambda.
One of the things that I want to do, and I've set up a GitHub org for this, is ask the PHP Community about "Best Practices" for deploying "micro" PHP to Lambda.
I expect that I will publish and maintain GitHub Actions for this.
Things I am thinking of:
• properly configured composer.json
• setting up the Serverless Framework's "serverless.yml" in different scenarios
• looking at the potential of this serverless framework plugin for CDK (thank you, Matthieu!)
• "best practices" for local, staging, and production environments
• "best practices" for namespacing, Lambda handler, temporary writable folder, github folder, etc
• "best practices" for deployment, including (and especially) GitHub Actions
• bake cost mitigation/fail-safes into these repos?
• testing, IAM, and keys
I will use GitHub Actions as part of the CI/CD process, and so I anticipate creating and maintaining FOSS GitHub Actions for this.
top
Deploying to Lambda is a completely different process than deploying to a traditional cloud server. There is no server to SSH into in order to perform a "git pull" and "composer update". The actual deployment to Lambda involves neither, s you are just uploading files to AWS. Before this upload, the entire process that we would do on the cloud server has to be performed. Since we are not on a cloud server, where do we perform this "pre-build"? Where do perform the "Lambda upload" to AWS? Ironically, I am thinking of EC2 instances (a good use of the EC2 free tier instance?). But, I think a more generic, and popular, solution would be on GitHub Actions. That is kind of funny, essentially using Azure to deploy to Lambda.
One of the things that I want to do, and I've set up a GitHub org for this, is ask the PHP Community about "Best Practices" for deploying "micro" PHP to Lambda.
I expect that I will publish and maintain GitHub Actions for this.
Things I am thinking of:
• properly configured composer.json
• setting up the Serverless Framework's "serverless.yml" in different scenarios
• looking at the potential of this serverless framework plugin for CDK (thank you, Matthieu!)
• "best practices" for local, staging, and production environments
• "best practices" for namespacing, Lambda handler, temporary writable folder, github folder, etc
• "best practices" for deployment, including (and especially) GitHub Actions
• bake cost mitigation/fail-safes into these repos?
• testing, IAM, and keys
I will use GitHub Actions as part of the CI/CD process, and so I anticipate creating and maintaining FOSS GitHub Actions for this.
top
Managing hundreds or thousands of "micro" PHP repositories scares the shit out of me. The number of PHP repos I already have that deploy to Lambda, without really trying, is growing like weeds on my lawn. When the Serverless Framework released version 3, I had to go to each repo to do changes. It was quite a taste of what's-to-come, foreshadowing burdensome overhead managing a shit-ton of "micro" PHP repos.
I searched for materials about this, but it's like the title of that old Star Trek movie (which sucked), "Undiscovered Country". The issue of managing repos seems like a place we just don't go to. Well, I think we need to go there.
Based on a terrific Toronto meet-up presentation Ben did, I did this blog post on my project site at https://phpserverlessproject.com/php-development-tools. There are a lot of PHP tools listed. Maybe some of these tools can help manage a plethora of repos. I have ideas, and I want to look deeper into what is out there. I want to poll the PHP Community for experiences and ideas.
Considering the conversation we had at our recent in-person meet-up about the co-relation between complexity and the number of repositories, not everyone will be able to minimize the number of repositories -- unfortunately!
top
I searched for materials about this, but it's like the title of that old Star Trek movie (which sucked), "Undiscovered Country". The issue of managing repos seems like a place we just don't go to. Well, I think we need to go there.
Based on a terrific Toronto meet-up presentation Ben did, I did this blog post on my project site at https://phpserverlessproject.com/php-development-tools. There are a lot of PHP tools listed. Maybe some of these tools can help manage a plethora of repos. I have ideas, and I want to look deeper into what is out there. I want to poll the PHP Community for experiences and ideas.
Considering the conversation we had at our recent in-person meet-up about the co-relation between complexity and the number of repositories, not everyone will be able to minimize the number of repositories -- unfortunately!
top
Right now, the only free and open source deployment solution for Lambda+PHP is the Serverless Framework, with Bref's Serverless Framework PHP plugin.
The Serverless Framework is an important tool in our toolbox. Please see the next section about creating a DIY PHP plugin. However, there is no one-size-fits-all solution for all Lambda use cases. Personally, for my stand-alone Blade forms deployed to Lambda, the Serverless Framework seems a bulky way to deploy.
A lightweight PHP-only solution will be pretty handy. I have not investigated which tool might be the best fit -- AWS' Serverless Application Model (SAM), AWS Cloud Development Kit, a straight CloudFormation template, but I want to look at each and report on each.
For those times when not using CloudFormation, perhaps just using AWS PHP SDK's "LambdaClient" class will be sufficient. My concern is IAM and the API Gateway when not using CloudFormation. I want to look into this and report on it.
I am not striving to build complicated software for deployment. I am not looking to replace the Serverless Framework with a PHP-only solution. What I am looking for is a lightweight PHP-only solution that has the option of using CloudFormation. And, lightweight PHP-only deployment solutions that contribute to the efficient management of "micro" PHP repos deployed to Lambda.
top
The Serverless Framework is an important tool in our toolbox. Please see the next section about creating a DIY PHP plugin. However, there is no one-size-fits-all solution for all Lambda use cases. Personally, for my stand-alone Blade forms deployed to Lambda, the Serverless Framework seems a bulky way to deploy.
A lightweight PHP-only solution will be pretty handy. I have not investigated which tool might be the best fit -- AWS' Serverless Application Model (SAM), AWS Cloud Development Kit, a straight CloudFormation template, but I want to look at each and report on each.
For those times when not using CloudFormation, perhaps just using AWS PHP SDK's "LambdaClient" class will be sufficient. My concern is IAM and the API Gateway when not using CloudFormation. I want to look into this and report on it.
I am not striving to build complicated software for deployment. I am not looking to replace the Serverless Framework with a PHP-only solution. What I am looking for is a lightweight PHP-only solution that has the option of using CloudFormation. And, lightweight PHP-only deployment solutions that contribute to the efficient management of "micro" PHP repos deployed to Lambda.
top
According to Datadog's 2021 "State of Serverless" survey (point #7), "The Serverless Framework is the leading way to deploy Lambda applications with AWS CloudFormation".
The Serverless Framework is an important tool in our toolbelt. However, it does not work with PHP out-of-the-box. In order to use PHP with it, you need to use a PHP plugin. Bref provides this plugin.
I want to create a skeleton PHP plugin for the Serverless Framework, as a headstart for do-it-yourself-ers. I would use this plugin as a bare-bones way of deploying my PHP code to Lambda. For PHP devs with specific needs that are not covered by community plugins, they can build on this skeleton.
top
The Serverless Framework is an important tool in our toolbelt. However, it does not work with PHP out-of-the-box. In order to use PHP with it, you need to use a PHP plugin. Bref provides this plugin.
I want to create a skeleton PHP plugin for the Serverless Framework, as a headstart for do-it-yourself-ers. I would use this plugin as a bare-bones way of deploying my PHP code to Lambda. For PHP devs with specific needs that are not covered by community plugins, they can build on this skeleton.
top
I agree with this recent PHP Ugly Podcast that Digital Ocean is terrific. I've been using their droplets for many years, in conjunction with Laravel's Forge. I was pretty sure that they would have a serverless offering, and when they bought Digital Ocean purchased Nimbella, a California serverless company, it was only a matter of time. A few weeks ago, Digital Ocean announced "DigitalOcean Functions".
I have read the articles, watched the videos, and looked at the sample PHP code. The PHP "Hello World" repo is very basic. Like AWS, they call their thing-that-makes-PHP-work-on-their-compute-service "runtimes", which makes me think that they constructed "Functions" along similar lines to Lambda; or, perhaps, used Lambda as a model. I have wondered if AWS releasing Firecracker as FOSS would help their competition. Maybe something to ask D.O. one day if they are using Firecracker. It looks like the out-of-the-box PHP runtime forces us to use the function construct. I find this constraint too, well... too constraining. Can I use namespaces and Composer?
As I was reading about DigitalOcean Functions, I thought that it was very important to understand Lambda as a baseline for looking at DO Functions. And, perhaps, would be the baseline understanding for looking at other non-Big-Three entrants into PHP serverless. It just reinforced to me the importance of getting an intimate understanding of Lambda expressed in terms of PHP. And then looking at D.O. Functions through a Lambda lens: is there such a thing as "cold start"? Is there an "optimal" way to code PHP for D.O. Functions? Are there layers? Droplets are more straight forward than EC2, because, among other things, there is no equivalent to IAM, nor are there regions. The pricing is more straight forward too. I am hoping that D.O. Functions is more straight forward than Lambda, for similar reasons. I want to dig into all of this as part of my project's first phase.
top
I have read the articles, watched the videos, and looked at the sample PHP code. The PHP "Hello World" repo is very basic. Like AWS, they call their thing-that-makes-PHP-work-on-their-compute-service "runtimes", which makes me think that they constructed "Functions" along similar lines to Lambda; or, perhaps, used Lambda as a model. I have wondered if AWS releasing Firecracker as FOSS would help their competition. Maybe something to ask D.O. one day if they are using Firecracker. It looks like the out-of-the-box PHP runtime forces us to use the function construct. I find this constraint too, well... too constraining. Can I use namespaces and Composer?
As I was reading about DigitalOcean Functions, I thought that it was very important to understand Lambda as a baseline for looking at DO Functions. And, perhaps, would be the baseline understanding for looking at other non-Big-Three entrants into PHP serverless. It just reinforced to me the importance of getting an intimate understanding of Lambda expressed in terms of PHP. And then looking at D.O. Functions through a Lambda lens: is there such a thing as "cold start"? Is there an "optimal" way to code PHP for D.O. Functions? Are there layers? Droplets are more straight forward than EC2, because, among other things, there is no equivalent to IAM, nor are there regions. The pricing is more straight forward too. I am hoping that D.O. Functions is more straight forward than Lambda, for similar reasons. I want to dig into all of this as part of my project's first phase.
top
Please note that there are two project phases, with your sponsorship pertaining to the first, short-term, phase only:
• a short term, intensive phase when the materials are published, from August 2022 to February 2023
• after this intensive period, ongoing maintenance and updates only --> but we'll see when we get there!
Sponsorship is not ongoing. It is short-term, to fund intensive work.
After this effort, it should be just a matter of updating things. However, who knows. With new investment coming into serverless there should be new entrants to look at. Or, maybe there will be something specific to do with my software. Regardless, phase one sponsorships will conclude. Let's assess what happens when we get there.
At this point, I want to fund my efforts with my podcast sponsorships and with PHP serverless gigs, and perhaps create a fresh sponsorship tier on GitHub Sponsors of a nominal amount so that I can promote by Founding Sponsors as ongoing.
top
• a short term, intensive phase when the materials are published, from August 2022 to February 2023
• after this intensive period, ongoing maintenance and updates only --> but we'll see when we get there!
Sponsorship is not ongoing. It is short-term, to fund intensive work.
After this effort, it should be just a matter of updating things. However, who knows. With new investment coming into serverless there should be new entrants to look at. Or, maybe there will be something specific to do with my software. Regardless, phase one sponsorships will conclude. Let's assess what happens when we get there.
At this point, I want to fund my efforts with my podcast sponsorships and with PHP serverless gigs, and perhaps create a fresh sponsorship tier on GitHub Sponsors of a nominal amount so that I can promote by Founding Sponsors as ongoing.
top
Free and open source repositories:
• "clone and go"
• pedagogical
• software repos
"Clone and Go" repos are how they sound. You clone it, you go through the readme and inline comments, and then you go. This is the head start you need. I already have a bunch of these repos at GitHub.com.
Pedgagical repos have no composer.json. They exist as documentation format, but the code is the star of the show, not the text. I am thinking that perhaps this will be the way to present custom PHP runtime. I can put code into files, and you can "wget" them or copy-paste the code. The one thing I want to avoid is a text-y documentation site, because I do not think these are very actionable.
It is kind of funny to have to list software as a category of repository, but I will be doing software too.
Free videos:
• help PHP devs with pain points
• one topic per video
• not courseware
• brief, "snappy", actionable videos
• companion videos for GitHub repos
There are lots of videos about AWS serverless, but very few that are specific to PHP.
I've done five videos:
• I have a somewhat basic competency with DaVinci Resolve
• I figured out a standard video structure to streamline video production (not going to win any design awards)
• I wrote new video packages for my software specifically for this project
• I set up a YouTube channel
Blog posts:
• project updates
• quick takes
• noteworthy things from AWS, such as announcements at re:Invent
Reference links: