Table of Contents

• Introduction
• IaC Evolution Timeline
• IaC Comparison At-a-Glance
• OpenTofu: The Open Source Terraform Alternative
• Crossplane: Kubernetes-Native Infrastructure
• Pulumi: Infrastructure as Actual Code
• Choosing the Right Tool
• Quick Start Guide
• Common Pitfalls to Avoid
• FAQ
• Conclusion

Introduction

In today's rapidly evolving cloud-native landscape, Infrastructure as Code (IaC) has transformed from a novel concept to an essential practice. As organizations embrace DevOps and platform engineering principles, selecting the right IaC tool becomes increasingly critical for operational success.

Who is this guide for? Platform engineers, DevOps practitioners, and technical decision-makers who need to select an appropriate IaC tool for their organization's needs.

This guide provides a focused comparison of three leading IaC tools—OpenTofu, Crossplane, and Pulumi—examining their architectures, capabilities, and ideal use cases.

🤔 Have you already started implementing Infrastructure as Code in your organization? What challenges are you facing?

IaC Evolution Timeline

Before diving into specific tools, let's understand how infrastructure management has evolved:

DevOps → SRE → Platform Engineering

1. DevOps established fundamental principles:

   • Cross-functional collaboration
   • Infrastructure defined as code
   • Automation of repetitive tasks
   • Rapid feedback loops for continuous improvement

2. Site Reliability Engineering (SRE) applied DevOps with emphasis on:

   • System reliability and service level objectives
   • Error budgets and acceptable failure rates
   • Customer experience focus
   • Incident response and postmortem analysis

3. Platform Engineering extended SRE concepts by focusing on:

   • Internal developer customers
   • Self-service capabilities
   • Integrated toolsets and abstractions
   • Developer experience optimization

IaC Comparison At-a-Glance

OpenTofu: The Open Source Terraform Alternative

OpenTofu emerged as a community-driven fork of HashiCorp Terraform following licensing changes. Now under the Linux Foundation with plans to join the CNCF, OpenTofu preserves the familiar HCL syntax while ensuring an open governance model.

Project Structure Example

my-opentofu-project/
├── main.tf           # Primary configuration file
├── variables.tf      # Input variable declarations
├── outputs.tf        # Output value declarations
├── modules/          # Reusable modules
└── environments/     # Environment-specific configurations

Code Example: AWS VPC Configuration

# Simple VPC example
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "${var.environment}-vpc"
    Environment = var.environment
    Project     = var.project_name
    ManagedBy   = "OpenTofu"
  }
}

# Create two public subnets
resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = "${var.region}${count.index == 0 ? "a" : "b"}"
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.environment}-public-subnet-${count.index + 1}"
  }
}

Key Architectural Concepts

1. Declarative Resource Definition: Define the desired state, and OpenTofu determines how to reach it
2. Provider Model: Plugins enable interaction with various cloud APIs
3. State Management: State file maps real-world resources to your configuration
4. Plan-Apply Workflow: Preview changes before applying them

When to Choose OpenTofu

• When you need compatibility with existing Terraform code
• When you prefer a declarative, configuration-based approach
• When you want an open-source tool with broad provider support
• When state management is acceptable for your use cases

🤔 What aspects of OpenTofu's approach most appeal to your team's workflow?

Crossplane: Kubernetes-Native Infrastructure

Crossplane extends Kubernetes by enabling it to provision and manage infrastructure resources across cloud providers. As a CNCF incubating project, it brings cloud resources into the Kubernetes resource model.

Project Structure Example

my-crossplane-project/
├── apis/                      # Custom resource definitions
├── package/                   # Package configuration
├── examples/                  # Example usage
└── infrastructure/            # Infrastructure definition

Code Example: PostgreSQL Database in AWS

# Define a PostgreSQL resource claim
apiVersion: database.example.org/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: production-db
  namespace: default
spec:
  parameters:
    storageGB: 50
    version: "13"
    tier: "medium"
  writeConnectionSecretToRef:
    name: production-db-conn

Key Architectural Concepts

1. Kubernetes Extension: Extends K8s API with custom resources for infrastructure
2. Composition-Based: Complex infrastructure composed from individual managed resources
3. Claim-Based Model: Developers "claim" infrastructure without understanding the complexity
4. Continuous Reconciliation: Controllers ensure actual state matches desired state

When to Choose Crossplane

• When you're already using Kubernetes for application deployment
• When you want to avoid state file management
• When you need a continuous reconciliation model
• When you want to provide self-service infrastructure to developers

🤔 If you're using Kubernetes, how would continuous reconciliation benefit your infrastructure management?

Pulumi: Infrastructure as Actual Code

Pulumi allows defining infrastructure using general-purpose programming languages like Python, TypeScript, and Go. This approach brings the full power of software development to infrastructure management.

Project Structure Example

my-pulumi-project/
├── __main__.py          # Main infrastructure code
├── Pulumi.yaml          # Project configuration
├── infrastructure/      # Infrastructure components
└── tests/               # Infrastructure tests

Code Example: AWS VPC in Python

import pulumi
import pulumi_aws as aws

# Create a VPC and subnets
vpc = aws.ec2.Vpc(
    "my-vpc",
    cidr_block="10.0.0.0/16",
    enable_dns_hostnames=True,
    enable_dns_support=True,
    tags={"Name": "my-vpc"}
)

# Create a public subnet
public_subnet = aws.ec2.Subnet(
    "public-subnet",
    vpc_id=vpc.id,
    cidr_block="10.0.1.0/24",
    availability_zone="us-west-2a",
    map_public_ip_on_launch=True,
    tags={"Name": "public-subnet"}
)

# Export the VPC ID
pulumi.export("vpc_id", vpc.id)

Key Architectural Concepts

1. General-Purpose Languages: Define infrastructure using familiar programming languages
2. Resource Model: Resources correspond to cloud provider offerings
3. Stack Management: Different environments managed as separate stacks
4. Testing Framework: Test infrastructure using familiar language testing frameworks

When to Choose Pulumi

• When your team has strong programming skills
• When you need to leverage programming language features (loops, conditionals)
• When you want to use the same language for infrastructure and applications
• When you need comprehensive testing of your infrastructure

🤔 Would using a familiar programming language improve your team's productivity with infrastructure code?

Choosing the Right Tool

Use this decision flow to help select the most appropriate tool for your situation:

Decision Flowchart

Consider these questions to determine which tool is right for you:

1. Are you already invested in Kubernetes?

   • Yes → Crossplane is likely a good fit
   • No → Continue to question 2

2. Do you have existing Terraform configurations?

   • Yes → OpenTofu provides the smoothest transition
   • No → Continue to question 3

3. Does your team prefer programming languages over configuration languages?

   • Yes → Pulumi is probably your best choice
   • No → OpenTofu offers a simpler learning curve

Quick Start Guide

OpenTofu Quick Start

Installation:

brew install opentofu/tap/opentofu

First Project: OpenTofu Getting Started Tutorial

Community Resources: OpenTofu Community Forum

Crossplane Quick Start

Installation:

kubectl create namespace crossplane-system
helm install crossplane --namespace crossplane-system crossplane-stable/crossplane

First Project: Crossplane Getting Started Guide

Pulumi Quick Start

Installation:

curl -fsSL https://get.pulumi.com | sh

First Project: Pulumi Getting Started Guide

Common Pitfalls to Avoid

OpenTofu Pitfalls

• State File Corruption: Always use remote state storage with proper locking.
• Provider Version Conflicts: Pin provider versions explicitly.
• Module Management: Structure modules for reusability without excessive nesting.
• Blast Radius: Use workspace separation for critical environments.

Crossplane Pitfalls

• RBAC Complexity: Carefully plan your permissions model from the start.
• Composition Learning Curve: Start with simple compositions before tackling complex ones.
• Resource Drift: Understand how reconciliation handles manual changes.
• API Versioning: Plan for provider API version changes.

Pulumi Pitfalls

• Language-Specific Issues: Consider team expertise when choosing a programming language.
• State Management: Handle secrets properly in your state storage.
• Import Existing Resources: Have a strategy for importing existing infrastructure.
• Dependency Management: Address language-specific package management challenges.

Conclusion

Infrastructure provisioning has come a long way, with IaC tools playing a crucial role in automation and scalability. OpenTofu, Crossplane, and Pulumi each offer unique approaches, making them suitable for different use cases.

The best tool for your organization depends on your team's skills, existing investments, and specific requirements:

• OpenTofu: Best for teams with Terraform experience seeking an open-source alternative
• Crossplane: Ideal for Kubernetes-centric organizations wanting unified management
• Pulumi: Perfect for teams wanting to leverage programming language capabilities

As you evaluate these tools, consider starting with small, non-critical infrastructure components to gain experience before wider adoption.

What IaC tool are you using? Let us know your thoughts in the comments!

Further Reading:

• OpenTofu Documentation
• Crossplane Architecture
• Pulumi Programming Model
• CNCF Landscape: Provisioning Tools