Harness SaaS Architecture
Harness SaaS architecture.
This diagram provides a high-level overview of Harness SaaS infrastructure. It runs across two regions, us-west1 and us-west2, for fault tolerance. The core infrastructure contains two Kubernetes clusters: a primary cluster and a failover cluster. The failover cluster runs all Harness services with zero pods. This configuration enables rapid application recovery during a regional outage. During an outage in Google Cloud Platform (GCP) us-west1 or one of its zones, pods in the us-west2 failover cluster scale up. Traffic can then move to us-west2 in about 20 to 25 minutes.
Both clusters connect to GCP managed data services for persistent storage and other data services. Additionally, they connect to a few non-GCP managed data services, such as MongoDB Atlas and Managed Timescale DB, which are VPC-peered with the GCP project to minimize network latency and enhanced security.
This diagram provides a detailed view of the Harness SaaS primary cluster. Clients, including automation tools, Harness users, and Harness agents, make Secure Sockets Layer (SSL) requests to *.harness.io. Cloud DNS resolves this hostname to the Google Cloud load balancer (GCLB) IP address. The load balancer routes requests to Cloud CDN for static content and delegate JARs, or to the primary Kubernetes cluster in us-west1.
Cloud Armor provides an additional layer of security by protecting against DDoS attacks and enforcing Web Application Firewall (WAF) rules. SSL termination also occurs at the GCLB.
The primary Kubernetes cluster is divided into 3 logical clusters (Prod1, Prod2, and Prod3). Harness customer accounts are distributed across these 3 logical clusters to achieve scalability, reduce the blast radius of releases, and adhere to compliance requirements. Each logical cluster has its own set of Harness services and data stores. Releases typically follow a staged approach, starting with Prod1, then Prod2 after a day, and finally Prod3 after a week.
Harness uses a microservices architecture. Requests route to the appropriate microservices through the NGINX Ingress Controller. Prod3 uses a dedicated ingress controller. Prod1 and Prod2 share a separate ingress controller. The Gateway Service routes requests to Prod1 or Prod2 based on the account identifier. Prod3 has its own Gateway Service.
Last updated
Was this helpful?