Fractal Sprint | Webinar: How to Build a Governed Developer Platform | Watch Now →

Fractal Cloud

How to Build Reusable Infrastructure: A Step-by-Step Guide

Fractal Cloud interface showing how to create a Fractal and build reusable infrastructure

Introduction

Your developers need an environment. They open a ticket. They wait. Days pass. Someone manually provisions the resources, wires them together, checks compliance, and closes the ticket. Next week, someone else needs the same thing and the cycle repeats.This is what happens when infrastructure knowledge lives in people's heads instead of in the platform. Fractals are how you fix that.In this post, you'll learn what a Fractal actually is at a technical level, how the component model works under the hood, and how to create one step by step. This is aimed at platform engineers and DevOps architects who want to go beyond the concept and start building.If you're looking for a higher-level overview of why platform engineering matters, check outDeveloper Portal vs Platform: Why a Portal Is Not Enough. Here, we go hands-on.

What Is a Fractal, Technically?

A Fractal is composed of two entities:🔷 Blueprint: a versioned group of components and integrations that define the infrastructural foundation of a compliant system.🔷 Interface: a versioned set of operations through which the Fractal can be further specialized or extended (adding, removing, or modifying components and their integrations).When a developer instantiates a Fractal, the result is a Live System, a real, provisioned environment that stays synchronized with the declared intent specified by the Fractal.The key property: any operation on a compliant Fractal produces either a compliant Live System or a further specialized Fractal. You can't break governance.The Fractal Automation Engine continuously monitors the Live System, detects drift, and reconciles it back to the desired state.This is fundamentally different from traditional IaC templates. A Terraform module produces a state file and hopes nothing changes. A Fractal produces a Live System that is actively governed for its entire lifecycle.

The Component Model: Component → Service → Offer

Before building a Fractal, you need to understand the three-level component hierarchy. This is the abstraction layer that makes Fractals cloud-agnostic.ComponentAn infrastructure capability, uniquely identified by an Infrastructure Domain and a Name. It is vendor-agnostic and delivery-model-agnostic. It describes what is needed, not how or where.Each Component defines:🔷 Parameters: what can be configured🔷 Dependencies: what other components are required🔷 Links: how other components connect to itExample: 'Compute.ContainerOrchestrator' means "I need container orchestration."ServiceA specialization of a Component that adds a Service Delivery Model (IaaS, CaaS, PaaS, FaaS, SaaS).Example: 'Compute.PaaS.Kubernetes' means "I need a specific container orchestrator, Kubernetes, delivered as a managed platform."OfferA concrete, vendor-specific implementation that fulfills a Service. This is the actual resource provisioned on a specific cloud provider.Example: 'Compute.PaaS.AKS' means "Azure Kubernetes Service."The full resolution path looks like this:The same Fractal definition deploys AKS on Azure, EKS on AWS, or OpenShift on-premises without changing the Fractal definition. The resolution happens at instantiation time based on the target environment.

The Composition Hierarchy: Atom → Molecule → Fractal

Components are composed into increasingly complex structures using a three-level hierarchy.AtomThe smallest, indivisible unit ofinfrastructure. An Atom wraps a raw cloud resource with everything needed to make it production-ready: security hardening, monitoring hooks, backup policies, compliance tags.An Atom is not a raw cloud resource. A raw EC2 instance is a resource. An Atom wraps it with your organization's standards so every instance starts with the right configuration, the right policies, the right monitoring.Examples: a Kubernetes cluster, a PostgreSQL database, a Kafka broker.MoleculeA composed group of Atoms connected by Links. Represents a functional building block.Example: a "web tier" Molecule = Kubernetes cluster + load balancer + API gateway, all wired together.FractalA complete, deployable architecture pattern composed of Atoms and Molecules. Represents a full infrastructure stack: compute, storage, networking, messaging, observability; all defined, connected, and governed.The hierarchy is recursive a Fractal can contain other Fractals:

Links: How Components Connect

A Link is a connection between two components that carries semantic meaning. It's not just "these two things are connected" it specifies how they interact.Links include parameters, based on the components they connect:🔷 A Storage link between a compute component and a storage component specifies access mode (read, write, readWrite), data format (JSON, Parquet, Avro), consistency level;🔷 A Messaging link between a compute component and a broker component specifies role (producer, consumer), delivery semantics (at-most-once, at-least-once, exactly-once), consumer group🔷 A Network link between IaaS components specifies protocol (HTTP, gRPC, TCP), routes, authentication requirementsWhen a Fractal is deployed, the Fractal Automation Engine auto-configures all connections between components: security groups, IAM roles, connection strings, certificates. Developers don't wire anything manually.

Building a Fractal: The Three Phases

Creating a Fractal follows a clear three-phase model that maps to organizational roles. Let's walk through this using a concrete example: a 3-tier application with Kubernetes, PostgreSQL, and a web application workload.Prerequisites: Security & Governance FoundationBefore any Fractal exists, the Ops team sets up the governance boundaries.Step 1: Create a Resource Group. This is the logical governance boundary. Teams, users, and permissions are all managed at this level.Step 2: Initialize the Environment. This connects a cloud environment to the Fractal Cloud control plane by installing a Cloud Agent.The Cloud Agent is a lightweight process deployed inside your cloud environment (AWS account, Azure subscription, GCP project). It works on a pull-based model:1. The agent polls the control plane: "What should my environment look like?"2. The control plane responds with the desired state3. The agent reads the actual state from infrastructure APIs4. The agent diffs desired vs. actual5. The agent reconciles: creating, updating, or removing resources6. The agent reports status back to the control planeThis pull-based architecture means no inbound firewall rules, no VPN, no stored credentials on the control plane. The agent uses local IAM roles and communicates outbound over HTTPS only.Phase A: Platform Engineer: Define the FractalThis is where you build the reusable construct.Step 1: Define the Blueprint. Choose which components make up your architecture. For a 3-tier app:🔷 'Compute.PaaS.Kubernetes' the compute layer🔷 'Storage.PaaS.PostgreSQL' the data layer🔷'CustomWorkloads.CaaS.KubernetesWorkload' the application workloadStep 2: Configure each component. Set the parameters that represent your organization's standards. For the Kubernetes cluster, this might include node pool sizes, IP ranges, autoscaling policies. For PostgreSQL, the schema, charset, and backup configuration.Step 3: Define Links between components. Wire the workload to the Kubernetes cluster (compute link) and to PostgreSQL (storage link with access mode and connection properties).Step 4: Define the Interface. Specify which parameters developers can configure when they instantiate this Fractal, and which operations are allowed on the resulting Live System. The Interface is what developers see everything else is abstracted away.Step 5: Version and publish. The Fractal is now available in the catalog.Phase B: Developer and/or Platform Engineer Instantiate the FractalDepending on how much freedom the organization wants to give the devs, these steps can be performed by either the platform engineer or the developer.The developer's workflow is minimal:1. Browse the Fractal catalog and select the 3-tier application Fractal2. Provide the required parameters: environment name, application repo, branch, runtime variables3. Request instantiation (via Web UI, SDK, or API) with selection of the target infrastructure: hyperscaler, regional cloud provider or on-prem.4. The Fractal Automation Engine validates, deploys, and wires everything together5. A Live System is created, complete, governed, and continuously managedNo IaC to write. No cloud console access needed. No ticket to open.

Two Approaches: Live-System First vs. Fractal First

Fractal Cloud supports two deployment strategies, depending on your maturity and goals.Live-System First focus on the end system for quick roll-outs. Best for PoCs and experimental projects. You describe your desired infrastructure state using pre-hardened components, and later extract a reusable Blueprint from the running Live System.Fractal First focus on reusability and governance from the start. Best for establishing a cloud adoption framework at enterprise level. You define Blueprints and Interfaces upfront, and teams instantiate them without needing cloud environment access.For most organizations starting out, the advice is: start Live-System First with a concrete use case, validate the model, then extract a Fractal and scale from there.

SDK Integration

Fractals can be defined and managed programmatically using the SDK. This is the path for teams that want Fractals-as-code versioned in Git, tested in CI, deployed in pipelines.Available SDKs:🔷 Java SDK ('fractal-java-sdk')🔷 TypeScript SDK ('fractal-ts-sdk')🔷 Terraform Provider ('terraform-provider')🔷 REST API for integrating with existing enterprise toolsSDK authentication uses service accounts stored in cloud-native secret stores (Azure Key Vault, AWS Secrets Manager, GCP Secret Manager). Secret naming is consistent across all providers, so the SDK experience is unified regardless of the target cloud.The typical SDK workflow for a platform engineer:1. Authenticate with the management environment2. Define the Fractal programmatically: components, links, parameters3. Publish the Fractal to the catalog4. Developers instantiate it via SDK calls, API, or pipeline triggers

Why This Matters

The difference between a Fractal and a traditional IaC template comes down to three things.Lifecycle. A Terraform module runs and produces a state file. A Fractal produces a Live System that is continuously monitored, drift-corrected, and governed. Infrastructure doesn't exist in a vacuum it changes, and the platform has to account for that.Abstraction. Developers don't write IaC. They don't need to know about VPCs, security groups, or IAM policies. They consume a governed construct that encodes the expertise of the platform team.Scalability. A Fractal defined once can be instantiated thousands of times across multiple clouds. Updates to the Blueprint propagate to all derived Live Systems. The platform team's impact scales without their workload scaling.

Wrapping Up

A Fractal is not a template. It's a governed, versioned, composable infrastructure construct that encodes your organization's expertise into a reusable asset.Key takeaways:🔷 The Component → Service → Offer model makes Fractals cloud-agnostic at the definition level while fully leveraging provider-specific services at the implementation level🔷 The Atom → Molecule → Fractal hierarchy lets you compose infrastructure from hardened building blocks🔷 Links carry semantic meaning the platform auto-configures connections, security, and credentials🔷 The pull-based Cloud Agent architecture means zero inbound firewall rules and continuous drift reconciliation🔷 Two approaches: Live-System First for quick wins, Fractal First for enterprise-scale governanceReady to build your first Fractal?Check out the docs and start with the guided tutorial.Build Faster, Run Anywhere.

Frequently asked questions

What is the difference between an Atom, a Molecule, and a Fractal?

An Atom is a single hardened resource, for example a Kubernetes cluster or a database, already configured to production standards. A Molecule connects several Atoms into a functional unit through typed links: a web tier made of a cluster, a load balancer and an API gateway wired together, with the security groups and routing implied by those connections configured automatically. A Fractal assembles Atoms and Molecules into a complete deployable architecture. The hierarchy is recursive, so a Fractal can contain other Fractals, and a rule attached to an Atom applies to every system built from it. If the Kubernetes Atom requires pod security admission, every system containing that cluster has it, by construction rather than by review.

What is the Component → Service → Offer model?

The Component → Service → Offer model separates infrastructure into three abstraction levels. A Component defines the required capability, a Service specifies the delivery model, and an Offer maps that capability to a provider-specific implementation. An example: the Component is Container Platform, the Service is Kubernetes, and the Offer is EKS on AWS, AKS on Azure or managed Kubernetes on Hetzner. The definition names the Component. The Offer is resolved at deployment time from the target provider, which is why one definition works on more than one cloud.

What is a Cloud Agent?

A Cloud Agent is a lightweight process that runs inside the customer's own cloud environment. On each cycle it reads the desired state from the control plane, reads the actual state from the cloud provider's API, compares the two and reconciles the difference. It works with the customer's own IAM roles and service accounts, so the control plane never stores cloud credentials. It talks to the control plane through outbound connections only: no inbound access, no open ports or VPN.

What is the difference between a Blueprint and a Fractal?

A Blueprint defines the versioned structure of an infrastructure system, including its components and integrations. A Fractal extends the Blueprint by adding a versioned Interface that defines the operations allowed across the infrastructure lifecycle. When instantiated, a Fractal becomes a governed Live System. The Blueprint says what the system is made of, for example a Kubernetes cluster, a managed database, a load balancer and the network rules between them. The Interface says what a team may do with it afterwards, for example scale the cluster and add a namespace, but not disable encryption or open the network. The Fractal is the two together, which is why it can be operated over time and not only described.

More articles

The metric CTOs never look at: the average age of infrastructure debt

The metric CTOs never look at: the average age of infrastructure debt

A CTO watches uptime, team velocity, and the monthly cloud bill. Those three are easy to watch: they update themselves, they have dashboards, and they compare month over month without anyone building anything.Now try to answer a different question from those same three dashboards. For each production environment, how long has it been since it last matched the definition it was built from? Uptime cannot tell you. Velocity measures the code your teams ship, not the infrastructure they stopped touching. The bill goes up when things are neglected, not down, so it does not even point in the right direction.That question has a measurable answer, and almost nobody measures it.

Diagram showing how a shared operating model aligns development and operations teams through Platform Engineering.

How to Align Dev and Ops Without Adding More Tools

Aligning infrastructure teams and development teams comes down, first of all, to the operating model. Tools matter, but on their own they explain little of what slows delivery down.Over the past few years almost every organization has tried to speed up delivery by adopting cloud, containers, and CI/CD pipelines. The outcome tends to repeat itself: developers want to move fast, while whoever runs the infrastructure has to guarantee security, compliance, and cost control. A structural conflict follows, where developers experience controls as a brake and Ops read team autonomy as a risk.There is a fairly precise way to measure that conflict: the cognitive load on developers, meaning how much they have to hold in their head before they can ship. When every team needs Kubernetes, Terraform, IAM policies, and the quirks of each provider, the time spent wiring infrastructure together is time taken from the product. Gartner estimates that by 2026, 80% of large software organizations will have a dedicated platform engineering team, up from 45% in 2022.The useful question, then, is how to design a system where speed and governance stop competing. It is the question Fractal Cloud was built around, and it deserves a general answer before a product one.

Why Great Observability Still Wakes You Up at 3 AM

Why Great Observability Still Wakes You Up at 3 AM

Closing the Loop Between Observability and InfrastructureMost organizations have good observability. They know within seconds when something breaks. And then someone gets paged.Alerts fire into runbooks, runbooks require humans, and humans are a bottleneck. The industry spent a decade solving the seeing problem. The acting problem is still largely manual.According to ITIC 2024 analysis, every minute of downtime costs a data center an average of $9,000. Speed and precision of response are not an operational detail: they are the factor that determines the final cost.There are two reasons this persists: operational data is fragmented across tool silos, so no single system has the full picture; and organizations don't trust automation they can't explain. Both problems need the same fix: a layer that contextualizes events across the full system, reasons deterministically about what to do, and executes infrastructure changes with full traceability.