Kubernetes you can actually run after we leave

Kubernetes is a good answer to a specific set of problems: many services that must be released independently, workloads that scale up and down sharply, or a need to run the same platform in more than one place. It is a poor answer for one application with one database and a team of four. A managed app service or a pair of virtual machines is cheaper, simpler and easier to hire for.

We open every engagement with a short assessment that asks plain questions. How many services do you run and how often does each change? What does your traffic curve look like across a week and across a year? Who will be on call, and have they operated a cluster before? If the honest answer is that you do not need Kubernetes yet, we say so and write down the signs that would change that.

When the answer is yes, we choose between a managed control plane, such as EKS, GKE or AKS, and a self-managed cluster. Managed is the default because it removes the hardest operational job, keeping the control plane healthy and patched. Self-managed makes sense mainly when infrastructure must sit in a specific in-Kingdom environment that has no managed offering.

Most Kubernetes failures are design failures, not software failures. Clusters become unmanageable when every team installs its own tools, when nothing limits how much memory a service can claim, or when upgrades are postponed until the version is out of support. We keep the platform small: one ingress, one way to deploy, one way to store secrets, resource limits on every workload and a written upgrade routine at least twice a year.

Containerizing the applications comes first and often takes longer than the cluster. Applications that store files on local disk, hold sessions in memory or read configuration from hard-coded paths need modest changes before they behave in a cluster. We make those changes with your developers, and keep a list so the same patterns are not reintroduced.

Stateful systems deserve caution. We usually keep databases on managed database services rather than inside the cluster, because backup, failover and patching are already solved there. Running a database in Kubernetes is possible, and we do it when the requirement is clear, but it should be a decision, not a default.

A cluster concentrates risk, so the security baseline matters. We apply network policies that deny traffic between services by default, give each service the narrowest role it needs, scan images on every build and block known critical vulnerabilities from running. Secrets come from a vault, not from files in a repository. These measures map to the National Cybersecurity Authority's Essential Cybersecurity Controls, and the logs they produce serve as evidence for an assessment.

Where the cluster runs depends on your data. Regulated and government-linked workloads may need to remain in Saudi Arabia under the cloud framework published by the Communications, Space and Technology Commission, and personal data is subject to the transfer rules under PDPL. Managed Kubernetes is available in in-Kingdom regions from several providers, and we check the specific service in your chosen region before committing to a design.

Plan for 4 to 8 weeks to reach a production-ready cluster for a handful of services, including training. Adding a service afterward typically takes days, because the pattern already exists.