[On-Demand Webinar] Fractal Sprint: Automation, Security and Multi-Cloud in One Platform | Watch Now →

Fractal Cloud
Blog
Abstract illustration representing a modular infrastructure component model with interconnected blocks and circuit-style connections.

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.Build Faster, Run Anywhere.

Cut the Wait. Reduce the Cost.Keep Control.

Get StartedBook a Demo

More articles

When Your Digital Twin Has Hands

When Your Digital Twin Has Hands

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.

Composable cloud architecture with modular infrastructure and governance components in Fractal Cloud

Composable Architecture: How to Build Platforms That Scale Without Multiplying Complexity

There's a pattern that appears in every infrastructure organization that has grown without a deliberate architectural philosophy.Twelve different Kubernetes configurations. Four different ways to define a database. Three different networking approaches. None of them wrong. None of them the same.The platform team spends more time understanding what's already running than building what should run next. New systems aren't built they're spawned from the nearest available precedent, carrying forward every quirk and accidental decision of whatever they were copied from.This post is about the architectural model that improves this cycle: composability. For platform engineers and architects who are tired of complexity accumulating faster than they can manage it.

Illustration of Fractal Cloud orchestrating infrastructure components, highlighting how internal platforms can become bottlenecks

When Internal Platforms Become Bottlenecks

Over the last decade, many organizations have embraced Platform Engineering as a way to accelerate software delivery.The promise is compelling: build an internal platform that provides developers with standardized tools, infrastructure, and automation so they can focus on building applications instead of managing environments.In theory, this should increase productivity, improve governance, and reduce operational overhead.In practice, things are often more complicated.