Introduction
Most articles about adopting Kubernetes open with an architecture diagram. We would rather open with a test.
Portability is the reason everybody gives for moving onto Kubernetes, and it is also the claim nobody checks until the day they need it to be true. So we checked it. Endatix’s CI environment runs on Azure’s managed Kubernetes service, and the GitOps control plane that deploys, configures and monitors it runs somewhere else entirely - on DigitalOcean. Two providers, one platform, and neither of them are aware that the other is involved.
Everything above the node line is identical on both. Moving that environment to a different provider would change the infrastructure underneath it and nothing else: not the charts, not the ingress, not the pipeline that ships it.
That is the short version of why we run Endatix on Kubernetes. Below is the longer one - what we were actually buying, and what it means for teams who self-host the Endatix form management system themselves.
Cloud-agnostic is something you build, not something you get
Kubernetes does not make you portable on its own. Plenty of clusters are firmly welded to the cloud they run on: a proprietary ingress controller, a vendor-specific secrets driver, a first-party monitoring agent, DNS managed through a console. Each of those is a small convenience today and a large migration cost later.
So we set ourselves one rule: nothing cloud-proprietary above the node line. Ingress, TLS certificate issuance, DNS records, secret synchronisation - that whole in-cluster platform is the same set of open components on every cluster we run, whoever is hosting it. Below the node line we are happy to use whatever the cloud does well: managed PostgreSQL, managed node pools, managed load balancers. Those are swappable. A rewritten deployment model is not.
Running on two clouds at once is what turns that rule from a claim into a measurement. When the same charts, the same certificate issuance and the same secret synchronisation come up healthy on both, you know what a provider change would actually cost you, because you are already paying for it. And you find the parts that do not port - the managed database networking model, the load balancer’s behaviour - while they are cheap to find, rather than during a migration weekend.
That last point is the one we would underline. Changing your hosting model and your cloud provider at the same time is how outages happen. A portable platform lets you separate the two and verify each independently, which is worth considerably more than any single provider’s pricing.
A platform that grows by configuration, not redesign
We run a hub-and-spoke setup: one management cluster holds the GitOps controller and the provisioning engine, and every other cluster is a spoke that it reconciles. The useful property is not the shape - it is what the next environment costs to add.
Adding one is a values file and a state key. The cluster comes up, registers itself with the control plane, and immediately starts receiving the same platform components and application charts as everything else. Databases are requested by the workload that needs them, declared in Git alongside the application, and provisioned automatically - with production databases explicitly protected, so that a bad sync can never cascade into data loss.
Scalability is usually pitched as “add more pods”, and yes, that too. The scalability that matters day to day is whether your tenth environment costs what your second one did.
Deployment flexibility: one artifact, many destinations
Kubernetes enforces a discipline that is good for you even when it is inconvenient: build the image once, promote that same artifact through every environment, and inject configuration at deploy time instead of baking it in. The build you tested is the build that reaches production, byte for byte.
That discipline is also what makes Endatix a genuinely self-hostable form management system. There is no separate “cloud edition” of the product - we publish the same containers and the same Helm charts we run ourselves. You can deploy them onto a managed Kubernetes service from any provider, onto a cluster in your own data centre, or inside a network where the data is not permitted to leave the building at all.
For a forms and survey platform, that last option is not a nice-to-have. Endatix is used in market research, legal intake, insurance, finance, education and healthcare - sectors where “where exactly does the response data live?” is the first question asked, and often the one that decides the project.
Testing: environments cheap enough to throw away
We put environment creation through the same two-cloud test. Using one definition from one repository, we stood up the same test environment on both providers and then tore both down again: same cluster shape, same platform components, same application versions, same DNS records - described once, applied twice. The differences were in the infrastructure underneath, which is exactly where we wanted them.
This is the benefit that rarely makes it onto a slide. Once an environment is a folder in a repository rather than a console session plus somebody’s memory, you stop rationing environments. Stand one up for a release candidate, point a customer at it for a week, and delete it on Friday. The same charts that run production run the throwaway environment, so what you tested there is meaningful.
Deleting one stops being a decision you have to think hard about, too. The repository still holds the complete desired state after the cluster is gone, so bringing an environment back is a redeploy rather than a rebuild.
Conclusion
We did not adopt Kubernetes in order to be modern. We adopted it so that “what would it take to run this somewhere else?” has a boring answer - and then we ran it on two clouds at the same time to make sure the answer stayed boring.
The payoff is not a saving we can put a figure on. It is that the next time the economics, the latency or the compliance requirements change, moving is a configuration exercise rather than a project. Every team running Endatix on their own infrastructure inherits exactly the same property, because it is the same platform.