Skip to main content

A pragmatic infrastructure and storage posture

· 4 min read
Ireti Engineering
Product and platform engineering

Infrastructure strategy should protect product velocity, customer data, and operational freedom. It should not force every workload into one cloud service or turn short-term convenience into permanent architectural dependence.

Ireti uses a pragmatic hybrid posture: portable compute, open data technologies, managed services where they provide clear leverage, and explicit authority boundaries across environments.

Principles​

Own the critical path​

Identity, authorization, product metadata, and core application data need predictable behavior and recoverability. They should run on infrastructure we can inspect, back up, restore, and move.

Use managed services deliberately​

Managed services are valuable when they remove undifferentiated operational work: global object durability, DNS, certificates, monitoring, or specialized delivery capabilities. They should be selected by workload need, not by a rule that every component must be managed.

Prefer open, portable foundations​

Containers, PostgreSQL, OpenAPI, standard OAuth/OIDC, and ordinary object APIs reduce coupling. Portability is not an abstract goal; it is negotiating power, recovery flexibility, and protection against regional or pricing constraints.

Keep secrets out of architecture state​

Configuration may identify a secret reference, but credentials and tokens do not belong in source, manifests, catalog records, URLs, logs, or audit metadata. Use managed identity or short-lived credentials where possible.

Compute follows workload boundaries​

The control plane and latency-sensitive product services can run on cost-efficient private compute while edge delivery, durable object storage, and specialized managed services remain in the cloud.

The architecture does not assume that one application workspace equals one virtual machine, container, namespace, database, or hostname. A logical workspace is a stable platform resource. Its physical realization can be:

  • a shared multi-tenant runtime;
  • a dedicated service instance;
  • a dedicated database or schema;
  • an externally managed SaaS tenant; or
  • a regional cell selected by provisioning.

That flexibility is possible because placement is returned by a trusted provisioning boundary rather than inferred by clients.

PostgreSQL as the durable relational core​

PostgreSQL provides a strong default for platform and product systems that need:

  • transactional consistency;
  • explicit schemas and constraints;
  • mature backup and recovery tooling;
  • broad operational expertise;
  • tenant-aware data models; and
  • portability across self-hosted and managed environments.

Separate authorities should remain separate databases or clearly isolated logical stores. Identity data, platform state, authorization relationships, billing state, and product records have different owners and recovery concerns. A shared database server does not imply a shared schema or authority.

Self-hosting PostgreSQL can be economical and operationally sound when backups, restore tests, monitoring, patching, ownership, and capacity are treated as product requirements. Managed PostgreSQL remains an option when its operational benefits justify the cost and migration trade-offs.

Object storage for object-shaped data​

Large immutable or semi-structured objects do not belong in transactional tables merely because PostgreSQL is available.

Use object storage for:

  • uploaded documents and media;
  • generated artifacts;
  • immutable release assets;
  • exports and archives; and
  • backup copies.

Store metadata, ownership references, lifecycle state, and integrity checks in the authoritative relational system. Store the object itself in the service designed for durable blobs.

Public delivery and private storage should remain distinct. A public asset can be published through a controlled release path without making its source container broadly writable or exposing administrative credentials.

Governance without runtime lock-in​

Governance tools such as Azure Arc can provide inventory, policy, monitoring, and operational visibility across machines without requiring every workload to move into one compute platform.

The useful boundary is:

  • governance observes and constrains infrastructure;
  • the application control plane owns application lifecycle and access;
  • product runtimes own their domain behavior; and
  • deployment systems own release placement.

No monitoring label or cloud resource tag should become application authorization evidence.

Resilience is an operational discipline​

High availability begins with recoverability:

  • immutable releases;
  • explicit health and readiness checks;
  • off-host backups;
  • tested restore procedures;
  • documented ownership;
  • bounded failure domains;
  • capacity thresholds;
  • rollback that preserves newer business data; and
  • current-state reconciliation after partial failure.

A nominally redundant architecture without a proven restore path is weaker than a simpler system with disciplined backups and rehearsed recovery.

The result​

Ireti's infrastructure posture is neither cloud-only nor anti-cloud. It is workload-specific.

We keep core authority portable, use managed capabilities where they create clear value, separate logical tenancy from physical placement, and make recovery a first-class part of system design. That balance supports reliable products without imposing enterprise-scale cost or lock-in before the business needs it.