datadog-agent VS lambda-architecture-bug

It's worse than that, they want security through obscurity too. They feel like someone is inappropriately tinkering with the agent they want customers to install. It's open source: https://github.com/DataDog/datadog-agent ...but the downloads are behind a login: https://github.com/DataDog/datadog-agent#datadog-agent

Serverless developers have the benefit of cloud providers deploying new features which improve our experience and reduce costs. Recently AWS introduced Graviton for Lambda, which leverages their custom ARM-based processor. Using Graviton, AWS says that users can see 19% better performance at 20% lower cost - and many users wouldn't even have to change any of their code at all! At my day job at DataDog, we quickly rolled out ARM-compatible versions of the DataDog Extension and our IaC integrations like the Serverless Plugin and the CDK Construct.

The package is at https://github.com/DataDog/datadog-agent/tree/6.37.1 and it seems to relay on downloads rather than vendored packages (https://github.com/DataDog/datadog-agent/blob/6.37.1/go.mod)

The worse is when many are intermixed, and usually glued together in unconventional ways. Like https://github.com/DataDog/datadog-agent where there's a go, c++, and python build.

At this point I had a hunch that this wasn't a bug per-se, rather a sharp edge around CloudFormation and the Lambda control plane. I decided to try to reproduce this issue with the Serverless Framework. It also relies on CloudFormation, but generates different CloudFormation templates, and would rule out the existence of a bug in the CDK construct. I created a demo project and was able to reproduce this immediately.