Without having thought much about this, surely datadog only want to store your data and have you pay for the storage/indexing/querying? I guess your worry is something like datadog making themselves the only possible backend? I don’t feel like that’s a very big risk – I think trying it would just lead to a fork of vector. Perhaps a more realistic risk is that vector would implicitly assume datadog’s constraints, eg (making these up without knowing much about datadog) field types or required information or the expected number of unique fields across all messages.
Yeah the trick is if they can lock you into a stack that sits everywhere in your apps, it’s very expensive to switch vendors, letting them extract high rents. This is what happened with the Datadog agents.
In that context, OTEL is an existential threat, because it makes them a commodity. Then it becomes relatively clear why they wouldn’t put OTEL support in the Vector roadmap.
I guess I’m surprised that your claim is basically that datadog’s advantage is in ingestion. I would have assumed they would be focusing on trying to make a product so good that people wouldn’t want to switch from it. Vector supporting multiple backends would be good for datadog if it can get more people in the door, so long as their product is compelling enough for people to stay.
I don’t know what exactly you mean about otel but elsewhere in this comments section someone linked to upscale, which uses vector to collect otel logs. Is that a counterexample?
My experience with using Datadog at (some) scale was that they focused on making it really, really easy to integrate their agent with your apps, and then once they had a large base of users with high switching costs they started rapidly raising prices.
In other words: My claim isn’t that they were better at ingestion but at onboarding and at creating switching costs.
Since that was how their leadership acted last time I used their code, I expect the same leadership to act the same way again with this other piece of code they own.
