Skip to main content

Portfolio Strategy

Purpose: For platform engineers and leadership, explains why openCenter builds managed data services and the sequencing strategy.

Why Managed Data Services​

openCenter already delivers secure, production-ready Kubernetes with GitOps lifecycle management, SOPS-based secrets, air-gap support, and a hardened platform services stack. Managed data services extend that foundation into stateful workloads that application teams need but do not want to assemble and operate themselves.

The strategy is not to become a broad database-as-a-service vendor. It is to build a repeatable blueprint business where each service is narrow, opinionated, and supportable within openCenter's engineering and SRE capacity.

Blueprint Model​

Every data service is delivered as a versioned blueprint — a tested combination of operator, topology, security controls, observability, and operational procedures. Blueprints are:

  • Declarative — defined as Kubernetes CRDs managed through GitOps
  • Opinionated — limited topology choices, standardized storage profiles, fixed auth models
  • Versioned — pinned to tested operator and application versions
  • Air-gap compatible — all images mirrored through Harbor, no runtime internet dependencies
  • Support-bounded — openCenter owns the platform; customers own application semantics

This model trades flexibility for repeatability. A customer cannot request arbitrary Kafka topologies or custom PostgreSQL extensions in the base blueprint. That constraint is what makes the service supportable.

Sequencing: What Ships When​

The portfolio follows a deliberate sequence defined in ADR-004:

QuarterMilestone
Q1GA: openCenter Managed Kafka
Q2Preview: openCenter Managed PostgreSQL; harden Kafka operations
Q3GA: openCenter Managed PostgreSQL
Q4GA: Schema Registry / Event Governance (Kafka add-on)
Q5GA: Narrow CDC add-on (Debezium, PostgreSQL-first)

Kafka goes first because it maps cleanly to the blueprint model: declarative operator lifecycle, standardized topology, strong observability, clear security controls, and repeatable deployment patterns. PostgreSQL follows because it has high demand but carries higher support expectations around backup/restore, HA semantics, and DBA-adjacent tasks.

What Is In Scope​

Launch (first five quarters):

  • openCenter Managed Kafka — event backbone, async messaging, decoupled integration
  • openCenter Managed PostgreSQL — standard transactional database
  • Schema Registry — contract management and schema compatibility (Kafka add-on)
  • Narrow CDC — Debezium-based change data capture, PostgreSQL source first

Deferred:

  • Redis / cache services
  • Stream processing (Flink, ksqlDB)

Excluded:

  • Object storage / data lake infrastructure
  • Generic workflow / integration platform
  • Search / analytics engines (Elasticsearch, OpenSearch)
  • Kafka Connect as a general-purpose connector platform

Why These Tradeoffs​

openCenter's strengths favor declarative operators, reusable topology patterns, controlled upgrades, strong security defaults, offline packaging, and defined support boundaries. Those same strengths work against platforms that require frequent custom connector work, workload-specific tuning, hardware-dependent storage, or unlimited flexibility.

Each service in the portfolio must pass these gates before launch:

  1. Can it be expressed as a versioned, supportable blueprint with limited topology choices?
  2. Does it have clear runbooks, SLOs, and incident procedures?
  3. Is the support boundary between platform and application explicit?
  4. Can it be patched and upgraded offline with confidence?
  5. Does it have validated demand from design partners?

If a service cannot satisfy all five, it does not ship.

Commercial Model​

Data services are packaged as blueprint + onboarding + day-2 managed operations. Three tiers:

TierFitSupport
FoundationNon-prod, internal platform adopters8×5, limited topology, no DR
EnterpriseProduction workloads24×7, HA, standard RCA/change/capacity
RegulatedPublic sector, financial, healthcare, air-gap24×7 + evidence/change control/segregation

Add-ons (DR replication, schema governance, CDC) are priced separately. Professional services cover application integration design, topic modeling workshops, and migration from legacy messaging.

Shared Responsibility​

The managed data services model fails commercially when platform teams absorb application ownership. The boundary:

  • openCenter owns: service deployment, broker/operator health, monitoring, certificate rotation, patching, upgrades
  • Customer owns: application logic, event semantics, producer/consumer code, topic design, retention decisions, data classification
  • Shared: capacity planning, DR objectives, security usage patterns, upgrade scheduling approval

This boundary is documented in support agreements and enforced through runbook scope.

Further Reading​