|
| 1 | +# Lambda Testing scenario |
| 2 | + |
| 3 | +The Lambda scenario is a variation on the [classical architecture](../architecture/overview.md#what-are-the-components-of-a-running-test) of the system-tests tailored to evaluate the `AWS Lambda` variants of the tracers when used to serve HTTP requests. |
| 4 | + |
| 5 | +To achieve this we simulate the following AWS deployment architecture inside the system-tests using AWS provided tools : |
| 6 | + |
| 7 | +```mermaid |
| 8 | +graph LR |
| 9 | + A[Incoming HTTP Request] -->|HTTP| B[AWS Managed Load Balancer] |
| 10 | + B -->|event: request as JSON| C[AWS Lambda] |
| 11 | +``` |
| 12 | + |
| 13 | +The AWS Managed Load Balancer could be any of the following ones: |
| 14 | +- API Gateway |
| 15 | +- Application Load Balancer |
| 16 | +- Lambda function url service |
| 17 | + |
| 18 | +To do this, we rely on two tools from AWS to emulate Lambda and Load Balancers: |
| 19 | +- [AWS Lambda Runtime Interface Emulator](https://github.com/aws/aws-lambda-runtime-interface-emulator) |
| 20 | +- [AWS SAM cli](https://github.com/aws/aws-sam-cli) |
| 21 | + |
| 22 | +>Note: for now only the python variant ([`datadog_lambda`](https://github.com/DataDog/datadog-lambda-python)) is being tested simulating an `API Gateway` |
| 23 | +
|
| 24 | +## Key differences with end to end scenarios |
| 25 | + |
| 26 | +To replace the **AWS Managed Load Balancer**, we run a dedicated container in front of the weblog named **Lambda Proxy**. It is responsible for converting the incoming request to a *lambda event* representation, invoking the lambda function running inside the weblog and converting back the return value of function to an http response. |
| 27 | + |
| 28 | +The **Lambda Function** runs inside the **Weblog Container** thanks to the *AWS Lambda Runtime Interface Emumlator*. |
| 29 | + |
| 30 | + |
| 31 | +There is no **Agent Container**, the **Datadog Extension** (equivalent to the **Datadog Agent** in the context of lambda) needs to run inside the **Weblog Container**, the [**Application Proxy Container**](../architecture/overview.md#application-proxy-container) therefore needs to send traces back to the **Weblog Container**. |
| 32 | + |
| 33 | + |
| 34 | +```mermaid |
| 35 | +flowchart TD |
| 36 | + TESTS[Tests Container] -->|Send Requests| LambdaProxy |
| 37 | + LambdaProxy[Lambda Proxy] -->|Send Lambda Event| Application |
| 38 | + subgraph APP[Application Container] |
| 39 | + Extension[Extension *:8126] |
| 40 | + Application[Application *:8080] |
| 41 | + end |
| 42 | + Application --> | Send Traces | APPPROXY |
| 43 | + APPPROXY[Application Proxy] --> | Send back traces | Extension |
| 44 | + APPPROXY -->|mitmdump| TESTS |
| 45 | + Extension --> AGENTPROXY |
| 46 | + AGENTPROXY[Agent Proxy] -->|remote request| BACKEND |
| 47 | + AGENTPROXY -->|mitmdump| TESTS |
| 48 | + BACKEND[Datadog] -->|trace API| TESTS |
| 49 | +``` |
0 commit comments