Technology partners
Docker and Kubernetes implementation and operations
Interkey containerises applications that were never designed for it, builds the pipelines around them, and operates the cluster afterwards — including the managed-versus-self-managed decision that residency rules usually settle for you.
The trap
What Interkey delivers with containers
Containerisation is well understood as an idea and frequently mishandled in practice. The common failure is treating it as a packaging exercise: an existing application is wrapped in a container, deployed to a cluster, and nothing improves, because the application still holds state locally, still assumes it is the only instance, and still cannot be restarted without a coordinated outage.
Interkey’s container work starts from the application rather than the platform. That means identifying what actually prevents a given system from running as multiple interchangeable instances: local session state, filesystem assumptions, hard-coded configuration, a startup sequence that depends on something else being ready, and fixing those before the orchestration layer is expected to solve them.
The delivery
From application to running platform
Unblock the application
Find and fix what prevents the system from running as multiple interchangeable instances, before the orchestration layer is expected to solve it.
Images and pipelines
Container image design and build pipelines, with CI/CD so that deployment becomes routine rather than an event.
Cluster architecture
Kubernetes cluster architecture and sizing, designed for the workloads it will actually carry.
Operate for years
Monitoring, logging, resource management and the upgrade discipline a cluster needs to stay healthy over years.
The first decision
Managed or self-managed Kubernetes
Take a hyperscaler’s managed service when your data is allowed to live there, and self-managed only when a constraint forces it — accepting that self-managed means owning the platform’s operation for years. And if a handful of stable applications deploy fine as they are, neither column is worth its operating cost yet.
| What decides it | Managed service | Self-managed, in-Kingdom |
|---|---|---|
| Where workloads may run | The provider’s regions; fine when your obligations allow it | Your infrastructure, inside the Kingdom, which is the usual reason to be here |
| Control-plane operation | The provider’s problem: upgrades, availability and patching arrive as a service | Your problem, or your partner’s: versions, upgrades and rollback discipline are real work |
| Day-two ownership | You still own alerting, cost and the upgrades of what runs on it | Somebody owns versions, capacity review and on-call for years. Interkey does that on the Saudi working week, or backs the team that does |
| Legacy running alongside | Assumes a fairly clean target state | Modernisation here is incremental: estates move piece by piece with the old system live for a long time, and the platform has to accommodate that |
| What you give up | Residency control, and some architectural freedom | The provider’s automation: you are buying control with engineering effort |
Security posture
What a production cluster has to be able to show
Container platforms concentrate risk as well as workloads, and a security review will ask for these whether or not anyone planned for them. Building them in from the start is dramatically cheaper than retrofitting them under audit pressure.
- Role-based access control that maps to real teams, not one shared admin credential
- Admission policy: what is allowed to run, and what is automatically refused
- Image scanning and a private registry, so provenance is known for everything deployed
- Secrets managed outside the codebase, with rotation that actually happens
- Network policy between workloads, because a flat cluster network is an incident waiting
- An upgrade cadence with a tested rollback, written down and rehearsed
- Backup and restore for cluster state and data, proven by an actual restore
Containerisation of systems that predate containers
The application unblocked first, then the platform
Self-managed and in-Kingdom platforms
For estates that cannot leave the Kingdom
Operated on the Saudi working week
Riyadh engineering, Sunday to Thursday
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.