Portal Community
BizFirst Observe

Avoiding Vendor Lock-In

BizFirstGO's observability design uses OpenTelemetry (an open standard) and the OTel Collector (a vendor-neutral pipeline) to maximize portability. Following a few additional practices ensures you can switch providers without rewriting dashboards or changing service code.

Lock-In Risk Assessment by Component

ComponentLock-In RiskMitigation
BizFirstGO service codeNone — uses OTel SDK standard APIsAlready portable: change endpoint env var, done
OTel Collector config (receivers + processors)None — standard across all providersAlready portable: only exporters section changes
Grafana dashboards (if using LogQL/PromQL)Low — works on any Grafana or Grafana CloudKeep dashboards as JSON in git; avoid Grafana Enterprise-only features in dashboard JSON
Alert rules (Grafana native)Low — Grafana alert rule format is portableKeep alert rules in provisioning YAML in git
Dashboards (if using KQL, Datadog, CloudWatch Insights)High — proprietary query languageAvoid: stick to LogQL/PromQL/TraceQL
Historical log data in LokiMedium — TSDB/Loki format not portableExport to NDJSON before migration; not practical at scale

Anti-Patterns That Create Lock-In

# AVOID these practices that create observability vendor lock-in:

1. Writing LogQL queries directly in BizFirstGO service code:
   # BAD: Hardcoded Loki query in application code
   var lokiQuery = "{job=\"processengine\"} | json | executionId = \"" + id + "\"";
   # GOOD: Use OpenTelemetry trace correlation IDs instead

2. Using Datadog SDK directly in BizFirstGO code:
   # BAD: import DatadogTracing; (Datadog-specific SDK)
   # GOOD: import OpenTelemetry; (provider-neutral)

3. Building dashboards with CloudWatch Insights or KQL queries:
   # BAD: Dashboard uses AWS CloudWatch Insights query language
   # GOOD: Use Amazon Managed Prometheus (PromQL) for metrics dashboards

4. Storing observability config in provider-specific formats:
   # BAD: Datadog dashboard JSON stored in git
   # GOOD: Grafana dashboard JSON stored in git (portable to Grafana Cloud)

Portable Observability Practices

# FOLLOW these practices for maximum portability:

1. Use OTel SDK (not vendor SDKs) in all BizFirstGO services
   # Already done — ObservabilityServiceExtensions.cs uses OpenTelemetry packages

2. Use OTel Collector as the single point of provider configuration
   # Change exporters section to switch providers

3. Use LogQL for all log dashboards (works on self-hosted Loki + Grafana Cloud)

4. Use PromQL for all metric dashboards (works on self-hosted Prometheus + AMP + Grafana Cloud)

5. Keep all dashboard JSON, alert rules, and OTel Collector config in git
   # Full disaster recovery: git clone + docker compose up = restored in 30 minutes

6. Use OTel standard attribute names (not vendor-specific):
   # Good: service.name, span.tenant.id, http.status_code
   # Avoid: datadog.span.type, aws.xray.segment.id
The OTel SDK Is Your Most Important Lock-In Protection

BizFirstGO's use of the OpenTelemetry SDK in all services is the primary source of portability. The OTel SDK emits OTLP — a format accepted by every major observability provider. As long as BizFirstGO services emit OTLP, switching providers is an infrastructure change (OTel Collector config + Grafana data sources) not a development project.

← Cost Comparison Next Guide: TEE Observability →