The First Fortnight
A handful of decisions made in an OpenShift platform's first two weeks set its cost for the next five years. Here is how to make them, and how to make them reviewable.
Most of the cost of an enterprise container platform is committed before the first workload ever runs. Not spent — committed. The zone model, the network topology, the certificate strategy, the failure domain boundaries and the naming scheme are usually settled in the platform’s first fortnight, often by whoever was in the room, and rarely revisited because revisiting them means re-cutting subnets, re-issuing trust chains or renaming objects that hundreds of manifests now reference. Enough five-year-old platforms have crossed our desks to know which early choices age well and which quietly tax every release for the life of the estate.
This is not an argument for slowing down. It is an argument for treating five specific decisions as architecture, not defaults, and for writing them down in a form an architecture board can actually review before they harden into concrete.
The zone model is a security boundary, not a folder structure
Most platforms end up with some variant of ingress, application and data zones, mapped onto OpenShift as network policies, node placement (taints/tolerations against zone-labelled nodes) and, on regulated builds, dedicated machine config pools for that node grouping. The decision that matters is not how many zones to have — three or four is typical — but what crosses a zone boundary and how that crossing is enforced. Teams that define zones as “groups of namespaces we generally trust together” end up relying on convention, and convention erodes under delivery pressure. Teams that define each boundary as an enforced NetworkPolicy and, at the routing layer, an explicit allow-list keyed on the calling identity — not the calling IP — keep the boundary meaningful five years on, after the team that drew it has moved to other engagements.
The test we apply: whether a new engineer, reading the manifests alone, can tell which zone a namespace belongs to and what is denied by default. If the answer depends on someone’s memory of the original design session, the zone model is decoration.
Network topology: decide the failure mode before the address plan
Address planning (illustratively, 198.51.100.0/24 for a cluster’s pod network, 203.0.113.0/24 for services) is the part everyone gets to eventually. The part that is easy to skip is deciding, in writing, what happens when a route flaps, when an egress path saturates, or when a second cluster needs to peer with the first. Multi-cluster and multi-site topologies bought without a stated failure mode tend to acquire one by accident, during the first real incident, and the accidental version is rarely the one an auditor would sign off on. Before it is built, the topology has to answer three questions on paper: what is the blast radius of one link failing, what is the blast radius of one control plane failing, and which of those two failures is cheaper to tolerate than to prevent.
Certificate strategy is a five-year commitment, not a bootstrap task
OpenShift ships a working certificate story out of the box, which is precisely why it gets under-designed. The decisions that matter are rotation ownership (platform-managed versus an external CA integration), the trust boundary between cluster-internal and externally-facing certificates, and — the one most often missed — what breaks when a root or intermediate is rotated on the timeline the organisation’s PKI policy actually mandates, not the timeline the platform team hopes for. A certificate strategy chosen for convenience in week one becomes a manual, high-risk rotation exercise in year three, executed by people who did not choose it.
Failure domains and naming are the same decision, twice
Failure domains — how workloads are spread across racks, availability zones or sites — and naming conventions look unrelated but fail the same way: both are cheap to change on day one and expensive to change once referenced. A naming scheme that does not encode environment, zone and failure domain (for example app-checkout-prod-zone2-az1, rather than app1-prod) forces every future automation, alert rule and RBAC policy to carry a lookup table instead of reading the name. Failure domains defined loosely as “spread the nodes around” rather than mapped explicitly to the organisation’s actual power, network and hypervisor boundaries give a false sense of resilience that only surfaces during a real regional event.
Making the five reviewable
None of this requires a heavyweight process. It requires that each of the five decisions exists as a short, dated architecture decision record — context, the options considered, the choice, and the specific consequence accepted — placed in the same repository as the manifests it governs, and put in front of an architecture board before the first production namespace is created rather than after. The record does not need to be long:
decision: zone-boundary-enforcement
status: accepted
context: ingress-to-application crossing must be identity-based, not IP-based
choice: NetworkPolicy + mTLS peer authentication at the mesh layer, once a service mesh is in the stack
consequence: services without a mesh sidecar cannot receive ingress traffic
A board that can read five such records in twenty minutes can catch the decisions that will not survive contact with a merger, an audit or a second site — while they still cost an afternoon to change, rather than a migration.
We build this review into the first two weeks of every OpenShift and Ansible Automation Platform engagement we take on, because judgement applied before the concrete sets is the only kind that is still cheap.