# System Architecture 🏗️

## Infrastructure Overview

In this section, I will delve into an example implementation of Backstage using a combination of Google Cloud Platform (GCP) services, Okta for Single Sign-On (SSO) authentication and authorization, and GitHub integration to access organization data.&#x20;

Here's a preliminary glimpse into the system's structure:

<figure><img src="https://1588585907-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MTwgToRvLjYdjfpAVgP%2Fuploads%2FRzUEmaOlBnY5hovtaZf4%2Fimage.png?alt=media&#x26;token=ae2e0cb5-1929-43d0-9984-bc3c9d6982e4" alt=""><figcaption></figcaption></figure>

* **Backstage Layer**
  * Backstage deployed on Cloud Run
    * Traffic outside of work hours is very low to none
    * ✅ Cost savings from going serverless and scaling to 0 instances when not in use
      * ⚠️ Tradeoff was cold starts. The first request needs to wait for a new container, causing a delay (10-15s).&#x20;
    * Cloud Run has [autoscaling](https://cloud.google.com/run/docs/about-instance-autoscaling), meaning that you don't necessarily need to put a load balancer in front!&#x20;
* **Storage Layer**
  * Cloud SQL: User, project and organization metadata
  * Cloud Storage: API documentation stored (swagger/openAPI)
  * Secret Manager: App secrets fetched and used as environment variables during build and runtime
* **Integration Layer**
  * Okta: Authentication/Authorization
  * GitHub: Repository and organization data management
  * Third-party tools: Monitoring via Cloud Logs and Google Analytics.
* **Nice-to-Have (But Not Achieved)**
  * Leveraging [cache](https://backstage.io/docs/overview/architecture-overview/#cache) stores (Redis, etc.) to improve performance

### CI/CD Deployment Pipeline 🔄

<figure><img src="https://1588585907-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MTwgToRvLjYdjfpAVgP%2Fuploads%2FPXOVZZYmom6bC7tZ2UFn%2Fimage.png?alt=media&#x26;token=f03e7e17-501b-4367-9d0c-10ef749f255e" alt=""><figcaption></figcaption></figure>

**Pipeline Components**

* **Trigger**: Cloud Build trigger listening for merge to default branch events
* **Build Process**:
  * Pull latest Backstage image from Artifact Registry (build cache)
  * Build new Docker image with latest changes
  * Push updated image to Artifact Registry
  * Deploy new instance to Cloud Run
* **Nice-to-Have (But Not Achieved):**
  * Staging environment
  * Canary rollout
    * Small percentage -> monitor metrics -> increase traffic if stable

**Key Benefits**

* **Efficient Builds**: Docker layer caching reduces build time
* **GitOps Deployment**: Zero-touch deployment process
* **Rollback Capability**: Easy rollback to previous versions
