В дополнение по теме Serverless отмечу обязательное к просмотру видео Романа Бойко (Serverless Specialist Solutions Architect, AWS) с разбором подкапотной работы Лямбды:

https://www.youtube.com/watch?v=I0BWfDmGj0Q

Тот вариант видео, что нужно добавить в закладки и периодически пересматривать.

#Lambda

​​Lambda Function URL: 🎉

https://aws.amazon.com/blogs/aws/announcing-aws-lambda-function-urls-built-in-https-endpoints-for-single-function-microservices/

Each function URL is globally unique and can be associated with a function’s alias or the function’s unqualified ARN, which implicitly invokes the $LATEST version.

For example, if you map a function URL to your $LATEST version, each code update will be available immediately via the function URL.

Lambda Function URL vs. API Gateway

Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching.

Pricing

Function URLs are included in Lambda’s request and duration pricing. (So it's FREE!💪)

▪️ Rest API (first 333 mil) = $3.5
▪️ HTTP API (first 300 mil) = $1.0
▫️ Lambda URL = Free
▪️ CloudFront proxying to Lambda URL = ~ $1.0 to $1.2

Timeout (seconds)

▪️ Rest API = 29
▪️ HTTP API = 30
▫️ Lambda URL = 900
▪️ CloudFront proxying to Lambda URL = 60 (by default)

#Lambda

🆕 Lambda + Node.js 18.x: 🎉

https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/

🔹 Node.js 18 is now supported by Lambda. When building your Lambda functions using the zip archive packaging style, use a runtime parameter value of nodejs18.x to get started building with Node.js 18.
🔸 For existing Node.js functions, review your code for compatibility with Node.js 18, including deprecations, then migrate to the new runtime by changing the function’s runtime configuration to nodejs18.x.

#Lambda

🆕 Lambda SnapStart:

https://aws.amazon.com/blogs/aws/new-accelerate-your-lambda-functions-with-lambda-snapstart/

✻ Lambda SnapStart can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. The largest contributor to startup latency (often referred to as cold start time) is the time that Lambda spends initializing the function, which includes loading the function's code, starting the runtime, and initializing the function code.

✻ With SnapStart, Lambda initializes your function when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When you invoke the function version for the first time, and as the invocations scale up, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup latency.

⚠️ Important
➣ If your applications depend on uniqueness of state, you must evaluate your function code and verify that it is resilient to snapshot operations. For more information, see Handling uniqueness with Lambda SnapStart.

SnapStart supports:
✅ Java 11 runtime

SnapStart does not support:
❌ provisioned concurrency
❌ arm64
❌ Lambda Extensions
❌ EFS
❌ > 512 MB ephemeral storage

ℹ️ You can't use SnapStart on a function's unpublished version ($LATEST).

SnapStart vs Provisioned Concurrency

👉 Use Provisioned Concurrency if your application has strict cold start latency requirements.
👉 SnapStart helps you improve startup performance by up to 10x at no extra cost.
❗ You can't use both SnapStart and Provisioned Concurrency on the same function version.

#Lambda

🆕 Lambda + Python 3.10

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#w354aac23c27:~:text=Mar%2031%2C%202023-,Python%203.10,-python3.10

#Lambda

​​📙 AWS Lambda Container Architecture

https://arxiv.org/pdf/2305.13162.pdf

#Lambda

​​⚒️ lambda-debug is a tool that enables you to invoke Lambda functions in the cloud from any event source and intercept the requests with breakpoints locally.

https://github.com/ljacobsson/lambda-debug

🏠 Local debugging: Set breakpoints in your code and step through your functions invocations locally on native events triggered in the cloud.
👍 No code changes: No need to modify your code to enable debugging. Just add some dev dependencies and some configuration.
🔐 Same IAM permissions: Your functions will run with the same IAM permissions as they do in the cloud.
⚡ Fast iterations: No need to deploy your code to the cloud to test changes. Just save your code and invoke your functions in the cloud.

#Lambda

Lambda + Python 3.11

https://aws.amazon.com/blogs/compute/python-3-11-runtime-now-available-in-aws-lambda/

#Lambda

🆕 Lambda x12 faster scaling! 🚀

https://aws.amazon.com/blogs/aws/aws-lambda-functions-now-scale-12-times-faster-when-handling-high-volume-requests/

Lambda function now scales by 1,000 concurrent executions every 10 seconds until the aggregate concurrency across all functions reaches the account’s concurrency limit.

#Lambda

​​Lambda + Python 3.12

https://aws.amazon.com/blogs/compute/python-3-12-runtime-now-available-in-aws-lambda/

#Lambda

Добрая пятничная история

Пару недель назад AWS выкатил поддержку CloudFront OAC для Lambda function URLs, чтобы можно было удобно ходить в приватные Лямбды.

Сначала все обрадовались, полезное дело, безопасности, все дела, но после выяснилось, что работают лишь GET запросы, а на POST/PUT отдаётся ошибка.

Потом все расстроились, потому что зря обрадовались — ведь это не фича, а баг.

Но один хороший человек упоролся и выяснил, что если посчитать SHA256 хэш и добавить его в заголовок x-amz-content-sha256, то и POST/PUT тоже работают.

https://twitter.com/rooToTheZ/status/1788606025265975505

Он написал запрос на обновление AWS документации для CloudFront и теперь там:

ℹ️ Note
If you use PUT or POST methods with your Lambda function URL, your user must provide a signed payload to CloudFront. Lambda doesn't support unsigned payloads.

В итоге расстроились и те, кто обрадовался, когда другие расстроились, потому что рано обрадовались.

Какая же здесь мораль? Документация — важна. Грамотно задокументированный баг всегда можно сделать фичей.

#CloudFront #Lambda