Runtimes in details

AWS Lambda layers

Bref runtimes are distributed as AWS Lambda layers (opens in a new tab). While Bref provides a Serverless plugin to simplify how to use them, you can use the layers directly.

The layer names (aka "ARN (opens in a new tab)") follow this pattern:

arn:aws:lambda:<region>:534081306603:layer:<layer-name>:<layer-version>

For example:

arn:aws:lambda:us-east-1:534081306603:layer:php-80:21

You can use layers via their full ARN, for example in serverless.yml:

service: app
provider:
    name: aws
functions:
    hello:
        # ...
        runtime: provided.al2
        layers:
            - 'arn:aws:lambda:us-east-1:534081306603:layer:php-80:21'

Or if you are using SAM's template.yaml (opens in a new tab):

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
    Hello:
        Type: AWS::Serverless::Function
        Properties:
            # ...
            Runtime: provided.al2
            Layers:
                - 'arn:aws:lambda:us-east-1:534081306603:layer:php-80:21'

Bref layers work with AWS Lambda regardless of the tool you use to deploy your application: Serverless, SAM, CloudFormation, Terraform, AWS CDK, etc.

Layer versions

All the layer/runtime versions can be found at runtimes.bref.sh (opens in a new tab).

Here are the latest versions:

You can also find the appropriate ARN/version for your current Bref version by running:

serverless bref:layers

Layers NPM package

You can use the @bref.sh/layers.js NPM package (opens in a new tab) to get up-to-date layer ARNs in Node applications, for example with the AWS CDK.

Telemetry ping

Bref layers send an anonymous ping to estimate the total number of Lambda invocations powered by Bref. That statistic is useful in two ways:

• to provide new users an idea on how much Bref is used in production
• to communicate to AWS how much Bref is used and push for better PHP integration with AWS Lambda tooling

We consider this to be beneficial both to the Bref project (to get more users and more consideration from AWS) and for Bref users (more users means a larger community, a stronger and more active project, as well as more features from AWS).

So far, knowing the number of Bref invocations has helped Bref grow, be recognized by AWS, and opened a lot of doors.

Data

On the month of the Bref 1.0 release, Bref was powering 1 billion invocations per month.

On the month of the Bref 2.0 release, Bref was powering 10 billion invocations per month.

What is sent

The data sent in the ping is completely anonymous. It does not contain any identifiable data about anything (the project, users, etc.).

The only data it contains is: "A Bref invocation happened with the layer XYZ" (where XYZ is the name of the Bref layer, like "function", "fpm" or "console").

Here is an example payload:

Invocations_100:1|c\nLayer_fpm_100:1|c

Anyone can inspect the code and the data sent by checking the Bref\Runtime\LambdaRuntime::ping() function (opens in a new tab).

How is it sent

The data is sent via the statsd (opens in a new tab) protocol, over UDP (opens in a new tab).

Unlike TCP, UDP does not check that the message correctly arrived to the server. It doesn't even establish a connection. That means that UDP is extremely fast: the data is sent over the network and the code moves on to the next line. When actually sending data, the overhead of that ping takes about 150 micro-seconds.

However, this function actually sends data every 100 invocation, because we don't need to measure all invocations. We only need an approximation. That means that 99% of the time, no data is sent, and the function takes 30 micro-seconds. If we average all executions, the overhead of that ping is about 31 micro-seconds.

Given that it is much much less than even 1 milli-second, we consider that overhead negligible.

Disabling

The ping can be disabled by setting a BREF_PING_DISABLE environment variable to 1.