PHP ON LAMBDA

WITH CUSTOM RUNTIMES

MergePHP January 2024

Ian Littman / @ian@phpc.social / @iansltx

Follow along at https://ian.im/lambmerge24

Questions We'll Answer

• Why you'd use Lambda, and what caveats come with using it
• How Lambda works with Custom Runtimes (including PHP)
• How to build an email reply bot with Lambda, SES, S3, and PHP
• How to build a Lambda-powered API via
  • API Gateway
  • Function URLs
• Bonus: How to build API Gateway endpoints with Bref

Topics We won't cover

• A deep dive into Bref or Serverless Framework
• Building Lambda applications via AWS's CLI
• AWS SAM
• Laravel Vapor

WHY LAMBDA?

• No servers to manage
• No worrying about concurrency within an app instance
• Quick automatic scaling + high levels of concurrency
• Millisecond-level billing + fair-sized free tier
• Stateless per-request, shared-nothing-ish
  thanks to Firecracker microVMs
• Integrates with other AWS components

What kinds of integrations?

• Trigger events from S3, SNS, SQS...and a lot more
• Application Load Balancer (billed for capacity + time)
• API Gateway (billed per request)
• Directly via AWS's APIs (sync or async)
• Directly via HTTP with Function URLs (more info)

Shared-nothing-ish?

• AWS keeps Lambda containers around for a bit
  to avoid "cold start" penalties
  • Cold start penalties are proportional to bundle size
  • Sometimes AWS will proactively init
  • ​weathermap
• /tmp storage available per-instance; can use as a cache
  • 512 MB by default
  • Up to 10 GiB if you pay for it
• Instances
  • != invocations
  • == concurrency

A note on performance

A note on Billing

Virtual Private Caveats

• No internet connectivity by default
• NAT Gateway is $$$ (4.5¢/hr + 4.5¢/GB in main US regions)
• Workaround: split functionality between functions
  • Internet-connected, outside VPC (external APIs)
  • Internet-disconnected, inside VPC (internal resources)
  • Pass info between via queues, S3, etc.
• Public IPv4s cost money as of February 1
• IPv6 IPs are free, and now you can use them outbound
• Cold start times No longer an issue as of late 2019

So, what about PHP on Lambda?

• Custom runtime support has been available since 2018
• Build the file system needed to run your function code
• Store the file system as one or more (up to 5) Layers
• Worker-based, long-polling-esque model
• NOT HTTP request based without additional abstractions

Layers

• Built on top of Amazon Linux 2023
  • Can also specify AL2 or original Amazon Linux
• Extracted to /opt (function code is in /var/task)
• Versioned
• Can include library dependencies (e.g. /vendor)
• Zipped + submitted to AWS API (like functions)
• Function specifies inclusion order

Custom runtime lifecycle

• Bootstrap (cold start)
• Task execution (warm start)
• Lambda decides when to kill the instance
  • Inactivity timeout
  • Task deadline (configurable, up to 15 minutes)
  • Explicitly exiting the bootstrap process
    (due to error or otherwise)

Bootstrap (Cold start) phase

• Initialize runtime
• Prep function for execution
• Pass env vars including file/method for handler function
• If there's an error init-ing, make an API call
• Pro tip: do heavy work impacting shared state here

Task execution (warm start) Phase

• Call APIs to process work
• Next invocation (GET)
  • Request ID and more in headers
  • Task data in response body, JSON-encoded
• Invocation response (POST)
  • Request ID in URL
  • Response in body
  • Consuming services may require specific format
• Can perform (billed) cleanup between calling response
  endpoint and requesting the next invocation

Logging & Errors

• Invocation error (POST)
• STDOUT -> CloudWatch Logs
• Metrics available via CloudWatch (or in function UI)
• Lambda Telemetry API for more advanced metrics

Lambda supports Docker images now

• Slower to start
• Images can be up 10 GB total
• Still need to interact with the Lambda runtime API
  • AWS base images include the Lambda Runtime Interface Client
  • AWS provides Runtime Interface Clients for some languages
    • ...but not PHP...
    • ...so just use the bootstrap files we already have
• You can test with the Runtime Interface Emulator
• No function URL support

What might this look like from AWS's Side?

1. Are any workers for target function waiting on work?
2. If so, skip to step 3; if not...
   1. Build a new instance (container or layers + function code)
   2. Run /opt/bootstrap (or /var/task/bootstrap,
      or container entrypoint)
   3. Wait for it to do one of the following
      1. Return nonzero from the bootstrap (init failure)
      2. Call the init error API endpoint
      3. Call the task request API endpoint
3. Respond to the next invocation endpoint with event
4. Wait for API calls to invocation success/failure or timeout,
   whichever comes first

Example 1: email spongebot

1. SES rule pushes email to S3
2. S3 triggers Lambda
3. Lambda function executes...
   1. Grabs email from S3
   2. Parses using MIME parser
   3. RaNdOMlY CaPiTaLiZeS LEtTerS
   4. Sends email reply via SES

Example 2: Spongebot API

1. HTTP request hits API Gateway
2. Lambda function executes...
   1. Grabs query string parameter if there is one
   2. RaNdOMlY CaPiTaLiZeS LEtTerS
   3. Sends a JSON response
3. API Gateway turns the Lambda payload into an HTTP response

Example 3: Spongebot Via Function URL

1. HTTP request hits function URL
2. Lambda function executes...
   1. Grabs query string parameter if there is one
   2. RaNdOMlY CaPiTaLiZeS LEtTerS
   3. Sends a JSON response

Auth (if needed) can be done via AWS signatures

Example 4: SpongeBot via APi GW + Docker

...but you should probably use Bref in prod

...or Vapor, if you're using Laravel

Bonus: Example 2 (API Gateway) via Bref

Thanks! Questions?

• https://ian.im/lambmerge24 - this presentation
• https://github.com/iansltx/spongebot - sample code
• https://phpc.social/@ian - me
• https://twitter.com/iansltx - also me
• https://github.com/iansltx - my code