Saw the announcement. Another "strategic partnership" that reads like a vendor lock-in roadmap. They're rebranding their managed service to run exclusively on that cloud's infra.
If you're already using their OSS distribution, this doesn't change much today. But the roadmap is clear: new "premium" features will be cloud-specific. Their APM agent will start optimizing for that cloud's proprietary telemetry backend. Suddenly, your SLO dashboards have dependencies on three services you don't control.
Teams considering this: are your SLOs and incident response procedures ready to be hostage to one vendor's pricing and availability? The promised "deeper integration" usually means you can't run it anywhere else.
—dw
Trust but verify.
Yeah, that's a big worry. The part about your SLO dashboards suddenly having "dependencies on three services you don't control" really hit home. I've seen that play out before with other tools, and it makes post-incident reviews a nightmare when you can't even get the data you need.
From a project management view, how do you even plan for that risk? Our team loves their open-source version, but if all the new features go cloud-native, our future roadmap is basically tied to theirs. Feels like we lose our negotiating power.
What would you recommend for teams just starting with them now? Is it already too late to avoid the lock-in, or can you still set things up in a portable way?
You're right about the dependency creep. I've seen this exact pattern play out with three other "platform partners" in the last five years. The initial integration is always a managed service on their infra, which seems convenient.
The real strategic move comes 12-18 months later, when the next major version of their APM or security modules require a proprietary cloud service (like a specific queue or blob store) that simply doesn't exist elsewhere. Your choice then is to accept the architectural lock-in or fork the OSS version and backport features yourself, which becomes a full-time engineering job.
Your point on SLO dashboards is critical - it's not just about vendor pricing. It's about diagnostic integrity during a major incident. If your observability toolchain's availability is now tied to the same provider's regional outage that's taking down your app, you're flying blind. That's an unacceptable operational risk we refuse to accept for any client's core telemetry.
Mike
Totally feel that. It's the "premium features will be cloud-specific" part that echoes every other partnership playbook. I've been testing the OSS build against the new managed one, and the delta is already there: the new alerting modules silently require that cloud's specific message queue. You can't even export the schemas to run it yourself.
My caveat is that this sometimes forces a healthy architecture review. If you're using their OSS version, now's the time to explicitly wrap their client libraries and push all telemetry through your own abstraction layer. It's a pain, but it keeps your SLO dashboards fed from a source you control if you need to switch the backend later.
We did this with a previous tool, and it let us migrate over six months instead of being stuck in a panic. Still, it's extra work that shouldn't be necessary.
Automate all the things.