Skip to content

Deployment Models

The same managed cluster can be delivered in four different arrangements. The choice is not ideological: it follows from where the users are, what downtime costs and where the data is allowed to be.

The four deployment models, from simplest to most distributed, with phased evolution

Each model is a step: you can start on the first and evolve without rebuilding the platform.

1. Single region

The simplest configuration uses worker nodes in a single region — usually br-sp-1.

Suited to: applications that primarily serve one geographic region, with no cross-datacenter continuity requirement, data that must stay close to the application, and simplicity and cost efficiency as priorities. Benefit: lowest cost, lowest internal latency and the least operational complexity possible. Limitation: a single failure domain — losing the region means losing the environment.

Even in this model the cluster is still managed: Cilium networking, security policies, controlled platform updates and monitoring are part of the service.

2. High availability across InteSys datacenters

For critical applications, workers are distributed across br-sp-1 (Cirion SAO1, Cotia/SP) and br-sp-2 (Equinix SP3, Tamboré/SP).

Both regions sit in the São Paulo metropolitan area but operate from different physical facilities and infrastructure providers, interconnected by Lan2Lan links or encrypted tunnels. The latency between them is a few milliseconds, which keeps even synchronous database replication viable.

Suited to: critical production that must survive the loss of one datacenter while keeping all data in Brazil. Benefit: two real failure domains, without leaving Brazilian jurisdiction and without international latency. Limitation: it does not protect against an event hitting the whole São Paulo metropolitan area — that calls for a third domain in another geography.

Kubernetes identifies node locations through regions and availability zones, which makes it possible to require automatic distribution across zones, pod anti-affinity, topology spread constraints, PodDisruptionBudgets and a minimum number of replicas per region.

3. Hybrid — InteSys + public cloud

The same cluster combines InteSys infrastructure with computing capacity from a public cloud: AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner or the customer's own infrastructure.

A common arrangement:

  • InteSys, Brazil — main application, databases and latency-sensitive workloads;
  • Public cloud, US — asynchronous processing and additional capacity;
  • Public cloud, Europe — serving European users.

Suited to: international expansion, disaster recovery with another provider, or use of a specific service that only exists in one cloud. Benefit: use each provider where it offers the greatest technical or commercial advantage, without fragmenting the platform. Limitation: traffic between providers carries latency and egress cost — the design has to keep chatty conversations inside the same region.

4. Multi-cloud

For environments designed to reduce provider dependency, workers sit simultaneously in more than one cloud — InteSys + AWS, InteSys + Azure, InteSys + Hetzner, InteSys + customer infrastructure, or several providers at once.

Suited to: an explicit provider-independence requirement, a contractual obligation to use multiple providers, or a continuity strategy that will not accept a single vendor as a single point of failure. Benefit: capacity, redundancy and geographic reach spread across providers. Limitation: each extra region adds latency, inter-provider traffic, egress cost, storage complexity and one more failure domain to operate.

Multi-cloud is not a goal in itself

The goal is not to use the largest possible number of clouds, but the combination of infrastructure that makes sense for the application's availability, performance, compliance and cost requirements. Every additional provider charges in operational complexity.

Flexible capacity per region

Worker nodes do not need identical configurations or the same provider. One cluster can combine, for example, two 16 vCPU / 64 GB nodes in br-sp-1, two matching nodes in br-sp-2 and smaller nodes in a public cloud for asynchronous processing.

That allows infrastructure to be optimized simultaneously for cost, latency, availability, data residency, capacity, compliance and proximity to end users — and to deliberately place latency-tolerant workloads in cheaper regions.

Phased evolution

PHASE 1         PHASE 2                   PHASE 3
br-sp-1    →    br-sp-1 + br-sp-2    →    br-sp-1 + br-sp-2 + public cloud

At each phase what changes is the infrastructure topology — not the platform, and not the application's manifests.