Infrastructure Strategy
When the Enterprise Standard Is Not the Lowest-Risk Architecture
An architecture decision story about PostgreSQL for Ansible Automation Platform on OpenShift, and why operational ownership sometimes mattered more than centralization.
Some architecture decisions look simple in a diagram and complicated in real life.
This one was about PostgreSQL for a Red Hat Ansible Automation Platform deployment running on OpenShift. The question was narrow on paper: should the database live inside the platform-aligned deployment boundary, or should AAP consume PostgreSQL from a centralized enterprise database service?
That question was never just about PostgreSQL. It was about ownership, recovery, operating maturity, and how much reality an architecture diagram is allowed to hide.
The Decision
The system boundary looked ordinary: automation clients would call Ansible Automation Platform, and AAP would persist state in PostgreSQL. The debate was whether PostgreSQL should be operated with the OpenShift-hosted AAP deployment, close to the team responsible for the application, or consumed from a separate enterprise PostgreSQL platform operated as a shared service.
Both options were defensible.
The centralized database option had the stronger enterprise story at first glance. It aligned with shared-service direction, database specialization, central backup standards, patching discipline, governance, and separation of duties. Those are real architecture benefits. A serious architecture review should give that position its strongest argument.
The application-aligned option had the stronger operations story in the environment as it actually existed. The team responsible for AAP understood the vendor-aligned deployment pattern, could see the full stack, and had a clearer path to restore service if something failed.
The decision was to favor the application-aligned PostgreSQL architecture.
Two Architectures
The two diagrams below are deliberately close to how the debate felt. One keeps most of the operational surface inside a compact platform boundary. The other moves the database into a separate operational domain and makes the connecting tissue visible.
Architecture A
Application-aligned PostgreSQL
PostgreSQL stays inside the OpenShift-hosted application boundary with the AAP deployment and its local platform dependencies.
Architecture B
External enterprise PostgreSQL
AAP runs on OpenShift while PostgreSQL is consumed from a centralized database platform in a separate operational domain.
Why the External Database Looked Better on Paper
The external PostgreSQL architecture had a legitimate case.
Centralized database platforms can provide specialized administration, repeatable backup standards, standardized patching, high-availability patterns, disaster recovery procedures, access governance, database-specific monitoring, and a cleaner separation of duties.
Those are not ceremonial benefits. In a mature environment, they reduce variance. They keep application teams from each inventing their own database operating model. They let database specialists own database concerns instead of asking every platform team to become a database team.
If the enterprise PostgreSQL service had been boring, fast to consume, well documented, observable, and proven under failure, it likely would have been the preferred architecture.
That was the key conditional.
Why I Chose Differently
The organization had spent years trying to mature PostgreSQL into a dependable shared service. That direction was reasonable, but the current capability still carried friction. Onboarding could be slow. Provisioning and integration were not yet as self-service as the target state required. Shared infrastructure dependencies had caused operational problems in other systems.
The operations team responsible for AAP preferred the packaged, vendor-aligned deployment model for practical reasons. They understood it. They knew where to look when it failed. They had direct visibility into the application, platform resources, storage relationships, logs, and recovery actions.
That mattered because the team paged for an AAP failure needed meaningful control over the components required to restore AAP. This is not an absolute rule. It is a useful architecture heuristic: the farther recovery moves from the team accountable for the service, the more carefully that distance has to be justified.
The external database option introduced more than a database endpoint. It introduced network paths, firewall rules, certificates, DNS records, identity integration, provisioning queues, separate maintenance windows, handoff points, support escalation, and cross-team incident coordination.
None of those made the shared-service architecture bad. They made it larger.
The Hidden Architecture
The simplest logical diagram said:
AAP -> PostgreSQLThat arrow was doing too much work.
Expanded arrow
- AAP runtime the application path users see
- DNS name resolution, endpoint changes, cache behavior
- Network routing paths, reachability, latency, segmentation
- Firewall policy approval, drift, change windows, troubleshooting
- Certificates trust chains, renewal, expiry, client configuration
- Identity and secrets credentials, rotation, authorization boundaries
- Database operations patching, maintenance, backup, restore, DR
- Another operating team handoffs, escalation, queue time, incident coordination
A dependency is not free because a diagram represents it with one arrow. The real system includes the arrow, the people who own each segment of the arrow, and the process required to recover when any segment breaks.
That is why “enterprise” could not be treated as a synonym for “lowest risk.” Centralization is not maturity. Decentralization is not immaturity. Vendor alignment is not a substitute for architecture. The decision had to account for the actual operating characteristics of the dependency, not the label attached to it.
The Principle
Operational ownership is an architectural property.
So are organizational boundaries, recovery paths, provisioning friction, observability, support quality, and the number of teams required to resolve an incident. They shape the system even when they are absent from the logical diagram.
The architecture that looks cleaner on a slide can be more complicated at 2:00 a.m. The architecture that looks less centralized can be easier to understand, operate, and recover.
The right question was not “Kubernetes database or external database?” It was “which dependency model produces the most supportable AAP service in this organization right now?”
What Would Change the Decision?
The external enterprise PostgreSQL architecture would become more attractive as the shared service became more operationally boring.
That would mean self-service or predictable provisioning, clear service-level expectations, proven availability, tested recovery, automated certificate lifecycle, standardized connectivity patterns, strong observability, documented disaster recovery, responsive support, and clear ownership during incidents.
At that point, the architecture equation changes. A mature shared service can reduce operational risk because it removes database burden from the application team without replacing it with slow handoffs or unclear recovery paths.
That is the standard enterprise platforms should aim for: not merely centralized, but dependable enough that consuming teams can stop thinking about them.
Retrospective
The decision irritated some people because it appeared to reject an enterprise standard. That was not the intent. The intent was to distinguish where the organization wanted to be from what it could safely operate at the time.
Architecture leadership has to hold both thoughts. It should help move the organization toward mature shared platforms. It should also refuse to make every application pretend the target state already exists.
The diagram is larger than the boxes. Sometimes the most responsible architecture decision is the one that admits that.