Implementation / System Design

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.

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

Backend and Frontend Deployment on GCP Cloud Run

When implementing Backstage, I decided to separate the frontend and backend into two distinct containers for several reasons. By doing this, we can allow each service to scale independently. For example, if the frontend experiences a surge in traffic due to an increase in user requests, it can scale up without impacting the backend services.

This separation also promotes a clear division of concerns, making the development process more straightforward. It allows my team to focus on the frontend and backend independently, improving our efficiency. Additionally, it boosts security by minimizing the attack surface; I can keep the backend isolated and only expose the necessary API endpoints to the frontend, reducing potential vulnerabilities.

Deployments

To deploy the frontend and the backend, I had to do the following:

  • Separate Frontend Dockerfile

    • I followed the steps in the Backstage docs here to separate the docker build of the frontend.

    • You can find two great examples of Dockerfiles that only build the frontend over here.

  • Google Cloud Build Deployment

    • I wrote a Cloud Build pipeline that builds an image for both the backend and frontend, pushes it to the Artifact Registry and deploys it to two Cloud Run services.

    • I added a build trigger that uses the "Push to a branch" event.

    • I set the branch to use the default branch ^main$.

    • To achieve separate deployments, you can add some logic to skip frontend or backend deploys when there are no file changes that are made in their respective directories .

Database Management with GCP Cloud SQL

For managing the database, I opted for Google Cloud SQL. Here's how I integrated it:

  • Database Setup: I created a Cloud SQL instance choosing PostgreSQL as the database engine.

  • Connection Pooling: To enhance performance and manage database connections efficiently, I implemented connection pooling within the Backstage backend, ensuring a smooth user experience.

Okta for SSO Authentication and Authorization

To implement robust authentication and authorization, I integrated Okta with my Backstage instance:

  • Okta Setup: I followed the instructions on this page.

  • Authorization Policies: I defined authorization policies within Okta to control access to different parts of Backstage based on user roles and permissions.

GitHub Integration for Organization Data

GitHub integration was crucial for accessing and managing the organization's data within Backstage:

  • GitHub App: I used the backstage-cli to create a Github App following the instructions here.

  • GitHub Metadata: I configured Backstage to pull organizational data using the docs here.

  • Resolving Github Users: To make it easier to manager users, I folllowed the steps here to link Okta users to Github users via email.

Cloud Storage for Storing API Docs

To store and manage API documentation, I utilized Google Cloud Storage:

  • Storage Buckets: I created Google Cloud Storage bucket to store API documentation files.

  • Integration: I configured Backstage to access and serve API documentation from the bucket using the documentation on this page.

By implementing this combination of GCP services, Okta for authentication and GitHub for Org data, you can have a basic Backstage setup that efficiently manages developer projects and provides a seamless experience for users. Additionally, using Cloud Storage for API documentation storage ensures that developers can easily access, find and use the information they need.

From here you can create scaffolder templates and add existing plugins to add features and enhance your Backstage implementation.

Last updated