Operational Services
In the OMI ecosystem, Operational Services are the “Back Office” of your swarm. While the App Registry handles discovery and the Auth Provider handles the gates, Operational Services manage the consequences of your app’s existence: its history, its costs, and its health.
In a traditional “CRUD State of Mind,” you would manually instrument every service with specific SDKs for logging, billing, and monitoring. In OMI, these are delegated. Your Domain Services simply emit standardized events, and the swarm routes them to the Operational Services of your choice.
The “What”: The Swarm’s Nervous System
Operational Services are a pluggable category of core services that handle cross-swarm telemetry. Common examples include:
| Service | Role | Operational Responsibility |
|---|---|---|
| Logging Provider | The Archivist | Collects and indexes system events and errors across all services. |
| Billing/Usage Service | The Accountant | Tracks resource consumption or API calls to manage quotas and payments. |
| Audit Service | The Court Reporter | Maintains an immutable record of high-value actions (e.g., who changed a configuration). |
| Metrics Service | The Vitals Monitor | Aggregates performance data (latency, throughput) to ensure swarm health. |
The “Why”: Decoupling the “How” from the “Result”
Unified Telemetry (No More SDK Fatigue) Because OMI Domain Services follow a strict protocol, they don’t need to know how to talk to a specific logging vendor. They send a standardized OMI event. Whether that event ends up in a high-end enterprise dashboard or a simple flat file is entirely up to the Operational Service you’ve bound to the Registry.
Operational Sovereignty You are no longer locked into the “default” monitoring tools of your cloud provider. If you want a Billing Service that respects user privacy by only tracking aggregate usage, or a Logging Service that encrypts all data before it hits the disk, you just swap the pointer in the App Registry. Your Domain Services don’t need a single code change.
The “Black Box” Reporting Operational Services respect the Black Box nature of Domain Services. They don’t peer into the internal database architecture; they listen to the service’s heartbeat and its external interactions. This ensures that even your logs and billing data remain decoupled from the internal implementation of your features.
How It Works: The Injected Context
When a Domain Service handshakes with the App Registry, it receives the Operational Context. This is a list of endpoints where it is required to report its activity.
- Instruction: The Registry tells the CMS: “Send all logs to https://logs.provider.io and all billing receipts to https://billing.provider.io.”
- Execution: The CMS performs its function (e.g., updating a post).
- Emission: The CMS sends a signed “Event Packet” to the designated Operational Services.
- Verification: The Operational Service verifies the packet’s signature using the CMS’s Public Key (resolved from the Registry) to ensure the event is legitimate.