4.1 Introduction

Architecture explains how Moonitoring systems are assembled and where their responsibilities begin and end. It answers four questions, in this order: which systems we run and who uses them, in which environments they run, how those environments are networked and protected, and which services and technologies we chose to build them.

Source of truth

The architecture is drawn in the draw.io diagram and its costs in the cost diagram. Both open only for Google accounts with access to the files. These pages explain the drawings and the rules behind them; when a design changes, update the drawing and the page together.

4.1.1 Principles

A few rules shape every page that follows. When a new system or change seems to need an exception, the exception is a design discussion, recorded as a decision, not a shortcut.

• One ecosystem of systems. The Moonitoring Platform is made of small systems, each responsible for one thing: access holds identities, Organizations and permissions, releases the releases of our installed clients, farm the canonical farm data (see System Overview). A system owns its own data and APIs and reaches another system only through its API or its events, never through its database.
• Environments stand alone. No environment depends on another to keep running.
• Serverless by default. Nothing stays on for convenience: services scale to zero, notebooks are stopped, no model endpoint is kept on. The fixed costs are the database of each environment and the public edge.
• Everything runs in Google Cloud. Services, data and databases live in our own projects, in Milan, behind our own network and identities.
• Europe holds every primary copy of the data. Other regions may receive an entry point close to their users and read-only copies, never the primary.
• No keys. People and workloads prove who they are through Google identities. Nobody downloads a service account key.
• Infrastructure only from code. Every change to the cloud is a reviewed change to a repository, applied by a pipeline.

4.1.2 Reading Order

• 4.2 System Overview

  The systems we run, the people and machines that use them, and how they connect.

• 4.3 Environments

  Shared, sandbox, stage and prod: what each one is for and what data it may hold.

• 4.4 Resource Hierarchy

  How Google Cloud is organized into folders and projects, and how they are named.

• 4.5 Network

  How traffic enters, how environments are kept apart, and how services reach the database.

• 4.6 Services & Technologies

  The cloud services, languages and tools we chose, and the alternatives we set aside.

• 4.7 Ingestion

  How farm data travels from the farm to canonical data, and where raw files and canonical data are kept.

• 4.8 Identity & Access

  Who may do what, for people, services and customers, and how every action is audited.

• 4.9 Infrastructure as Code

  How a change to the cloud is proposed, reviewed and applied with Terraform.

• 4.10 Costs

  What each environment is expected to cost, the budgets and their alerts.

• 4.11 Application Delivery

  The common contract for registering a service, building it and releasing it to stage.