Blog
Fractal Architecture: a Component Model for Secure, Governed and Ready-to-Use Infrastructure.

Fractal Architecture: a Component Model for Secure, Governed and Ready-to-Use Infrastructure.

Introduction

Fractal Architecture is a Platform Engineering model designed for simplifying infrastructure definition for complex, multi-cloud, and regulated enterprise environments.It enables development teams to operate with declarative autonomy within a secure, versioned, and governed infrastructure system.Through a composable, automated, and compliance-by-design approach, it reduces operational debt and accelerates platform evolution.Fractal Cloud implements this model by transforming infrastructure into a system of modular, versioned components that are automated and mapped to shared policies.

A Component Model for Platform Engineering

In this model, Fractals are modular, composable infrastructure components, each carefully designed, owned, and governed by the Infrastructure Teams. These teams establish the guardrails, enforce policies, and define clear input boundaries for each Fractal, ensuring consistency, compliance, and operational safety.Development Teams do not build or modify Fractals. Instead, they use them declaratively to define the infrastructure their applications need, without diving into low-level implementation details. Fractals act as abstractions that encapsulate best practices, enabling developers to self-serve common infrastructure patterns safely and efficiently.This model allows infrastructure to be flexible where needed and opinionated where necessary, aligning platform capabilities closely with real application demands, while maintaining centralized control, security, and maintainability.

A formal definition of the component model

A Fractal is a platform component constituted of two fundamental entities:· a Blueprint: a versioned collection of components and integrations that defines the structure and dependencies of the infrastructure system.· an Interface: a versioned set of operations that allows the Fractal to be safely extended or specialized. Each operation must result in a compliant target system.A Fractal is instantiable, meaning it can be deployed multiple times using different combinations of technologies and vendor-specific implementations. The outcome of this instantiation is known as a Live System, an operational infrastructure system deployed using the selected cloud vendor services.

A Practical Application

Let’s consider an organization migrating to a Microservice Architecture. As depicted in the figure above, the foundational elements of such an architecture often include an API Gateway, a security layer governing the service mesh, Backend for Frontend (BFF) components, and domain services communicating via a message broker.All of these components form the Blueprint, which acts as the immutable backbone of your microservice ecosystem.

Blueprint: The Core infrastructure

To identify the components that are part of the Blueprint, consider the elements that remain consistent across different applications sharing the same architectural style, as depicted in the following diagram.While the Blueprint defines the static foundation of a Fractal, the Interface brings it to life.

Interfaces: Operationalizing the Blueprint

Interfaces are where the real dynamism and adaptability of Fractal Architecture emerge, enabling the infrastructure to evolve in response to application-specific requirements.In our ongoing microservices example, consider how your organization may need to support new device types or user interfaces. This often demands the deployment of new Backend for Frontend (BFF) services or modifications to existing ones. Instead of relying on manual provisioning, Interface operations can automate the deployment and reconfiguration of the BFF services, updates to routing, security, and observability layers.Similarly, as your business evolves, so must your domain services, the core of your microservice architecture. Interface operations can be used to deploy new domain services, manage service lifecycle, seamlessly integrate services into the service mesh, with appropriate access controls and observability instrumentation.

Declarative and Compliant Self-Service

Fractals are declarative, versioned, and governed.Development Teams use them to define the infrastructure they need, without accessing or modifying their internal structure. Provisioning is fully automated within secure and traceable boundaries.This model enables:· controlled system composition, by granularly administrating access control to Fractals, Live Systems and the Environments on which they are deployed;· automated provisioning through the Fractal Automation Engine;· structured reuse of components and configurations;· continuous evolution without disruption;· standards and security embedded in the model.

How is it done?

The Development Experience CoE (whose responsibility at times falls within the Platform Team) enables standard Fractals among the ones ready to be used within Fractal Cloud or composes and publishes bespoke ones, even containing bespoke components (in this case through the necessary collaboration of Infrastructure Specialists).These Fractals can then be safely used by the Development Teams without further verification or audit. These Fractals are safe to be used and are automatically instantiated and maintained within environments that do not require any access from the Developers.When needed, CoEs and Development Teams can collaborate for the creation of new Fractals (for instance Streaming Architecture, Event-Driven Architecture, etc.).

Platform and Landing Zones

The model applies to both main categories of infrastructure systems:· Platform: preconfigured, centrally governed management environments, designed as specialized Fractals and usually both owned and instantiated by the Centers of Excellence. They provide secure and consistent foundations for the Landing Zones of the Development Teams.· Landing Zones: operational systems derived from Fractals usually owned by the Centers of Excellence but instantiated and operated by the Development Teams.This distinction enables a federated operating model: centralized foundations with localized autonomy in system management.Here is an example of a Fractal Architecture implementation in an Azure environment.The image shows a cloud architecture structured according to Microsoft Azure Cloud Adoption Framework (CAF). In traditional models, the complexity of this setup falls entirely on infrastructure and platform teams. Fractal Cloud removes this burden by automating security, governance, and environment configuration requirements following the Cloud Vendor best practices, in this specific example the Azure CAF, without asking the CoEs or the Development Teams to write a single extra line of Infrastructure as Code (IaC). Although the example is based on Azure, the same approach applies to AWS, GCP, and OCI, thanks to the cloud-agnostic nature of the Fractal Architecture model, Fractal Cloud implements transparently the Well-Architected Framework, the Google CAF, and Oracle CAF respectively.

Fractal Automation Engine: Continuous Automation and Compliance

The Fractal Automation Engine manages the lifecycle of Fractals, applying controls, versioning, and updates in a continuous and compliant manner.The Fractal Automation Engine manages the full infrastructure lifecycle. Mirroring the principles of GitOps, the Fractal Agent is deployed within the CSPs’ environments, using their own integrated Identity and Access Management (IAM) solutions. It continually pulls configuration from the CMDB system, aligning the actual infrastructure state with the expected state.It adopts the Operator Pattern, a pattern extensively used in orchestration platforms, like Kubernetes, but exploded to cover the full breadth of services offered by the supported Cloud Vendors. Adoption of the Operator Pattern brings several key benefits to the Fractal Automation Engine:· Automated Management: it automates the management of applications and their components, ensuring that the system continually reflects the desired state;· Continuous Monitoring: operators continually monitor the state of their resources, reacting to changes and discrepancies in real time;· Rollback Capabilities: operators can automatically revert unauthorized manual changes, maintaining system integrity and compliance;· Exception Handling: in maintenance scenarios, where manual configurations are necessary, the Operator can intelligently pause or alter synchronization to accommodate these exceptions (as for situation requiring Just-in-Time production access).

An Architecture Designed to Evolve

All components in Fractal Cloud are versioned and centrally governed.Fractals can be updated or replaced with compatible versions, ensuring continuity for active instances.This approach:· prevents the proliferation of unauthorized variants;· supports continuous platform evolution;· ensures stability, traceability, and auditability;· reduces operational overhead and risks from manual configuration.Fractal Architecture transforms infrastructure into a composable, reusable, and compliance-by-design capability.An operating model that balances autonomy and control, accelerates cloud adoption, reduces risk, and simplifies governance.Fractal Cloud makes this new approach available for your enterprise today.Code Faster, Run Anywhere.

More articles

What "Cloud-Agnostic" Really Means in 2025 (And Why It's Not What You Think)

What "Cloud-Agnostic" Really Means in 2025 (And Why It's Not What You Think)

"Cloud-Agnostic" is one of the most seductive and misunderstood buzzwords in our industry. For years, we've been sold a utopia: the promise of building an application once and then freely moving it between AWS, Azure, and GCP with a single click, as if they were interchangeable utilities.In 2025, it's time to say it clearly: this idea no longer reflects the complexity of real-world cloud architectures.Chasing the "run anywhere" myth leads companies to build bland, lowest-common-denominator systems that fail to leverage the true power of any cloud. You end up paying the price of the cloud without enjoying its main benefits.But this doesn't mean the idea is worthless. It just means the real value isn't where we've been told to look. True "cloud-agnostic" isn't about implementation portability; it's about architecture standardization.

Announcing Hetzner Cloud support in Fractal Cloud

Announcing Hetzner Cloud support in Fractal Cloud

Today we are adding Hetzner Cloud to Fractal Cloud. Teams that choose Hetzner for European sovereignty can now provision secure, production‑ready Kubernetes and move workloads across vendors with a single, automated workflow. The result is developer self service with governance built in, and a clear path to sovereign multicloud without lock in.

Designing for Resilience: from Disaster Recovery to Strategic Advantage

Designing for Resilience: from Disaster Recovery to Strategic Advantage

In cloud engineering, there is a fundamental truth: systems fail. It's not a matter of "if," but "when." Provider Service Level Agreements (SLAs), with their "nines" (99.9%, 99.99%), are not a promise of infallible uptime; they are the contractual guarantee that failures, however rare, are an expected part of the service.The "Shared Responsibility" model is clear: the provider is responsible for the reliability of the infrastructure, while we are responsible for the reliability of our applications running on it.When a core service or an entire region goes offline, it's not a "betrayal." It's an expected operational event. The real question isn't why it happened, but how we respond.

Cut the Wait. Reduce the Cost.
Keep Control.

Fractal Cloud helps your teams deliver faster across any cloud, without the complexity.Sign up or book a demo to see how.