Interkey delivers Docker and Kubernetes work in Saudi Arabia

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.

Container orchestration, cloud-native development, DevOps consulting and CI/CD pipeline development are all listed among Interkey’s core capabilities, and this sits alongside its mission-critical solutions practice, which matters, because the organisations doing this here are frequently running systems that cannot simply be taken offline for a weekend.

The pipeline work meets teams where they already are: builds and deployments in whichever CI the estate runs, GitLab CI, GitHub Actions, Jenkins, Azure DevOps, with GitOps-style declarative delivery adopted where it genuinely fits the team’s operating model rather than as a fashion statement. The test applied throughout is unglamorous: can this team deploy on a Thursday afternoon without holding its breath.

The container platform conversation this market skips is the one that matters most: after go-live, who owns the cluster. Kubernetes versions move on a fixed cadence, nodes fail, certificates expire, workloads creep past their resource requests, and a cluster nobody owns degrades silently until it fails loudly. Self-managed platforms in particular need a named operator with an upgrade discipline, a capacity review habit and an on-call arrangement that survives contact with a Thursday-night incident.

Interkey does that work on the Saudi working week, either operating the platform or backing the in-house team that does, and treats visibility as part of the platform rather than an optional extra: a cluster is not finished until its workloads can be seen, which is where this practice meets Interkey’s observability work. Cost belongs in the same conversation, because unbounded resource requests and forgotten namespaces are the container platform’s version of the unread log bill.

This work appears across government and semi-government entities modernising citizen services, telecommunications operators running large internal platforms, energy and industrial organisations, and e-commerce and logistics businesses that need to scale with demand rather than provision for a peak they hit twice a year.

It connects directly to end-to-end software engineering, since containerisation is usually part of building or rebuilding an application, and to digital transformation and cloud migration, where moving to containers is one workstream inside a broader modernisation programme. Where a data platform change is happening at the same time, the two are normally planned together.