Skip to main content

Core Concepts

To use Infrastream effectively, you only need to understand a few core concepts. These concepts form the foundation of the platform and will guide you in how you define, deploy, and manage your applications and services.

Manifests: Your Declarative Interface​

The most important concept in Infrastream is the Manifest. A manifest is a simple, human-readable text file (written in YAML) where you declare the resources you need.

Think of it like providing a blueprint to an automated factory. You don't need to know how to operate the machinery, weld the steel, or run the electrical wiring. You simply provide a precise blueprint that describes the final product, and the factory (Infrastream) handles the entire complex assembly process for you.

You are responsible for defining what you want, and Infrastream is responsible for the how.

For example, to request a database, you don't write complex scripts. You add a block like this to your manifest file:

# This is a complete, standalone manifest in its own file.
# File: ../project/your-project-name/database/my-app-db.yaml
apiVersion: lowops.manifests.v1
kind: Database
metadata:
  name: my-app-db      # The name of your new database
  # --- Parent Metadata ---
  project: your-project-name
  environment: development
  organizational-unit: your-ou
  organization: your-org
spec:
  clusterSize: 3
  cpuCount: 4

You declare the desired state, and the platform takes on the complex tasks of provisioning the database, configuring it, setting up networking and firewalls, and ensuring it meets all security and compliance requirements.

The Infrastream Hierarchy: Where Your Resources Live​

All resources within Infrastream are organized into a strict hierarchy. This structure ensures that everything is logically contained, secure, and easy to locate. You will primarily interact with the lower levels of this hierarchy.

The structure flows from the broadest scope to the most specific:

  • Organization (The entire company)
    • This is the top-level container. It's managed by the central platform team and contains the global security policies and billing configuration that apply to everyone.
  • Organizational Unit (OU) (Your Line of Business, e.g., "Retail Banking")
    • An OU represents a major division or product area within the company. It allows different lines of business to have their own specific configurations while still inheriting the global policies from the Organization.
  • Environment (e.g., development, production)
    • Within your OU, resources are separated by environment. This allows you to have a development environment for testing and a production environment for live traffic, with configurations that are consistent but appropriately scaled (e.g., a smaller database in development).
  • Project (Your application, e.g., "Mobile-Login-Service")
    • This is your primary workspace. A Project Manifest defines all the resources for a single application or a collection of tightly-coupled services. This is the file you will edit most frequently to add a new microservice, a storage bucket, or change an application's configuration.

Understanding this hierarchy helps you locate the correct manifest file to edit when you need to make a change.

The Core Project: The Hub for Shared Services​

While you will do most of your work within your team's Project manifests, it is useful to know about the Core Project.

The Core Project is a special, central Google Cloud project that provides foundational services consumed by all other projects in the organization. If a Project is your team's office, the Core Project is the building's central facilities management—it hosts the Spanner State Ledger, the Infrastream Engine execution environment, the core Shared VPC networking, and enterprise security tools that all offices share.

Because the Core Project manages highly critical shared infrastructure, it is completely opaque to end-users. You will never need to edit a manifest for the Core Project directly; the Engine handles its configuration and lifecycle automatically, ensuring a seamless delete/rehydrate flow for disaster recovery. Knowing it exists simply helps you understand where the core services that power your applications come from.