Alessandro Bologna

Yes I remember that, but if recall correctly your findings, not having it will make it even more likely that we would end up in the suppressed init scenario (with the throttled cpu) more often, because it won’t have enough cpu to stay in the 10s the first time no?

I wonder what will happen of the other “freebie”, the unthrottled cpu during init, if that is not valid anymore we will see longer cold starts I am afraid.

Screenshot showing the GitHub account opening 323+ similar issues in other repositories

Looks like the account that has opened the issue (probably taken over in the same way) has been busy opening just a few of them…

A better way to handle stacks composition than what CF offers (nested stacks, modules, macros, includes etc), even if client side a la CDK would be great. Just an idea… 🙂

Italiano 🇮🇹:

Impara a creare interazioni affascinanti e tocchi deliziosi usando la magia di CSS, JavaScript, SVG e Canvas

So yeah "otel is hard" but mostly when what you're looking for is a drop in replacement for prometheus or an expensive vendor solution.

Like with anything new, workout how you can leverage it and how it helps you. Don't throw it out because you don't understand it.

It may be controversial, but I have a rule: “If you can’t do math on it, it’s a string”. Helps with things like phone numbers, ZIP codes, and IDs… and spares you the horror of bugs where leading zeros mysteriously vanish. 🙂

Yes, I think I am very much aligned on this thinking, and it’s true that often are the other costs (clouwatch logs I am looking at you…) that bite more. I know about what vercel has done, but I didn’t know about Binaris? What is it?

right, and I was wondering how much this overhead really costs anymore, with firecracker and all the other things that have been built in the last 10 years of lambda.

When I read “oh well that’s expensive to run on lambda, so I will use a bunch of ec2 (or containers) at 30% utilization” I wonder for who it’s better to allocate those resources inefficiently. It seems it is for the customer, because of how pricing is structured, but does it need to be this way?

Absolutely, and I 100% agree. I absolutely love it. But what I was questioning wasn’t if it’s better for me (it is), what I was wondering was: if it is better for the cloud provider as well (and I suspect it is), why not incentivizing its use more, by reducing its cost?

Which does beg the question of why does lambda compute have to cost more per unit of work, however you define it. I may be wrong, but I would think that, from a cloud provider point of view, it is actually more efficient at resources and energy utilization, so is it just because of the convenience?

DSQL was written in rust.

Also, this made me smile, I was wondering throughout it “how did they build it?”

I finally had the time to watch this amazing session on DSQL, but also on how to architect and build distributed systems that scale. It’s really impressive, and humbling to see how much complexity can be behind something that I am sure I will use for my silly projects. Kudos to the team behind it.

Yes, tail based sampling seems to be the answer to the volume/cost problem. It also seems (didn’t try it yet myself) to be non trivial to self manage within your own infrastructure, but hey. Gotta try to tell for sure.

Good to know! Btw I meant *semconv above, got autocorrected in transit...
So, in a greenfield scenario, say a new app using otel, could one just add tracing (and forgo logs and metrics) and pick a platform that knows how to slice and dice, extract and aggregate, and query and visualize everything?

Screenshot of AWS price calculator for 100GB of standard logs

Absolutely true. Retention/storage is never the main concern. 100GB of standard logs is $50 for ingestion, $0.45/month for storage. You would need the keep those logs for 9 years to pay the same for storage. 🤷🏻

I think this is inspiring: wide structured logs as the single source of truth, with no limits on the cardinality of attributes. And then I wonder, could one just emit opentelemetry spans/traces, as OTLP records, with all the possible attributes (dem inv and not)? Or am I missing something?

I hacked together a js animation which displays Bluesky firehose in a Matrix style rain: simone.computer/bluerain/
ugly source code available here: github.com/syxanash/blu...
@pfrazee.com 👀

It may have to do with historical reasons, and backward compatibility: the fanout ESM came much later and likely implemented that from the get go. I can see how that could possibly break things otherwise.

I didn’t even know that enhanced fanout would do that, I assumed you had to do the de-aggregation yourself as usual. So it does it do it for event filters and also invokes the lambda with the records already de-aggregated?

GitHub - cargo-lambda/new-functions-template Contribute to cargo-lambda/new-functions-template development by creating an account on GitHub.

No, I love cargo lambda, but it's to build and deploy the code, it's not a client runtime for your code, as far i know. When you create a function with `cargo lambda new` it will build a boilerplate that depends on lambda_runtime: github.com/cargo-lambda...

I agree, but it makes it a little harder in corporate enterprise-y environments to say “we should go with rust for lambda”. You need to advocate a lot more.

GitHub - awslabs/aws-lambda-rust-runtime: A Rust runtime for AWS Lambda A Rust runtime for AWS Lambda. Contribute to awslabs/aws-lambda-rust-runtime development by creating an account on GitHub.

Awesome, I hope that it means that AWS is investing more on supporting the rust lambda runtime client, maybe making it non “experimental”. github.com/awslabs/aws-...

GitHub - dev7a/lambda-otlp-forwarder: Forwards OTLP records serialized to cloudwatch logs to an Open Telemetry collector Forwards OTLP records serialized to cloudwatch logs to an Open Telemetry collector - dev7a/lambda-otlp-forwarder

Slightly related, I have started a side project/experiment (very alpha at this point) to explore ways to make lambda play better with o11y and think it’s promising: github.com/dev7a/lambda...

Yes, completely agree. OTEL is the common language for observability, and this is a step in the right direction for serverless on AWS.

Not having to start the sidecar collector makes cold starts a little faster. Also by default they only enable the minimal instruments. So it’s definitely an improvement.

technically you don’t need a layer if you are doing manual instrumentation. What AWS did here was to remove the layer extension collector, add a UDP OTLP exporter lib to send traces to the local xray endpoint, and use the layer to instrument the lambda before it starts.

There’s also apparently a regular https endpoint but it’s not clear what type of auth it would require, maybe sigV4?

docs.aws.amazon.com/AmazonCloudW...

At least for lambda, the provided layer seems to do that. It kind of makes sense since there’s an xray UDP endpoint for lambda.