Docker
Docker and Kubernetes: every question a buyer asks
Split out from the main Docker page so it stays easy to scan: getting started, the platform decision, and operating a cluster after go-live, answered in one place.
Published 3 min read
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Getting started
Can you containerise an application we did not write?
Usually yes, though the answer depends on what the application assumes. The blockers are normally local state, filesystem assumptions and hard-coded configuration rather than the language or framework. An assessment of those comes before any commitment.
Can this be done without a full rewrite?
Yes, and incrementally is normally how it should be done. Systems are moved piece by piece with the legacy platform running alongside the new one, rather than attempting a single cutover of a system the organisation depends on.
Platform decision
Do we need a hyperscaler cloud to run Kubernetes?
No. Kubernetes runs perfectly well on infrastructure inside the Kingdom, on-premise or in a local cloud region, which is what many Saudi organisations require for data residency. The trade-off is that a self-managed cluster needs operating, which is part of what Interkey provides.
Managed or self-managed Kubernetes: how should we decide?
By constraint. If your data and workloads are permitted to run in a hyperscaler’s managed service, take it: the automation you get is worth more than the control you give up. If a residency or sovereignty constraint keeps workloads in-Kingdom, self-managed on local infrastructure is the honest answer, priced with its true cost: somebody has to operate the platform for years. The decision table on the main Docker page is the whole framework.
Operating it
What does operating a cluster actually involve after go-live?
Version upgrades on Kubernetes’ fixed release cadence, each with a tested rollback; node lifecycle and capacity review; certificate and secret rotation; backup proven by restore; security patching; and an on-call arrangement for the platform itself, separate from the applications on it. None of it is exotic, and all of it is the difference between a platform and an incident with a delay on it.
How does monitoring fit into a container platform build?
As part of the platform, not a later phase. Containerised workloads move between nodes, scale in and out and leave no console to log into, so visibility has to be designed in: cluster and workload metrics, logs and traces, with alerting the platform team actually trusts. That is where this practice meets Interkey’s observability work, and the Kubernetes monitoring guide covers the design in depth.
Next step
Discuss a container platform
Tell us what runs where today — VMs, bare metal, a cloud account — and whether the constraint is residency, cost or release speed. That is enough for a first conversation.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia
Elsewhere