datadogpy VS datadog-agent

Ideally, if we had access to the underlying infrastructure, we could probably install the Datadog Agent and configure it to send our logs directly to Datadog, or even use AWS Lambda functions or Azure Event Hub + Azure Functions in case we were facing some specific cloud scenarios.

- DD_ENV=CI DATADOG_API_KEY=$DATADOG_API_KEY DATADOG_SITE=datadoghq.com datadog-ci junit upload --service system cypress/results/combined.xml

> DataDog's libraries don't seem to be OSS: https://github.com/DataDog/datadogpy/blob/master/LICENSE

Is that not a verbatim the 3-clause BSD license?

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.