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 ( 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 ( 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 (, 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.
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.

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.

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.

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.

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.

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 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!

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.

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.

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.

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.

Free and open source repositories:
The most actionable thing I can publish for PHP devs are repositories. Best thing is to see the code in action. There are three types of repos I want to publish:
   • "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

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:
Video is a powerful medium. Producing videos is a key aspect of my project:

   • 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:
Sometimes an article is the better than a video. Such as this one I did on AWS credentials. Blog posts are handy for:
   • project updates
   • quick takes
   • noteworthy things from AWS, such as announcements at re:Invent

Reference links:
It started with writing down a few links for myself. When my list grew, I put them on a web page on my LaSalle Software site. When I created my new project site, I wrote new "link" packages specifically to curate these links.

Amazon per use charges can be frustrating to understand. This is how Lambda is charged:

⦿ the number of requests for a Lambda function (regardless of how it is invoked)
⦿ how long it takes your code to run, rounded up to the nearest 1ms (duration)
⦿ the amount of memory you allocate to your Lambda function impacts your code duration
⦿ did you enable provisioned concurrency?
⦿ be mindful of data transfer & VPC usage
⦿ you might have a use case for Lambda@Edge
⦿ what about the associated Amazon services, such as API Gateway and CloudWatch?
⦿ the free tier for Lambda:
   • 1 million requests per month,
   • 3.2 million seconds of compute time per month
   • always free

With Lambda, your price per 1ms depends on the amount of memory you purchase to run that Lambda function. So what is optimal?

Things I worry about with Lambda per-use billing:
⦿ what if I get DDoS'd?
⦿ what if I do something in my code that initiates per-use charges that I did not mean to do?
⦿ what if I am just trying to learn Lambda and end up triggering big per-use charges simply because I am a newbie?
⦿ what if something happens that I don't know about until I see the invoice?

I want to see if and what notifications and fail-safes can be included in the repos.

Reading about S3 egress fees, story of "why we ditched DynamoDB", questioning "Is the AWS Free Tier Really Free?", and Why AWS charged me for Free Tier are warnings to be cautious about AWS charges. Cost is a major topic to focus on.


⦿ Lambda environments are more constructs than physical -- serverless vs servers
⦿ how to set up local, staging, and production environments using PHP?
⦿ how to use Composer with Lambda environments?
⦿ how to use Git branches with Lambda environments?
⦿ deployments to Lambda are "push", not "pull"
⦿ use GitHub Actions to deploy PHP Lambda functions
⦿ "observability" and "monitoriing"
⦿ "micro" PHP development
⦿ should we be using the CDK by way of this Serverless Framework plugin?
⦿ workflow for runtimes and layers
⦿ what does the PHP community consider "Best Practices"?
⦿ encapsulate this knowledge into repos, do videos about these repos


⦿ AWS SAM CLI vs the Serverless Framework?
⦿ local and staging environments
⦿ runtimes and layers
⦿ incorporating PHP tooling

Repository Management:

⦿ managing repos when there are dozens, hundreds, (thousands?!), of small services oriented repositories
⦿ "dot"" folders
⦿ composer.json
⦿ branches
⦿ the Serverless Framework's serverless.yml file: are there ways to manage it?
⦿ is there a way to change the runtime in the serverless.yml en masse instead of manually changing each one-by-one?
⦿ repos when the only file is the serverless.yml (or SAM template)
⦿ PHP tooling

AWS serverless is an entire platform. These Amazon services work hand-in-hand with Lambda:

⦿ CloudFormation
⦿ API Gateway
⦿ S3
⦿ CloudWatch

There are a lot of Amazon services available for use with Lambda, including:

⦿ CloudFront (Lambda@Edge)
⦿ DynamoDB, and the other database alternatives
⦿ Step Functions (orchestration)
⦿ EventBridge

What is a runtime? I think of it as: no language runtime = cannot use that language with Lambda.

AWS provides runtimes for seven languages. For other languages, you have to Bring Your Own Runtime. Or else, you cannot use Lambda with that other language.

The AWS docs says that:

"The runtime provides a language-specific environment that runs in an execution environment. The runtime relays invocation events, context information, and responses between Lambda and the function. You can use runtimes that Lambda provides, or build your own. If you package your code as a .zip file archive, you must configure your function to use a runtime that matches your programming language. For a container image, you include the runtime when you build the image."

Well, if that does not clear up the confusion... I was quite angry that PHP is not a Lambda native language, forcing us to be concerned with PHP runtimes. I have since come to the conclusion that PHP devs should be concerned with PHP runtimes. Optimized runtimes can lower your Lambda costs, and your use case determines how you construct your PHP runtime. A Bref blog post, at "Bref 1.0 is released", says that, "By removing [PHP extensions that were not commonly used]], we make your Lambda lighter... improving cold start performance". So controlling your compiled PHP can help with your Lambda costs.

How exactly do we "optimize" our PHP code for Lambda? Is it advantageous to use Layers, or just stick with using Composer to prepare our uploads to Lambda? There is no storage fee and no egress charges for Lambda Layers (from an AWS Repost), so perhaps there is an advantage there. What should we do with the bootstrap file? What do we do about Lambda cold starts? There is much to look into, and then express in PHP terms.

Runtimes are elemental to using Lambda. There is no one-size-fits-all PHP runtime. We should not take PHP runtimes for granted; instead, we should construct our own PHP runtimes, suitable for our use case.

PHP was not, is not, and very likely shall never be, a Lambda native language.

Not being Lambda native means that AWS does not maintain first-party PHP runtimes. And, that AWS does not maintain first-party docs about using Lambda with PHP. Notwithstanding the blog posts and repos AWS has published over the years about using Lambda with PHP.

In November 2014, Amazon Web Services announced their new Lambda service:
⦿ announcement on the AWS website
⦿ announcement at re:Invent 2014
⦿ "Getting Started with AWS Lambda" session at re:Invent 2014

The only natively supported programming language that Lambda supported at launch was Node.js. Since Lambda's launch, AWS has made six more languages Lambda native:
⦿ Java in June 2015
⦿ Python in October 2015
⦿ C# in December 2016
⦿ Go in January 2018
⦿ PowerShell in September 2018
⦿ Ruby in November 29, 2018

At the same time that Ruby became Lambda native (on November 29th, 2018), AWS announced Lambda Layers and Runtimes. After this announcement, Lambda ceased making additional languages native to Lambda.

My journey into Lambda+PHP started with my assumption that when the time came for me to use Lambda, AWS would provide the docs and repos to get me going. This is because AWS provides wonderful first-party PHP support for its services. Wwhy would Lambda be any different?

AWS provides direct PHP support for its services in the following ways:
   • they maintain their own first-party PHP SDK
   • AWS maintains their PHP SDK on their main GitHub account
   • AWS maintains a developer guide on their "docs" site
   • They maintain an API reference on their "docs" site

On top of that, there are things like their "PHP Code Samples for Amazon S3", which is also on their "docs" subdomain.

I took it as axiomatic that AWS provides direct, first-party, PHP support for its services. So much so that I blamed myself for failing to find official documentation about Lambda+PHP on the AWS website.

There are blog posts about Lambda+PHP. I find these blog posts to be a mish-mash of marketing and tech tips. The companion repos on GitHub, when published, are more helpful. But, at best, this is ersatz support.

In 2016, these were the Lambda native languages: Node.js ("the original"), Java (2015), and Python (2016). C# was just made Lambda native. AWS published a blog post on December 09, 2016, with the title "Scripting Languages for AWS Lambda: Running PHP, Ruby, and Go". This post opens with, "Lambda provides native support for a wide array of languages, such as Scala, Java, Node.js, Python, and C/C++ Linux native applications. In this post, we outline how you can use Lambda with different scripting languages". (I have no idea what Scala is, why it is listed as Lambda native). Why is AWS publishing an article about these three languages? I figure the reason why AWS is publishing an article about these three languages is because these languages represent a major potential source of Lambda revenue, and Amazon wants to on-board devs using these languages.

Amazon made two of these three languages native. Go in January 2018, and Ruby when the Lambda Runtime API was announced at re:Invent 2018. It sure looks to me like confirmation that these three languages are important to AWS. I have not found anything about why PHP was not made Lambda native?

With the advent of the Lambda API Runtime, my guess is that no language henceforth will be deemed native. Since getting Ruby in under the wire, no language has been made Lambda native.

I did not find this AWS Compute Blog post on the AWS website. I found it on a third-party site that linked to the original AWS blog post That URL is a 404 now.

If AWS recognizes the PHP Community as a significant potential source of Lambda revenue, and PHP is not Lambda native, and given that PHP runtimes are necessary for us to use PHP on Lambda, then it would make sense for Amazon to focus its efforts on having PHP devs cook up our own PHP runtimes. Which is what happened.

In December 2018, after the re:Invent that announced Lambda's API Runtime, AWS published this blog post: "AWS Lambda Custom Runtime for PHP: A Practical Example (Dec 2018)". This a good blog post, just gets to the point and provides a good recipe. If it was this important to provide us with a runtime recipe, why not just provide the runtime? At least, AWS should just cook up a sample runtime so PHP devs can play around with Lambda, and then get excited about doing "real" PHP runtimes on their own. This is a pretty good article, but it is not kept up-to-date.

AWS published a six part series on their Compute Blog in July 2020, "Introducing the new Serverless LAMP stack", along with a companion GitHub repo. IMO, these articles are communicating that PHP devs are not cooking up their own PHP runtimes. So, AWS is looking at the number one thing that PHP devs do, and sell them on cooking up their own PHP runtimes, by selling them on using Lambda to host their monolithic PHP apps. Naturally, after selling the LAMP stack on the AWS serverless platform, they get right into cooking up our own PHP runtime. Of course this is the first thing, because runtimes are existential to revenues.

IMO, AWS seems frustrated. PHP devs are not on-boarding onto Lambda as much as they would like, and so there is more of a sales focus in this series. At the bottom of part four, two surprising links are displayed: one to Vapor, and the other to the Bref project. They might as well have said in the blog post, "Hey PHP Devs, go check out this GitHub repo, and also check out Vapor and Bref, depending on which one is more suitable for you". There, mission accomplished. If you are not going to cook up your own runtime, then the only way you are going to on-board to Lambda is to use someone else's PHP runtime. And, for that, there are just two games in town: Vapor, which you have to pay for. And Bref, which is free open source software.

AWS published a brilliant repo on October 19, 2021. I do not think that they published a blog post for it. This repo is called "PHP Runtime on Amazon Lambda", and resides on the the "aws dash samples" GitHub account. The heart of this repo is a 600 line CloudFormation template. This is a developer's mindset at work, to come up with a software solution to the problem of getting PHP devs to cook up their own PHP runtimes. Instead of going through a recipe, and asking us to run all the code and stuff ourselves, this is at least some type of coming halfway. This template is really well done. Unfortunately, there is no way we can use this for production. It is a one-off effort, and a good one at that, but it is not updated. A very interesting approach.

There is only one single, ongoing, going-concern, project devoted to using Lambda with PHP:

Bref is not one thing. It is four things:
   • Bref maintains a PHP plugin for the free and open source Serverless Framework (to deploy to Lambda, see point 7)
   • Bref maintains PHP runtimes for Lambda
   • Bref maintains docs about using Lambda with PHP with Bref
   • Bref maintains free and open source software to interactions between Lambda and other Amazon services

Bref maintains a very active GitHub repo. They are up to 134 releases, 127 contributors, 2,466 commits, and 2,500 stars. The first commit was on October 2017.

Matthieu Napoli started this project just to kick the tires, so to speak, of using Lambda with PHP. The project grew into what it is today. Matthieu now works for the corporation that makes the Serverless Framework, Serverless Inc., as Senior Project Manager. He was interviewed on a recent Serverless Chats podcast. Matthieu is also an AWS Community Hero. Here is Matthew at re:Invent 2021, and in a recent Serverless Office Hours stream.

According to the Datadog "2021 The State of Serverless", "The Serverless Framework is the leading way to deploy Lambda applications with AWS CloudFormation". A whopping 90% of organizations that use a CloudFormation wrapper use the Serverless Framework. Bref maintains a PHP plugin for the Serverless Framework.

I cannot emphasize this enough: Bref provides what Amazon will not -- PHP runtimes, and docs for using these runtimes.

The Bref Project provides an essential implementation for using Lambda with PHP. No one else is doing this, and we would be screwed without it.

As comprehensive as Bref is, and it is very comprehensive, one FOSS project cannot cover all the bases. My project, perhaps embryonic yet the ball is rolling, is just the second ongoing project devoted to Lambda+PHP, and to PHP serverless in general.

I feel very strongly that "micro" PHP development is going to trend up.

This does not mean that I think that monolithic PHP development is going to come to an end. Not at all. I think that the advent of serverless platforms, our increasing proficiency of pairing PHP with these serverless platforms, the increase in the number of serverless platforms available beyond The Big Three, and PHP devs doing more "small PHP coding" for serverless (and not just looking at serverless as an alternative hosting platform for monolithic apps) is going to drive the rise of "micro" PHP software development.

What I mean by the term "micro" is small, independently developed, pieces of PHP code, residing in their own repos, with their own CI/CD process.

According to the 2021 JetBrains Developer Survey (their 2022 survey is not out yet), 70% of PHP apps in production use php-fpm and 19% use mod_php. Only 9% of PHP is deployed to serverless platforms. Of the PHP deployed to serverless platforms, I am sure that the bulk of these apps are monolithic. There is a huge potential for PHP on serverless that is not for monolithic apps.

Lambda's provisioning feature enables "micro" PHP development, because the production environment does not have to be physically set-up, nor maintained (although "maintenance" is done via the PHP runtime). The physical server does not have to be created.

Just as key is being able to run the code from external, non-AWS, sources, so the API Gateway is important too. The virtual host does not have to be set up. The C record does not have to be created. This entire overhead is dispensed.

Mounting monolithic PHP apps is not the original intention of Lambda. See my next section for a recent interview with Dr. Werner Vogels. What attracted me to Lambda in the first place is deploying small pieces of PHP code without the server overhead.

There are three things in particular that I want to do with "micro" PHP code deployed to PHP serverless: deploy stand-alone forms that render Blade, deploy stand-alone form handlers, and deploy back-end processes that may or may not return data. Fourth is interacting with other Amazon services, but I confess that I am looking at Twilio to hand in-and-out bound emails for my custom podcasting platform.

Dr. Werner Vogels, Amazon's Chief Technology Officer, joined Amazon in 2004. Recently, Dr. Vogels was interviewed on the Serverless Chats podcast, episode 132. I recommend that you listen to this episode, and/or read their transcript.

I want to quote the portion of the interview, at the four minute mark, when Dr. Vogels talks about the genesis of Lambda. I am taking a certain license with this quote to draw out some things that he says.

"Almost everything else in AWS is serverless by nature. For any given Amazon service, customers do not have to worry about scale, reliability, performance, managing costs, etc. The only thing that was not really serverless was compute."

"The problem we were looking at was customers having small tasks to perform. To perform these small tasks, they had to run active EC2 instances. To successfully execute the scale of these small tasks, they basically had to run dozens of active idle EC2 instances waiting for work. When this work was really small, it was hugely inefficient to run EC2 fleets."

"How do we bring the scalability, reliability, performance, and all that stuff that we have in our other Amazon services, to compute? Our customers want to trigger these small tasks when other Amazon services are accessed. How do we do that? How do we execute this code on-demand, without having to reserve fleets of active EC2 instances? How do we charge for executing these small tasks on an on-demand basis?"

"What kind of primitives can be built? Our customers are implementing complex patterns to solve their problems. How do we build these solutions into a compute service so that our customers are relieved of the burden of building these solutions themselves? This is, in essence, the birth of Lambda."

"We saw customers implementing these complex patterns for small tasks well before 2014, the year when we launched our Lambda compute service. However, we just did not have the experience and the knowledge of exactly how to build this when we first identified the need to build An on-demand compute service. And, when we identified the need to create this new compute service, we did not have the experience, nor the knowledge, to do it in a way that would be affordable for our customers."

"The compute service we were thinking of building had to be pay-as-you-go. Building a compute service that is pay-as-you-go is both a technical challenge, and a mental switch. Paying for actual execution time is both a technical challenge, and a mental switch from the traditional cloud server. An on-demand, pay-as-you-go, paying for actual execution time was a radical shift in thinking about compute. This was a RADICAL SHIFT in thinking about compute."

"At the time we were contemplating this new compute service, I think they were still paying for EC2 by the hour. It took a while before it went to the minute. We were coping with the technical challenges of being able to charge for EC2 by the minute. So we had a ways to go technically to figure out how to charge on a pay-as-you-go basis for this new compute service."

"Internally, here at AWS, we had to build new technical proficiencies in order to build this new compute service. But, it was not just a matter of building new technical proficiencies. For us, and for our customers, it was a switch mentally. It was a mental switch that you are going to pay only for the actual execution time. This was a radical shift in thinking about compute. We think of compute as a fully installed cloud server. Thinking of compute as lightweight and nimble compute service was a radical shift in thinking about compute. A lightweight and nimble compute service that allowed for a whole new set of patterns."

There are a number of things here that are very relevant to my project.
   • Lambda is a compute service, not a cloud server
   • we are so used to traditional cloud servers, that it takes a "mental shift" to grasp compute as a service
   • this "mental shift" is so drastic, that it represents a "radical" shift in thinking about compute
   • compute as a service requires a "radical shift" in our conception of compute
   • compute as a service requires a "radical shift" in the technology to deliver it
   • Lamba was conceived as a way to execute small tasks that relate to other Amazon services
   • Lambda is an intensively proprietary Amazon compute service

This PHP Ugly podcast a few weeks ago, "Episode #290: PHP Lambos and Lambdas", included a very interesting chit-chat about Lambda. Starting at 26min 34secs, and ending at 34min 16sec. I want to note some of the things they talked about.

At 26:50, "... there have been variations of what serverless means. The big player in this arena has been AWS... it is soooo stinking complex on how to get everything set up... understanding how to get the correct authentications, getting everything talking to everything correctly has always been this bit of a struggle...".

At 27:55, "[Digital Ocean] is like 'AWS Light'. They have the important... services that you would use at AWS without a lot of the complexity...".

At 28:33, "Well, now, Digital Ocean has something like this, I am very curious [about it]... called App Platform, is like AWS Lambda...".

At 29:08, "... one step it had up on Lambda [is that PHP runs out of the box... The weird thing about Lambdas is you can get very caught up in the situation... where you can run up your [AWS] bill through the roof. I am wondering how Digital Ocean stacks up against that... Lambda services are not meant to run 24/7. It is not meant to be 'A Server'... [Lambda] is meant to run small little applications that you can off-load... a common example is photo processing... is process intensive but only needs to run for a minute, and then I'm not going to need to run that again for another three or four days..."

At 30:58, "It depends on your definition of serverless... As long as I can manage the server, it is always there for me, and I can always customize the server for for the release of the language that I want to run and what is connected to it".

At 31:28 --> Q: "Is an EC2 instance serverless?". A: "No. That is a server [that] you have to log into.. you have to manage it, you have to patch it.".

At 32:49, "The big thing with AWS' Lambda's is it did not support PHP out-of-the-box... Bref helps you run PHP applications on Lambdas... and Taylor came out with Vapor..."

At 33:30, "[Lambda] has always felt like a work-around to get it to work in AWS, whereas Digital Ocean out-of-the-box supports PHP".

At the end of the segment, there's a peek at the Digital Ocean website where it is stated that Digital Ocean's new serverless offering is called "Functions".

This conversation reinforces my impression that serverless in general, and Lambda in particular, are still mysterious things for PHP devs. I pin this completely on Amazon, as a logical consequence of PHP not being Lambda native. What did AWS think was going to happen?

As Dr. Vogels said, Lambda represents a "... a radical shift in thinking about compute. We think of compute as a fully installed cloud server. Thinking of compute as lightweight and nimble compute service was a radical shift in thinking about compute. A lightweight and nimble compute service that allowed for a whole new set of patterns". PHP not Lambda native has not been a help.

It makes complete sense to me the sentiment expressed in this conversation of the hope that the Digital Ocean serverless offering is "Lambda Light". I feel the exact same way. I have enjoyed using Digital Ocean droplets for many years (in conjunction with Forge) in part because it is so much easier to use than EC2. If I may point out, Digital Ocean is not out to replicate many Amazon services. D.O. does an excellent job with their cloud servers. My use case calls for a more straight forward implementation of cloud servers -- no IAM, no VPC, etc. I am hoping that the new Digital Ocean Functions is a more straight forward implementation of serverless than Lambda, I have not dug into it yet.

Lambda was announced at re:Invent 2014. Digital Ocean announced Functions in 2022. So with that head start, in the same month that D.O. announced their serverless offering, this podcast, the longest running continuously produced PHP podcast in the world, has this conversation.

I wrote a section about Digital Ocean Functions.

Ok... to be candid here, I was up one night, as I've been wont to do mulling this project and sponsorship thereof, wondering how much money my project could potentially make for Amazon. Amazon published blog posts and GitHub repos whose primary mission is to get PHP devs to cook up their own PHP runtimes. I want to dig into PHP runtimes and containers, in a way where PHP devs understand what is under the hood, and where they can cook up their own optimized runtimes and containers, in accordance with their use case. And providing repos and videos to give fellow PHP devs a head start. My project has the potential of on-boarding new Lambda consumers.

Furthermore, I am advocating small PHP code bases. Sometimes it's just a couple of dozen lines of code. Sometimes it is a defined, single featured process, such as my own podcast RSS feed file generation. Or, maybe rendering stand-along forms. Or, perhaps, as Amazon originally intended, small pieces of code that interact with other Amazon services. This is more an untapped way of PHP devs using Lambda, representing (methinks) a size-able growth area for Lambda+PHP.

The "Serverless Architecture Market by Service Type" states:
   • serverless infrastructure market @ $7.9 billion (USD) in 2020
   • serverless infrastructure market project to grow to $21.9 billion (USD) by 2025

This article at says in Q1 2021, AWS had 32% market share. I remember seeing somewhere that Lambda had 60% market share of serverless, but I cannot find it. Still, with 2022 at $13B, the AWS serverless platform, at 32% is bringing in over $4B. The 2021 Datadog State of Serverless, point number 8, implies, that PHP is but a smidgen of Lambda usage. If PHP represents a mere 1/10 of 1%, that is still $4 million. I think it is safe to say that there is potential for my project to generate at least my sponsorship amount in Lambda revenues.

I got into Lambda because I was looking for simple way to deploy small, targeted-scoped, features for my own custom podcasting platform.

I've been doing podcasts on-and-off for the last 10 years, and am re-starting them. I am doing three podcasts, "LaSalle Software News", "The Bob Bloom Show", and The Bob Bloom Interviews. Each are about PHP, and each will talk a lot about PHP serverless. I want to get sponsors for my commentary and interviews show, and I want to pursue a good production pace for my shows. I built, and continue to build, a custom podcasting platform to help me manage, produce, and publish my podcast episodes. It is based on my own free and open source LaSalle Software, which is based on the Laravel Framework. My admin uses Laravel's commercial Nova package. My "CRUD" admin works very well. It's what you'd expect, and includes a few pet features. My front-end domains all fetch data from the admin app. Deployed with Forge and Digital Ocean.

Non-CRUD features whet my appetite for developing outside of my admin app, while still using my database.

Creating a new podcast episode is a bit involved, and to make it easier, I created a wizard to take me through the stpes. The CRUD screen works, but there is a bit more to it than just filling in a few fields. I successfully created the wizard within my admin app, but it feels kludgey, and a bit constraining. I would have preferred to do this feature "outside the app", but it was expedient to do so within. I do not use Nova for this wizard.

The RSS Feed File Generation is a critical feature that I would really like to extract out of my CRUD app, into its completely separate environment. I would prefer to have a repo where I know that the only thing there is for this feature. No burying the tests inside app tests. No worries that making a change somewhere is somehow going to futz up this feature. This feature could grow into something more intense than it is now, worthy of its own repo. I created a separate package for this feature for my admin app to at least have this code on its own, in a place where I can find it.

The feed file is but one process in the post-production sequence. I wanted to get the entire post-production process out of my admin app, but ended up doing a pretty intense wizard inside my admin app, but external to Nova.

I want to build special features to help me with my Interviews show. Such as forms for guests to upload their logos and visages, and handling email correspondence.

What amazed me is that, for someone absolutely steeped in doing monolithic PHP web apps, I want to do these features in their own repos, deployed separately. Even if it means that a mere dozen lines of PHP end up in their own environment, not unlike my sample blade form. The only I saw to achieve this was to wrap everything in an API, which involved so much overhead that it was not worth it. A lot of the time, there would be more overhead API code than feature code.

Short story made even shorter, I ended at knocking at Lambda's door. Despite being frustrated, confused, infuriated, and woefully clued out, I somehow persevered to do a working "Hello World" PHP Lambda function from the command line using Bref. Could I composer install a Laravel Framework package for Lambda? Yes. Could I render a Blade form? That took a bit of doing, but yes. When that worked, I was hooked.

What really attracted me was the API Gateway. Lambda provisions the server, saving the hassle of physically setting up the server. But, wow, the API Gateway automatically assigns a URL and handles the routing. When it matters, I can assign a subdomain to an API Gateway URL. Because, well, I was wondering how I was supposed to do the routing. With the routing off my hands, I can completely dispense with the API wrapper.

What happened next was that I did up a bunch of repos to try things out. And, wow, just playing around these repos added up. How many repos might I have for my podcasting platform that deploy to Lambda? My estimates start at two to three dozen, and go up from there. The prospect of updating each repo every time something changes, such as package versions in composer.json, literally scares the shit out of me. The API overhead Lambda + API Gateway saves me will turn into overwhelming repo management overhead.

And that is how I ended up on this serverless journey.

What have I done with my project so far?

   • I bought the "phpserverless dot com" domain
   • with my free and open source PHP LaSalle Software, I built this website
   • I wrote new Software (private) packages for my list of reference link
   • I wrote new (private) packages for my videos
   • I set up a new GitHub Organization, called "lasallesoftware-serverless"
   • I created a new repo strictly for Discussions
   • I set up GitHub Sponsors, which took almost a month as I ended up helping GitHub figure out issues with Stripe Express

At first, thought the best thing to do would be Twitch streams, because the emphasis would be on going through issues with fellow PHP devs. I would then extract the good stuff from the stream recordings into bite-sized videos. I downloaded the remarkable DaVinci Resolve video editor to do the editing. As I was getting a handle on DaVinci Resolve, I started to appreciate the power of video. I had underestimated video. Sure, I can splice stream recordings. But, I could also do screencasts about specific issues, and then edit them down into a short, snappy video.

I made five videos. The amount of time it took was unbelievable! I put together a standard format to help speed up future video productions, because I want to get into doing a lot of short, snappy videos. Four of the videos are brief, focusing on one main theme. The fifth is more like what I was thinking of doing with the streams, being a longer live demo video, and having done it just reinforces that I need to do short, tightly themed, videos.

I did a half-dozen "clone-and-go" repos.

So, there is enough done already to give you a flavour of where I am heading with my project.

When you realize that the five videos I did for my project were published over a year ago, you are going to want to know why I have not done videos since. You are going to want to know why my blog is not updated. Why the delay getting the ball rolling?

Well, one reason is that I am a chicken-shit. I am afraid that I will piss off AWS due to my criticism. I am afraid that, somehow, I will piss off someomne in our PHP Community. In this day-and-age, it does not take much these days to get someone angry.

Another reason is that I've spent an insane amount of time doing up this description, and writing draft upon draft upon draft of my special podcast episode. I tried too hard to hit the right notes, to be as inoffensive as possible. I found it hard to describe my project without getting mired in endless lexicon and explanations. Many explanations started with "PHP is not Lambda native" and it was downhill from there.

I have been scratching my head how I am supposed to go about reaching out to potential project sponsors. Specifically, what I am selling? I am not selling products. I am not selling services. You are not buying anything. The essense of project sponsorship is donating. Which means what I am doing is begging, which is actually what it feels like. In the absence of pitching a product or service, it just feels weird. My project is fundamentally sound, of that I have no doubt. Yet, I have not been able shake my embarrassment.

I did a podcast about sponsorship, "Gifting a Contract". As well, last December's Voices of the Elephpant podcast talked about sponsorship, with the PHP Core Team talking about the new PHP Foundation.

It's been easier to avoid going through with my project, but it is time to get the ball rolling. In the intervening time period I've been putting things off, we are still in the same situation. I need the knowledge and techniques that I will learn from this project to develop podcast features that I will deploy to Lambda (and to D.O. Functions).

I certainly has not helped that it has taken me seemingly forever wrapping up this description, doing my special "Bob Bloom Show" episode, and doing my special letter at the top of this description.