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

Fractal Cloud

Beyond YAML: How an SDK Elevates Infrastructure as Code to a True Software Engineering Discipline

Comparison diagram between traditional YAML-based infrastructure configuration and an SDK-based software engineering approach

Introduction

For years, Infrastructure as Code (IaC) has promised us the ability to manage cloud complexity with the same efficiency as application code. Tools based on declarative languages and YAML configuration files have revolutionized the way we work, allowing us to define our desired state. But let's be honest: how many times have we found ourselves copying and pasting hundreds of lines of YAML, only to change a couple of values? How often have we fought with the syntax of a loop in a configuration language or skipped writing a test because "it's just config"?This approach, while powerful, has forced us to operate with a limited set of tools. Complex logic, reusability, and testability remain painful. It gave us the "Code" part of IaC, but it deprived us of the "Engineering" part.What if we could overcome these limits? What if we could define our infrastructure using the same power, flexibility, and patterns we use to build our business applications? This is the paradigm shift that an SDK in a true programming language brings to the table.

The Limit of Static Declarative Languages

Static configuration files (YAML, JSON, and other declarative languages) are excellent for defining a state. But they fail miserably when they need to define the logic to get to that state.The result is a widespread "anti-pattern": the proliferation of scripts (Bash, Python) that "generate" the YAML or configuration files. We've created an extra layer of complexity just to compensate for the shortcomings of our IaC tool, introducing fragility and making the process even more opaque.When infrastructure is defined in a full-fledged programming language, this superstructure disappears. The language itself becomes the tool for managing complexity.

1. Forget Copy-Paste: Create True Libraries

The biggest problem with traditional IaC is the lack of abstraction. If you want to create three (dev, staging, prod) environments that are almost identical, you often end up with three almost identical folders.With an SDK, you can stop thinking in terms of "files" and start thinking in terms of "objects" and "libraries."Instead of copying 200 lines of YAML for a database, a security and compliance expert can create a reusable class, for example, SecureProdDatabase. This class, once written, encapsulates all the business logic and corporate policies: backups enabled, encryption at rest, advanced monitoring, and restrictive firewall rules.From that moment on, anyone in your organization who wants a compliant database doesn't need to read a 50-page manual. They just need to instantiate that object in their program. Governance and best practices are no longer a document to be checked off a list; they are codified within a reusable and maintainable software construct.

2. Apply Design Patterns: The Builder Example

Configuration languages don't have the concept of "design patterns." Programming languages live by them. Think about creating a complex infrastructure component with many options, some mandatory and some optional. In YAML, this translates into a massive file full of comments trying to explain what's optional.In a programming language, this is a problem solved decades ago: the Builder Pattern.With an SDK, you can define the creation of your infrastructure in a fluent and readable way, with self-explanatory methods like:The IDE (Integrated Development Environment) itself guides you, suggesting available options and flagging errors if you forget a mandatory parameter.This isn't just an aesthetic choice. It's a fundamental change in the Developer Experience (DevEx). The code becomes:🔷 Fluent and readable: The intent is clear.🔷 Safe: The constructor can validate the data. You can't misspell a property.🔷 Maintainable: Adding a new option just means adding a new method to the Builder.

3. Manage Dependencies with Type Safety

In traditional IaC, dependencies are managed with strings, for example: depends_on = "my_db_instance". This is fragile. If you rename "my_db_instance" to "primary_database", the dependency breaks, and you only find out during a “plan” or, worse, an “apply”.In a programming language, dependencies are object references, not strings.When you create your web application, you pass the database object directly to the constructor or builder of the webApplication object. The underlying framework instantly understands the relationship. But the biggest advantage is that if you rename the database variable, your IDE automatically updates the reference. The compiler itself becomes your first infrastructure validation tool.You get type safety applied to your cloud infrastructure, eliminating an entire class of runtime errors.

4. Testability Becomes a Reality

Finally, true "engineering" requires tests. Testing YAML files is nearly impossible without deploying them. But how do you test a software class? With a unit testing framework.For the first time, you can perform true unit testing on your infrastructure, before ever talking to a cloud API.You can write a test that, in milliseconds and on your local machine, creates an in-memory instance of your SecureProdDatabase and asserts that backups are enabled by default and that the firewall rules are correct. You can test complex logic, conditionals, and loops, just as you would for any other critical software.This shifts error detection far to the left (a true shift-left) in a way that static configuration files never could.

From "Configurators" to "Engineers"

Using an SDK in a full-fledged programming language to define infrastructure doesn't just mean writing Java instead of YAML. It means changing your mindset.It means stopping being cloud "configurators" and starting to be cloud systems "engineers." It means applying decades of software engineering best practices, abstraction, encapsulation, patterns, testability, to one of the most critical parts of our stack.This approach transforms Infrastructure as Code from a manual, error-prone task into a true software discipline, managed with the same robustness and scalability as the application code it supports.Build Faster. Run Anywhere.

Frequently asked questions

What are the limitations of traditional Infrastructure as Code?

Infrastructure as Code solved a real problem: infrastructure became described, versioned and repeatable. Its limits show up with scale rather than with correctness. Configuration languages offer little support for the practices that keep a large codebase manageable: abstraction, shared libraries, type checking, design patterns, unit tests. The usual result is copy and paste between modules, glue scripts around the tool, and a growing amount of code that only one or two people fully understand. The tooling is not wrong. It was built to describe infrastructure, and it is being asked to model it.

What are the benefits of using an SDK for Infrastructure as Code?

An SDK allows infrastructure to be defined using a general purpose programming language instead of configuration files. Developers can build reusable libraries, apply software design patterns, validate infrastructure through type safety, and write unit tests, making Infrastructure as Code easier to maintain, extend, and scale.

Why use a programming language instead of YAML for Infrastructure as Code?

YAML is effective for describing configuration, but managing complex infrastructure often requires abstraction, composition, validation, and reusable logic. As infrastructure grows, large configuration files can become difficult to maintain and evolve. A programming language allows infrastructure to be modeled as software, making complex systems easier to organize, test, extend, and maintain.

What makes Fractal Cloud different from traditional Infrastructure-as-Code (IaC) approaches?

Fractal Cloud eliminates the need for handwritten IaC scripts by offering a Java SDK and pre-approved, composable modules maintained by platform teams. This enables faster, more consistent, and governed infrastructure delivery without relying on low-level scripting.

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.

Day 2 Operations
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.

Platform Engineering
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.

Day 2 Operations