Projects, Blueprints, Resources, Intents, Flavors, Packs, Environments: the entities you'll be naming and configuring.

Projects

A 'Project' in Facets is a comprehensive workspace that provisions the infrastructure and streamlines software development. It houses a Blueprint, which acts as your application's visual roadmap provisioning all the resources required for your Project, and Environments that are practical implementations of the Blueprint for software deployment on your selected cloud platform. For detailed instructions on setting up a Project, refer to the Creating a Project documentation.

Blueprint

Blueprints are declarative representations of your overall application's architecture. They serve as a comprehensive plan, enabling you to design every aspect of your product without deploying resources to the cloud.

They encapsulate all configurations required to create and manage cloud environments, including resource definitions, service discovery, and secrets. Stored as files in a Git repository, blueprints provide a single source of truth for infrastructure design and deployment.

Benefits of using Blueprints

Consistency and Zero Drift

Blueprints ensure that all your environments follow the defined architecture unless explicitly overridden. You can always compare an environment against the blueprint defaults, maintaining consistency across deployments.

Default Configurations

Blueprints let you set default configurations. For example, if you set your production configuration as the default, you can launch a performance environment identical to production whenever needed.

Single Source of Truth

Blueprints act as a single source of truth for your infrastructure. They help you tag resources correctly for billing and cost tracking. Since blueprints capture everything needed to run an environment, including resource configurations, service discovery, and secrets, you can launch environments with a single click.

Efficient Resource Management

Blueprints help you manage resources by defining and tagging them correctly. This ensures your cloud infrastructure is organized and costs are tracked accurately.

Version Control with Git

Every Blueprints reside in a Git repository, so all infrastructure changes are versioned and under your control. This approach offers several advantages:

Versioning: Fine-grained versions in resource configurations are beneficial as your team grows. You can use PR raise and merge flows similar to your code for infrastructure, observability, and application configuration changes.
Innovation: Infra-as-Code files in JSON allow internal teams to be innovative. Some customers have written Slack bots for resource creation, policies to scan before each release, and automation to rightsize resources based on feedback from observability platforms.

Resources

A resource in Facets refers to any cloud infrastructure component included in a Blueprint and deployed to an environment. This can range from fundamental elements like VPCs and Kubernetes clusters to application-specific components like databases, caches, and load balancers. For detailed instructions on provisioning resources within Facets, refer to the Adding Resources documentation.

Understanding Intents

An Intent represents a high-level infrastructure requirement. When you're building an application, you think in terms of capabilities: "I need a database" or "I need a cache." You shouldn't need to worry about whether it's AWS RDS, GCP Cloud SQL, or which specific configuration parameters to set.

Here's how an Intent works in practice:

# Example Database Intent
{
  "kind": "postgres",
  "version": "0.1",
  "disabled": true,
  "metadata": {
    "tags": {
      "name": "postgres"
    }
  },
  "spec": { }
}

The Intent above declares a postgres intent what you need without specifying implementation details. It focuses on the essential characteristics your application requires. This abstraction allows you to maintain the same Intent across different environments or cloud providers.

Working with Flavors

While Intents declare what you need, Flavors define how to provide it. A Flavor is a concrete implementation of an Intent, packaged as a Terraform module. Think of Flavors as the bridge between your high-level requirements and actual cloud resources. Each Flavor implements the same Intent differently, but they all satisfy the core requirements.

Here's how to assign a flavor:

# Example Database Flavor
{
  "kind": "postgres",
  "flavor": "k8s",
  "version": "0.1",
  "disabled": true,
  "metadata": {
    "tags": {
      "name": "postgres"
    }
  },
  "spec": { }
}

In the above, the Flavor we assign, "k8s" in this case, specifies how this database will be provisioned, packaged as a Terraform module tailored for Kubernetes deployment. This allows the Intent for PostgreSQL to be fulfilled in a way that's consistent across different cloud environments, leveraging Kubernetes as a common infrastructure layer.

With an understanding of resources, intents, and flavors, you can define infrastructure components in Facets. By structuring these components, you can create an infrastructure blueprint tailored to your project's needs.

Packs

Packs are collections of Intents and Flavors managed by Ops teams. They act as a registry of infrastructure capabilities, allowing developers to access reusable definitions for consistent infrastructure deployment.

Types of Packs

Facets Module Packs: Provided by Facets, including pre-configured Intents and Flavors designed to cover standard infrastructure needs.
User-Created Packs: Created by organizations to include custom Intents or additional Flavors for existing Intents, tailored to specific infrastructure needs.

Function of Packs

Ops Setup: Ops teams create Module Packs by organizing relevant Intents and corresponding Flavors.
Standardisation and Flexibility: Custom Packs allow organizations to define new infrastructure requirements or specify additional Flavors for existing requirements.
Developer Use: Developers select Intents from Packs to create their product architecture, a Blueprint.

Packs act as a centralized registry, simplifying access to reusable infrastructure definitions and promoting consistency across products and environments.

Environment

An Environment in Facets is a concrete implementation of a Blueprint designed for a particular cloud infrastructure. It contains all necessary resources, configurations, and services to run the software.

Base Environment

The term "Base Environment" is often referred with "Environment" when referring to a standalone environment that is created independently and operates without dependencies on other environments. Both terms refer to the same concept when there is no need for environment-specific dependencies.

Dependent Environment

The Dependent Environment in Facets enables environments to inherit infrastructure, tools, and deployed resources from a specified Base Environment. This approach ensures consistency, minimizes duplication, and simplifies maintenance by allowing updates made to the base environment to propagate to dependent environments as needed. For detailed instructions on creating a Dependent Environment, refer to the Dependent Environments documentation.

Time-Sensitive Environments

Time-sensitive environments support temporary setups for testing or short-term projects. These environments are configured within a normal environment to be used for specific purposes and can be easily discarded once they are no longer required. For detailed instructions on configuring an environment as time-sensitive, refer to the Availability Rules for Environments documentation.

The next step is learning how to customize and adjust resources within these environments through overriding, allowing for tailored configurations and flexibility in deployment.

Core concepts