← All work

Delivery engineering · Platform & infrastructure · Observability

When not to reach for Kubernetes

Zyntrix Technologies Limited · Wuse 2, Abuja · four clients

Focus
Delivery engineering · Platform & infrastructure · Observability
Evidence
3 documented proof points
Decision record
Firsthand trade-off included

The brief

What was built

One delivery standard across nine runtimes — AWS, Azure, GCP, Vercel, Render, Railway, Heroku, App Engine and Azure App Service — chosen per client rather than by default.

Evidence

Recorded outcomes

  • A written platform-selection framework: operability after handover, compliance, cost at the client's scale, traffic shape, data residency
  • One consistent pipeline, secret-handling and security-scanning contract regardless of target
  • An explicit portability boundary — what was deliberately not abstracted, and why

Decision record

Where the obvious criterion lost

Anchor Cooperative was the case where “financial platform” did not automatically mean “put everything on Kubernetes”. A small team needed low operational overhead, so the web application went to Vercel and the containerised API to Render. But the financial source of truth went to managed AWS PostgreSQL from day one, because application compute is replaceable and financial data is not. EKS remains the target only when measured transaction volume, availability, operational complexity or regulation justifies owning the whole application tier. Operability won for stateless compute; durability and regulatory control won for the data layer.

Return to all work