Lambda, the AWS flagship serverless service, allow to run code on various runtimes. However PHP is not explicitly in the official product description. Does it mean you can't run PHP code on Lambdas? No it doesn't!

In this series (derived from a talk I gave to AWS User Group Poitiers), we'll discuss what serverless is and how to get PHP (if that's your favorite language) to run on Lambda.

What's serverless?

Serverless is a hosting paradigm where the cloud provider dynamically scales resources allocated to the customer's workload, while managing not only the physical infrastructure (servers, power cooling) but also up to the execution runtime (patching, ..).

In a strict sense, compute is allocated for every request, leading to a "scale-to-zero" pricing model (no resources are paid by the hour, but only proportionally to actual demand), while providing built-in high-availability.

That adds to other Cloud benefits, primarily the fact that everything comes with an API, making automation possible.

The sum of these benefits makes it possible to have virtually free feature-branch ephemeral environments, boosting developer productivity and lead time.

Serverless is not only about compute!

There is a plenty of solutions in the serverless ecosystem. When Serverless compute (Lambda) appeared, back in 2014, managed queues (SQS) had been around for a decade, and S3 for 8 years.

Note that in the slide above, Aurora doesn't match our strict definition of Serverless since it doesn't scale to zero (v1 scaled-to-zero but then could take minutes to start, with v2 you need to have at least 0.5 ACUs on both your writer and reader instances for the database to be ready to serve queries.

You'll find below a typical architecture for hosting a web application involving only serverless services. Hosting such an application could cost less than $1/year for a limited number of users.

Is Serverless only for microservices?

Yes.. and no. It was designed with microservices in mind but you can still deploy a monolithic architecture (as long as you don't have long-running start up sequence every time a new environment is launched).

Serverless options to solve common challenge with microservices: Orchestration and Choreography

Microservices architecture make it possible to reduce coupling between applications components (using different languages, through asynchronous patterns, improving scalability by removing infrastructure-level coupling).

However, when we have multiple single-purpose functions, implementing the business logic may require coordination between functions. This coordination can implemented using two fundamental patterns.

• Orchestration: in this pattern, we control invocations of the function in an imperative way. This is often use within a business domain, when functions are delivered by a single service team. A serverless approach for this is AWS StepFunction, a workflow / state-machine. There is a nice tutorial on how to coordinate Lambda functions using StepFunction here.
• Choreography: this pattern is more relevant in cross-business-domain scenarios, with separate service teams, to maintain very limited coupling. An event bus enables application to push events and subscribe to events. Multiple consumers can subscribe to the same event and each consumer can filter whatever events they need. The core AWS service for this is EventBridge. You'll a blog post I wrote about it here.

Getting to know Lambda

Lambda is AWS's Function-as-a-Service solution. With Lambda you can deploy your code and get instant high-availability and scalability, without worrying about instances deployment and OS or runtime patching.

Lambda can used with synchronous invocations (via an API Gateway, an Application Load Balancer or a Lambda function url) or asynchronous invocatons (responding to either AWS-generated or user-generated events).

When you deploy a Lambda you chose how much memory it needs to run. Allocated CPU is proportional. You then pay based on the number of milliseconds used. For instance a 128Mb Lambda costs 1.7*10^-9$/ms. That's 164 hours of compute before you spend your first dollar.

And Lambda scales. Fast. Much faster than anything else. No more 429s (or 500 if you're workload is not well protected) errors due to high traffic variation.

Solving the main challenge with LambdaLiths: cold starts

Lambda execution environments process only one single request at a given time, and are re-used for subsequent requests. That means that, for a Lambda function to scale, or when a Lambda function hasn't been invoked for a while, Lambda will have to start a new execution environment : that's a cold start.

If cold starts are detrimental to your application (again, that's probably better that all traffic being slow or hitting 429s), then there are a few options. AWS has a nice article about using Lambda warmers or setting provisioned concurrency to address it. In addition to those, for Java users, Lambda SnapStart features makes it possible to deliver good cold start performance, by snapshotting the microVM after the JVM inits.

What about PHP support?

The official product FAQ states it "natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, and provides a Runtime API which allows you to use any additional programming languages to author your functions."

In the next blog posts in this series, we'll explain how you can run PHP on Lambda leveraging two distinct frameworks, Bref and the Lambda Web Adapter, and compare the possibilities offered by each of them.