Data Services Blueprints
Purpose: For platform engineers and app developers, explains the Data Services family — how individual data tools become a cohesive platform layer with shared principles, operations, and lifecycle management.
Overview
Individual data tools are easy to install and hard to operate. The Data Services family treats them as a cohesive layer of the platform with shared principles: versioned blueprints, operator-managed lifecycle, GitOps delivery, security by default, and air-gap readiness.
Each data service is deployed via openCenter-gitops-base and managed through FluxCD like any other platform service. Customers declare intent via CRDs in Git; operators handle provisioning, scaling, backup, and upgrades.
Strategy Principles
| # | Principle | Meaning |
|---|---|---|
| 1 | Blueprint repeatability | Versioned, supportable blueprints with limited topology choices |
| 2 | Day-2 operability | Clear runbooks over feature breadth |
| 3 | Security by default | TLS, auth, secrets handling, image provenance, and policy controls built in |
| 4 | Air-gap viability | Mirrorable, patchable, and operable without live internet |
| 5 | Operator maturity | No fragile operators or unstable APIs — production-ready only |
| 6 | Shared responsibility | openCenter owns platform/operations; customers own app behavior/data |
| 7 | Limited optionality | Standardized topologies, plans, access patterns, maintenance models |
| 8 | Commercial clarity | Attachable day-2 revenue and clear support boundaries |
Domain Roadmap
| Domain | Status | Timeline | Description |
|---|---|---|---|
| Streaming | Limited Availability | Now | Apache Kafka with Strimzi operator — clusters, topics, users, ACLs, Connect, MirrorMaker 2 |
| Databases | Preview | Q2–Q3 2026 | Managed PostgreSQL — operator-backed lifecycle with backup, restore, failover, upgrade |
| Schema Registry | Planned | Q4 2026 | Schema versioning and compatibility enforcement as a Kafka add-on |
| Change Data Capture | Planned | Q1 2027 | Debezium-based CDC for PostgreSQL-first patterns via KafkaConnect |
Streaming (Limited Availability)
Apache Kafka managed by the Strimzi operator. First limited-availability product. Multi-broker clusters with KRaft mode, inter-broker TLS, SASL authentication, topic-level ACLs, and full observability (Prometheus exporters, Grafana dashboards, alerting rules). Kafka Connect and MirrorMaker 2 for integration and replication.
See: Streaming Blueprint
Databases (Preview — Q2–Q3 2026)
Managed PostgreSQL with operator-backed lifecycle management. Automated backup (scheduled base + continuous WAL + point-in-time recovery), failover, rolling upgrades, and connection pooling. Operator selection between CloudNativePG and Zalando postgres-operator.
See: PostgreSQL (Planned)
Schema Registry (Planned — Q4 2026)
Schema versioning and compatibility enforcement (Backward, Forward, Full, None) for Avro, Protobuf, and JSON Schema formats. Deployed as a Kafka add-on in the data-kafka namespace. Prevents breaking schema changes from propagating through streaming pipelines.
See: Schema Registry (Planned)
Change Data Capture (Planned — Q1 2027)
Debezium-based CDC for PostgreSQL (pgoutput), MySQL (binlog), and MongoDB (change streams). Deployed as KafkaConnect connectors managed via KafkaConnector CRDs. Requires both Kafka (streaming) and PostgreSQL (databases) services to be operational.
See: CDC (Planned)
Further Reading
- Portfolio Strategy — sequencing rationale and commercial model
- Kafka Architecture — technical architecture and CRDs
- Naming Standards — naming conventions for data services