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.
Implementation team in Riyadh, working in Arabic and English.
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.
When this is the wrong fit: an application that runs on one server and is deployed twice a year. Containers will not make it faster, and Kubernetes will cost more to operate than the application costs to run. The case appears when the same application has to behave identically in three places, or when environment drift is already the reason releases fail.
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
Working together
How work with Docker and Kubernetes begins
Docker and Kubernetes are technologies Interkey implements and operates; the partner relationship is with the technology, and the people on the cluster are Interkey’s own team in Riyadh. Work begins with what runs where today: VMs, bare metal or a cloud account, and whether the constraint is residency, cost or release speed. That first conversation decides managed versus self-managed before any cluster is built.
The platform build is scoped as a fixed piece of work — cluster, ingress, secrets, observability hooks and the pipeline that deploys to it — and operation afterwards is a written scope under managed services. Pricing follows that scope, with cloud consumption shown as the provider’s cost. Where the move is part of a larger estate change, the cloud migration practice is the page that sequences it, and cloud services is the foundation the cluster lands on.
Read next
Explore related solutions
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.
-
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