[Fractal Sprint – Live Webinar | March 24] Beyond the Portal: Building a Governed Internal Developer Platform | Register now β†’

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

Cut the Wait. Reduce the Cost.
Keep Control.

More articles

From Weeks to Minutes: Combining Speed and Governance in Cloud Environments with Fractal Cloud

From Weeks to Minutes: Combining Speed and Governance in Cloud Environments with Fractal Cloud

The cloud promised instant scale, yet in many enterprise organizations, developers still wait days or even weeks for a new environment to be provisioned. The bottleneck is rarely technical; modern cloud providers have made resource allocation virtually instantaneous. What truly slows organizations down is the bureaucratic labyrinth of governance.Production environments must rigidly comply with security policies, architectural standards, observability requirements, and cost controls. Ensuring all these constraints are respected typically forces a slow-motion negotiation between infrastructure operators, platform engineering teams, and application developers. Without a unifying abstraction layer, every single deployment becomes a painful compromise between development speed and operational control.Fractal Cloud was engineered to obliterate this tradeoff. As a premier Internal Developer Platform (IDP), it delivers secure, universally compliant infrastructure across any cloud provider, setting a new standard for platform engineering. By equipping teams with ready-to-use building blocks that natively combine vendor-specific knowledge with security best practices, Fractal Cloud unlocks a frictionless developer experience. Organizations can finally transition from manual, ticket-based provisioning to a governed self-service model where fully compliant infrastructure is instantiated in minutes.Crucially, this frictionless experience does not force engineers to change how they work; it meets them where they are. While code-first developers can leverage a powerful SDK, the Internal Developer Platform also features an intuitive, elegantly designed Web interface to manage the entire resource lifecycle visually. Teams can visually browse a catalog of available building blocks, launch new environments, and manage running systems through guided workflows without writing a single line of code. Regardless of the interaction model chosen Web UI or SDK, both paths are strictly governed by the exact same architectural rules and abstractions.

Platform Engineering 2026: Beyond the Portal, Toward the Invisible Control Plane

Platform Engineering 2026: Beyond the Portal, Toward the Invisible Control Plane

Looking back at 2024, we remember the obsession with "UI-first thinking." At the time, many companies fell into the trap of confusing the interface with the platform, spending months implementing developer portals (like Backstage) without first resolving the underlying fragmentation.It is precisely to overcome this confusion between interface and platform that solutions like Fractal Cloud are born as a control plane first, rather than just a visible product. Today, in 2026, we know that the portal is just a view, not the substance.Platform Engineering has matured, transforming from the management of integrated toolchains into a product discipline. The Internal Platform is no longer an agglomeration of scripts and services, but a proper product with a roadmap, stable APIs, clear ownership, and a governed lifecycle.In Fractal Cloud, the platform is a governed product: every exposed capability is deliberately limited, versioned, and traceable.The driver for this evolution was the need to manage a level of complexity that is no longer compressible by humans alone. Between provider fragmentation, AI costs, and supply chain security, the cognitive load on the individual developer became unsustainable. In 2026, the Platform does not serve to "facilitate" via graphical interfaces; it serves to ensure determinism.Here is how the discipline has evolved and why the Internal Developer Platform (IDP) of the future is, first and foremost, an operating model.

Architecture diagram showing Fractal Cloud enabling cloud sovereignty by controlling data, applications, and operational processes without vendor dependency

Absolute Autonomy: Why Cloud Sovereignty Allows No "Grey Areas"

In the debate over IT modernization, a comfortable yet dangerous narrative has taken hold: the idea that cloud sovereignty is a spectrum, a scale of greys where "a little compliance" is still a step in the right direction.