Core Concepts

Fractal — The Formal Definition

A Fractal is a component constituted of two entities:

• A Blueprint: a versioned group of components and integrations defining the infrastructural foundation of a compliant Live System;
• An Interface: a versioned set of operations through which the Fractal can be further specialized or extended; these operations can cause the addition, removal, or modifications of components and their integrations within the Fractal. An operation performed on a compliant Fractal will always produce either a compliant Live System or a further specialized Fractal.

Any team member with access to a Fractal can instantiate it unlimited times, using multiple infrastructure stacks and vendors. The result of a Fractal instantiation is called a Live System.

---

The Component Model

The power of Fractal Cloud comes from its Component Catalogue — a cloud service categorization system that separates infrastructure capabilities from their concrete implementations.

Component → Service → Offer

The catalogue is organized as a three-level hierarchy that progressively narrows from abstract capability to concrete, deployable resource.

Component — An infrastructure capability, uniquely identified by an Infrastructure Domain and a Name. Components are both vendor-agnostic and delivery-model-agnostic — they describe what is needed, not how or where it is delivered. A Component defines the parameters (what can be configured), dependencies (what other components are required), and link properties (how other components connect to it).

Example: Compute.ContainerOrchestrator — "I need container orchestration."

Service — A specialization of a Component, also vendor-agnostic. Each Service is uniquely defined by adding a Service Delivery Model to the Component's Infrastructure Domain and Name. A Component can have one or more Services, each representing a different way the capability can be delivered. The delivery model defines the operational contract — what you manage versus what the platform manages.

Example: Compute.PaaS.Kubernetes — "I need container orchestration, delivered as a managed platform."

Offer — A concrete, vendor-specific implementation that fulfils a Service. Each Offer corresponds to an actual resource that gets provisioned on a specific cloud provider or infrastructure platform, with the full configuration schema for that vendor's implementation.

Example: Compute.PaaS.AKS — "Azure Kubernetes Service, in West Europe, Standard tier."

The full resolution path:

Component:  Compute.ContainerOrchestrator       ("I need container orchestration")
  Service:  Compute.PaaS.Kubernetes              ("delivered as a managed platform")
    Offer:  Compute.PaaS.AKS                     ("on Azure")
    Offer:  Compute.PaaS.GKE                     ("on GCP")
    Offer:  Compute.PaaS.EKS                     ("on AWS")
    Offer:  Compute.PaaS.OpenShift                ("on-premises")

When a Fractal is deployed, the platform resolves each Component through its Service to a specific Offer, based on the target environment. The same Fractal definition produces AKS when deployed on Azure, EKS on AWS, or OpenShift on-premises — all without changing the Fractal.

Infrastructure Domains

The Infrastructure Domain defines what category of infrastructure a Component belongs to:

Domain	What It Covers
Compute	Virtual machines, container platforms, workloads
Network	Virtual networks, subnets, load balancers, security groups
Storage	Relational databases, document databases, key-value stores, object storage, search engines
Messaging	Message brokers, event streaming, pub/sub systems
BigData	Distributed data processing, compute clusters, data lakes, ML experiments
Observability	Monitoring, tracing, logging
APIManagement	API gateways, ingress controllers
Security	Service mesh security, identity management
CustomWorkloads	Application-specific deployable units (containers, functions, PaaS apps)

Service Delivery Models

The Service Delivery Model defines how a capability is delivered — the operational contract between the consumer and the platform:

Delivery Model	What You Manage	What the Platform Manages
IaaS (Infrastructure as a Service)	Everything from the OS up	Physical hardware, hypervisor, networking
CaaS (Containers as a Service)	Your containers and their configuration	Container orchestration, scheduling, networking
PaaS (Platform as a Service)	Your application configuration	Runtime, scaling, patching, backups
FaaS (Functions as a Service)	Your function code	Everything else
SaaS (Software as a Service)	Your data and configuration	The entire application stack

The Component Hierarchy: Atom → Molecule → Fractal

Components compose into larger structures through a three-tier hierarchy:

Atom — the smallest unit of infrastructure. An Atom is a single, indivisible component with embedded operational standards: security hardening, monitoring hooks, backup policies, compliance tags. It cannot be decomposed further. Examples: a Kubernetes cluster, a PostgreSQL database, a Kafka broker, a virtual machine.

Atoms are not raw cloud resources. A raw cloud resource is just a resource — an EC2 instance, an RDS database. An Atom wraps that resource with everything needed to make it production-ready: default security configurations, observability integration, tagging standards, network policies. Atoms encode the decisions your organization has already made about how infrastructure should be configured.

Molecule — a composed group of Atoms connected by Links. A Molecule represents a functional building block: a "web tier" molecule might combine a Kubernetes cluster, a load balancer, and an API gateway, all wired together. Molecules are reusable patterns that capture how Atoms work together to deliver a specific capability.

Fractal — a complete, deployable architecture pattern composed of Atoms and Molecules with their integrations. A Fractal is the Blueprint that teams instantiate into Live Systems. It represents a full infrastructure stack for an application or service: compute, storage, networking, messaging, observability — all defined, connected, and governed.

The hierarchy is recursive — a Fractal can contain other Fractals, enabling composition at any scale. A "microservices platform" Fractal might compose a "compute" Fractal (Kubernetes + load balancer + API gateway), a "data" Fractal (PostgreSQL + object storage), and a "messaging" Fractal (Kafka + schema registry). Each inner Fractal is independently versioned and reusable.

Links — How Components Connect

Components don't exist in isolation. A Kubernetes workload needs to reach a database. A load balancer needs to know which services to route traffic to. An API gateway needs to authenticate against an identity provider.

Links define these relationships. A Link is a typed connection between two components that carries semantic meaning — it's not just "these two things are connected" but "this workload accesses this database with read-write permissions using connection pooling."

Links have properties that configure the relationship:

• A storage link might specify: access mode (read, write, readWrite), data format (JSON, Parquet, Avro), consistency level (eventual, strong)
• A messaging link might specify: role (producer, consumer), delivery semantics (at-most-once, at-least-once, exactly-once), consumer group
• A network link might specify: protocol (HTTP, gRPC, TCP), routes, authentication requirements

Links ensure that when a Fractal is deployed, the platform not only provisions each component but also configures the connections between them — security groups, IAM roles, connection strings, certificates — automatically.

---

Other Entities

To deliver on its promise, Fractal Cloud uses several more entities than just Fractals and Live Systems:

• Resource Groups: logical sets of Fractals and Live Systems. The Resource Group owns these entities and provides the governance boundary.
• Teams group users and help manage access at scale to one or more Resource Groups.
• Users represent actual people interacting with Fractal Cloud. They can:
  • Administrate, Manage, or have specific access to one or more Resource Groups
  • Administrate, Manage, or be part of one or more Teams
  • Administrate one or many Organizations
• Organizations hold generic metadata and group Teams.

---

Two Available Approaches

Fractal Cloud has been thought and built for Enterprise Scale. Two approaches are available to support your organization in any situation.

Live-System First

• Focus on the end system for quick roll-outs
• Best for PoCs and Moonshots projects

Using the approach we named "Live-System First" you can describe the desired state of your infrastructure through code, pretty much as you might already be doing today.

However, the difference is that with limited amount of code you will be able to spawn tailored infrastructure to the need of your application using standard and security-hardened components ready to support your application and services.

When you are then ready for enterprise-grade, you can extract a reusable Blueprint from your running Live System, making it available for your colleagues across your organization, ensuring cross-pollination of proven best practices, technologies, and architectures.

Fractal First

• Focus on reusability and automation across your organization
• Advised on establishing a cloud adoption and governance framework at the enterprise level

Through the approach we named "Fractal First" you tackle Cloud-Native complexity at the enterprise level from the beginning.

You will first define Blueprints, reusable sets of components, and their relations, which put the basis for compliant solutions in your IT Landscape. To each Blueprint, you can associate an Interface, a versioned set of operations through which the teams can modify the Blueprint while ensuring application compliance.

Any teams authorized will then be able to instantiate a specific Blueprint on any cloud vendor you have enabled, resulting in the creation of a Live System they own.

The latter will be able to be extended and tailored directly by the team owning it without requiring any access to any actual cloud environment; they will instead use the APIs exposed by the associated Interface.