Alternatif Terraform #

Terraform memang populer, tapi bukan satu-satunya pilihan di dunia Infrastructure as Code. Setiap tool IaC punya filosofi, kekuatan, dan trade-off yang berbeda. AWS punya CloudFormation yang terintegrasi mendalam dengan ekosistemnya. Pulumi dan CDK memungkinkan kamu menulis infrastruktur dalam bahasa pemrograman umum. Ansible mengambil pendekatan berbeda dengan agentless automation. Crossplane membawa infrastruktur ke dalam Kubernetes. Dan OpenTofu muncul sebagai respons terhadap perubahan lisensi HashiCorp.

Memilih tool yang tepat bukan soal mana yang paling populer, tapi soal mana yang paling sesuai dengan konteks tim, proyek, dan arsitektur yang sedang kamu bangun. Artikel ini membahas secara mendalam masing-masing alternatif — dengan contoh kode nyata, tabel perbandingan, dan panduan untuk mengambil keputusan.

AWS CloudFormation #

CloudFormation adalah layanan IaC native dari AWS. Dirilis pertama kali pada 2011, CloudFormation mendukung hampir semua layanan AWS dan terintegrasi langsung dengan API AWS tanpa perlu provider terpisah.

Cara Kerja CloudFormation #

CloudFormation menggunakan template dalam format JSON atau YAML untuk mendefinisikan resource. Setiap template di-upload ke AWS, dan CloudFormation yang bertanggung jawab untuk membuat, mengubah, dan menghapus resource sesuai definisi.

# cloudformation-template.yml
AWSTemplateFormatVersion: '2010-09-09'
Description: Web server infrastructure

Parameters:
  Environment:
    Type: String
    AllowedValues:
      - staging
      - production
    Default: staging

  InstanceType:
    Type: String
    Default: t3.medium

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-vpc

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: ap-southeast-1a
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-public-subnet

  WebServerSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Web server security group
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: ami-0abcdef1234567890
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref WebServerSG
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-web-server

Outputs:
  ServerPublicIP:
    Description: Public IP of the web server
    Value: !GetAtt WebServer.PublicIp

Kelebihan CloudFormation #

Tanpa biaya tambahan. CloudFormation gratis — kamu hanya membayar resource yang dibuat, bukan tool-nya. Berbeda dengan Terraform Cloud yang punya tier berbayar.

Integrasi AWS mendalam. Ketika AWS merilis layanan baru, support CloudFormation biasanya sudah tersedia sejak hari pertama. Kamu tidak perlu menunggu provider update seperti di Terraform.

Drift detection. CloudFormation punya fitur drift detection yang bisa mendeteksi perubahan manual pada resource yang dikelola oleh stack.

Rollback otomatis. Kalau ada error saat membuat atau mengupdate stack, CloudFormation otomatis rollback ke state sebelumnya.

Kekurangan CloudFormation #

Vendor lock-in AWS. Template CloudFormation hanya bisa digunakan untuk resource AWS. Kalau kamu punya infrastruktur multi-cloud, kamu butuh tool terpisah untuk masing-masing cloud provider.

Sintaks verbose. Template CloudFormation cenderung sangat panjang dibanding Terraform. Sebuah VPC dengan beberapa subnet, route table, dan NAT Gateway bisa memerlukan 200+ baris YAML di CloudFormation dibanding 50-70 baris HCL di Terraform.

Kurva pembelajaran intrinsic function. Fungsi seperti !Ref, !Sub, !GetAtt, !If, !Select kuat tapi membingungkan bagi pemula.

flowchart LR
    subgraph CF["CloudFormation"]
        C1["Template YAML/JSON"] --> C2["Upload ke AWS"]
        C2 --> C3["CF buat/mengubah\nresource"]
        C3 --> C4["Stack terbentuk"]
    end

    subgraph TF["Terraform"]
        T1["Config HCL"] --> T2["terraform plan"]
        T2 --> T3["terraform apply"]
        T3 --> T4["Resource + State"]
    end

    CF --> CF_PRO["✓ Native AWS\n✓ Drift detection\n✓ Rollback otomatis"]
    CF --> CF_CON["✗ Vendor lock-in\n✗ Sintaks verbose\n✗ Debugging sulit"]

    TF --> TF_PRO["✓ Multi-cloud\n✓ Sintaks ringkas\n✓ Plan/preview"]
    TF --> TF_CON["✗ Provider delay\n✗ Perlu install\n✗ State management"]

    style CF_PRO fill:#e8f5e9,stroke:#2e7d32
    style CF_CON fill:#ffebee,stroke:#c62828
    style TF_PRO fill:#e8f5e9,stroke:#2e7d32
    style TF_CON fill:#fff3e0,stroke:#e65100

Pulumi #

Pulumi mengambil pendekatan radikal: menulis IaC dalam bahasa pemrograman umum seperti TypeScript, Python, Go, dan C#. Ini berarti kamu bisa menggunakan semua fitur bahasa pemrograman — loops, conditionals, functions, classes, error handling, testing frameworks — yang tidak tersedia di HCL atau YAML.

Contoh Pulumi dengan TypeScript #

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Menggunakan TypeScript biasa
const config = new pulumi.Config();
const environment = config.require("environment");
const instanceType = config.get("instanceType") || "t3.medium";

// VPC
const vpc = new aws.ec2.Vpc(`${environment}-vpc`, {
    cidrBlock: "10.0.0.0/16",
    enableDnsHostnames: true,
    tags: { Name: `${environment}-vpc` },
});

// Subnet — bisa pakai loop!
const availabilityZones = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"];
const subnets = availabilityZones.map((az, i) => {
    return new aws.ec2.Subnet(`${environment}-subnet-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i + 1}.0/24`,
        availabilityZone: az,
        tags: { Name: `${environment}-subnet-${az}` },
    });
});

// Security Group dengan conditional rules
const ingressRules: aws.types.input.ec2.SecurityGroupIngress[] = [
    { protocol: "tcp", fromPort: 443, toPort: 443, cidrBlocks: ["0.0.0.0/0"] },
];

if (environment === "staging") {
    // Di staging, buka SSH untuk debugging
    ingressRules.push({
        protocol: "tcp", fromPort: 22, toPort: 22,
        cidrBlocks: ["10.0.0.0/8"],
    });
}

const sg = new aws.ec2.SecurityGroup(`${environment}-web-sg`, {
    vpcId: vpc.id,
    description: "Web server security group",
    ingress: ingressRules,
});

// EC2 Instance
const server = new aws.ec2.Instance(`${environment}-web`, {
    ami: "ami-0abcdef1234567890",
    instanceType: instanceType as aws.ec2.InstanceType,
    subnetId: subnets[0].id,
    vpcSecurityGroupIds: [sg.id],
    tags: { Name: `${environment}-web-server` },
});

// Export output
export const serverPublicIp = server.publicIp;
export const vpcId = vpc.id;

Kelebihan Pulumi #

Bahasa pemrograman umum. Kamu bisa menggunakan TypeScript, Python, Go, atau C#. Tidak perlu belajar bahasa baru. Testing bisa dilakukan dengan framework testing yang sudah kamu kenal (Jest, pytest, Go testing).

Abstraksi yang kuat. Dengan class, function, dan module bawaan bahasa pemrograman, kamu bisa membuat abstraksi yang lebih fleksibel dibanding Terraform module.

Component resource. Pulumi punya konsep “component resource” yang memungkinkan kamu membuat resource komposit yang terdiri dari beberapa resource — dengan interface yang bisa kamu definisikan sendiri.

Kekurangan Pulumi #

Complexity leakage. Bahasa pemrograman umum membawa kompleksitasnya sendiri. Debugging Pulumi error bisa sangat membingungkan karena error bisa datang dari infrastruktur atau dari kode program itu sendiri.

Kurang mature. Ekosistem provider Pulumi masih kalah luas dibanding Terraform. Beberapa resource AWS mungkin belum tersedia di Pulumi native provider.

State management. Pulumi menyimpan state di Pulumi Cloud (berbayar) atau di backend self-hosted yang memerlukan setup tambahan.

ANTIPATTERN vs BENAR (Pulumi):

ANTI-PATTERN:
  ✗ Menggunakan terlalu banyak abstraksi yang kompleks
    (class inheritance 5 level deep — sulit dipahami tim)
  ✗ Menulis IaC seperti menulis aplikasi biasa
    (terlalu banyak dynamic behavior yang unpredictable)
  ✗ Mengabaikan type safety yang ditawarkan TypeScript

BENAR:
  ✓ Gunakan abstraction sederhana yang bisa dipahami semua orang
  ✓ Manfaatkan type safety untuk mencegah error di level kode
  ✓ Tetap buat resource definition yang jelas dan readable
  ✓ Manfaatkan unit test untuk memvalidasi infrastruktur

AWS CDK #

AWS Cloud Development Kit (CDK) adalah framework yang memungkinkan kamu mendefinisikan resource CloudFormation menggunakan bahasa pemrograman umum. CDK pada dasarnya adalah “wrapper” di atas CloudFormation — kode yang kamu tulis di-compile menjadi template CloudTemplate.

Contoh CDK dengan TypeScript #

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as rds from 'aws-cdk-lib/aws-rds';
import { Construct } from 'constructs';

export class WebAppStack extends cdk.Stack {
    constructor(scope: Construct, id: string, props?: cdk.StackProps) {
        super(scope, id, props);

        // VPC dengan 2 Availability Zone
        const vpc = new ec2.Vpc(this, 'WebAppVPC', {
            maxAzs: 2,
            natGateways: 1,
            subnetConfiguration: [
                {
                    cidrMask: 24,
                    name: 'Public',
                    subnetType: ec2.SubnetType.PUBLIC,
                },
                {
                    cidrMask: 24,
                    name: 'Private',
                    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
                },
                {
                    cidrMask: 28,
                    name: 'Database',
                    subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
                },
            ],
        });

        // Security Group
        const webSg = new ec2.SecurityGroup(this, 'WebSG', {
            vpc,
            description: 'Security group for web servers',
            allowAllOutbound: true,
        });
        webSg.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443));

        // EC2 Instance
        const webServer = new ec2.Instance(this, 'WebServer', {
            vpc,
            instanceType: ec2.InstanceType.of(
                ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM
            ),
            machineImage: ec2.MachineImage.latestAmazonLinux2(),
            vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
            securityGroup: webSg,
        });

        // RDS Database
        const database = new rds.DatabaseInstance(this, 'AppDB', {
            engine: rds.DatabaseInstanceEngine.postgres({
                version: rds.PostgresEngineVersion.VER_15_4,
            }),
            vpc,
            vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
            instanceType: ec2.InstanceType.of(
                ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM
            ),
            multiAz: true,
            allocatedStorage: 20,
        });

        database.connections.allowFrom(webSg, ec2.Port.tcp(5432));
    }
}

CDK vs Pulumi #

CDK dan Pulumi sering dibandingkan karena keduanya menggunakan bahasa pemrograman umum. Perbedaan utama:

Kekurangan CDK #

Hanya untuk AWS. CDK hanya bisa membuat resource AWS melalui CloudFormation. Untuk multi-cloud, kamu butuh tool lain.

CloudFormation bottleneck. Karena di-compile ke CloudFormation, CDK mewarisi semua kelemahan CloudFormation — termasuk batasan 500 resource per stack dan error message yang tidak jelas.

Construct complexity. L1 (Cfn), L2 (high-level), dan L3 (pattern) constructs bisa membingungkan — terutama ketika L2 construct tidak mendukung fitur yang kamu butuhkan dan kamu harus “turun” ke L1.

Crossplane #

Crossplane mengambil pendekatan unik: membawa infrastruktur cloud ke dalam Kubernetes. Dengan Crossplane, kamu mendefinisikan resource cloud (seperti RDS, S3, EC2) sebagai Kubernetes custom resource, dan Crossplane yang menerjemahkannya ke API cloud provider.

Cara Kerja Crossplane #

# crossplane-rds.yaml — Definisi RDS di Kubernetes
apiVersion: rds.aws.crossplane.io/v1alpha1
kind: DBInstance
metadata:
  name: app-database
spec:
  forProvider:
    engine: postgres
    engineVersion: "15.4"
    dbInstanceClass: db.t3.medium
    masterUsername: admin
    allocatedStorage: 20
    storageType: gp3
    multiAZ: true
    vpcSecurityGroupIds:
      - sg-0123456789
    dbSubnetGroupNameRef:
      name: app-subnet-group
  providerConfigRef:
    name: aws-provider
  writeConnectionSecretToRef:
    name: app-database-conn
    namespace: crossplane-system

Kelebihan Crossplane #

GitOps native. Crossplane bekerja sangat baik dengan ArgoCD dan FluxCD. Kamu bisa mengelola infrastruktur menggunakan workflow yang sama dengan deployment aplikasi Kubernetes.

Composition. Crossplane punya konsep “composition” yang memungkinkan kamu membuat resource abstraksi tinggi tinggi (seperti “WebApp” yang terdiri dari EC2, RDS, dan S3) sebagai satu Kubernetes resource.

Self-service. Developer bisa request infrastruktur melalui Kubernetes manifest tanpa perlu tahu detail cloud provider.

Kekurangan Crossplane #

Hanya untuk tim yang sudah menggunakan Kubernetes. Crossplane memerlukan cluster Kubernetes yang berjalan — kalau kamu belum di Kubernetes, ini menambah kompleksitas.

Debugging sulit. Ketika terjadi error, kamu harus memeriksa Crossplane provider logs, Kubernetes events, dan cloud provider API — tiga layer yang berbeda.

Kurang mature. Ekosistem Crossplane masih berkembang. Tidak semua resource cloud tersedia dalam provider Crossplane.

flowchart TD
    A["Developer\nkubectl apply -f resource.yaml"] --> B["Kubernetes API Server"]
    B --> C["Crossplane Controller"]
    C --> D{"Resource\nType?"}
    D -->|"AWS"| E["AWS Provider"]
    D -->|"GCP"| F["GCP Provider"]
    D -->|"Azure"| G["Azure Provider"]
    E --> H["AWS API"]
    F --> I["GCP API"]
    G --> J["Azure API"]
    H --> K["Resource Terbuat"]
    I --> K
    J --> K

    style A fill:#e3f2fd,stroke:#1565c0
    style K fill:#e8f5e9,stroke:#2e7d32

OpenTofu #

OpenTofu adalah fork dari Terraform yang lahir sebagai respons terhadap perubahan lisensi HashiCorp dari MPL 2.0 ke BSL (Business Source License) pada Agustus 2023. OpenTofu di-maintain oleh Linux Foundation dan berkomitmen tetap open-source.

Perbedaan OpenTofu dengan Terraform #

OpenTofu saat ini sangat mirip dengan Terraform — menggunakan sintaks HCL yang sama, mendukung provider yang sama, dan sebagian besar workflow identik. Namun, ada beberapa fitur eksklusif yang ditambahkan OpenTofu:

State encryption. OpenTofu mendukung enkripsi state file di semua backend, bukan hanya di Terraform Cloud.

# opentofu-backend.tf — State encryption
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    # OpenTofu: client-side encryption
    # (Terraform hanya support S3 server-side encryption)
  }
}

Client-side state encryption. Enkripsi dilakukan di sisi client sebelum state dikirim ke backend — memberikan kontrol penuh atas kunci enkripsi.

Kapan Memilih OpenTofu #

OpenTofu layak dipertimbangkan jika:

• Lisensi BSL HashiCorp menjadi masalah untuk use case kamu
• Kamu butuh state encryption di semua backend
• Kamu ingin berkontribusi ke proyek open-source
• Kamu ingin fork protection dari perubahan lisensi di masa depan

ANTIPATTERN vs BENAR (OpenTofu):

ANTI-PATTERN:
  ✗ Memilih OpenTofu hanya karena "anti-HashiCorp"
    tanpa evaluasi fitur dan kebutuhan tim
  ✗ Menganggap OpenTofu 100% kompatibel dengan Terraform
    (ada fitur baru yang eksklusif di masing-masing)

BENAR:
  ✓ Evaluasi fitur yang kamu butuhkan (state encryption?)
  ✓ Cek kompatibilitas provider yang kamu pakai
  ✓ Pertimbangkan ecosystem dan community support
  ✓ Migrasi dari Terraform ke OpenTofu relatif mudah
    (ubah binary, hampir semua konfigurasi tetap berfungsi)

Framework Pengambilan Keputusan #

Memilih tool IaC bukan keputusan yang bisa diambil dalam 5 menit. Berikut framework yang bisa membantu:

flowchart TD
    A["Mulai: Pilih Tool IaC"] --> B{"Multi-cloud?"}
    B -->|"Ya"| C{"Tim tahu\nbahasa pemrograman\ndengan baik?"}
    B -->|"Tidak, AWS only"| D{"Sudah di\nKubernetes?"}
    B -->|"Tidak, GCP only"| E["Cloud Deployment\nManager / Terraform"]
    B -->|"Tidak, Azure only"| F["Bicep / Terraform"]

    C -->|"Ya, TypeScript/Python"| G["Pulumi"]
    C -->|"Tidak, prefer DSL"| H["Terraform / OpenTofu"]

    D -->|"Ya"| I{"Semua resource\ndi K8s?"}
    D -->|"Tidak"| J{"Perlu tight\nAWS integration?"}

    I -->|"Ya"| K["Crossplane"]
    I -->|"Tidak"| L["Terraform + K8s mix"]

    J -->|"Ya"| M["CloudFormation / CDK"]
    J -->|"Tidak"| N["Terraform / OpenTofu"]

    style G fill:#e8f5e9,stroke:#2e7d32
    style H fill:#e8f5e9,stroke:#2e7d32
    style K fill:#e3f2fd,stroke:#1565c0
    style L fill:#e3f2fd,stroke:#1565c0
    style M fill:#fff3e0,stroke:#e65100
    style N fill:#e8f5e9,stroke:#2e7d32
    style E fill:#fff3e0,stroke:#e65100
    style F fill:#fff3e0,stroke:#e65100

Pertimbangan Berdasarkan Skala Tim #

Pertimbangan Berdasarkan Kebutuhan Multi-Cloud #

Single cloud (AWS only): CloudFormation atau CDK paling optimal karena integrasi native. Terraform tetap bagus kalau kamu ingin konsistensi workflow dan opsi multi-cloud di masa depan.

Multi-cloud (AWS + GCP + Azure): Terraform atau Pulumi. CloudFormation dan CDK out karena hanya untuk AWS. Crossplane bisa jadi opsi kalau sudah di Kubernetes.

Hybrid (cloud + on-premise): Terraform atau Ansible. Terraform punya provider untuk VMware, bare metal, dan berbagai cloud provider. Ansible bisa menangani konfigurasi server di mana saja.

flowchart LR
    subgraph Single["Single Cloud"]
        S1["AWS → CloudFormation/CDK"]
        S2["GCP → Deployment Manager"]
        S3["Azure → Bicep/ARM"]
        S4["Atau → Terraform (lebih fleksibel)"]
    end

    subgraph Multi["Multi-Cloud"]
        M1["Terraform ✓"]
        M2["Pulumi ✓"]
        M3["OpenTofu ✓"]
    end

    subgraph Hybrid["Hybrid"]
        H1["Terraform + Ansible"]
        H2["Terraform + Chef/Puppet"]
    end

    style S1 fill:#fff3e0,stroke:#e65100
    style S4 fill:#e3f2fd,stroke:#1565c0
    style M1 fill:#e8f5e9,stroke:#2e7d32
    style M2 fill:#e8f5e9,stroke:#2e7d32
    style M3 fill:#e8f5e9,stroke:#2e7d32

Perbandingan Komprehensif #

Tabel berikut membandingkan semua tool berdasarkan aspek-aspek penting:

Ringkasan #

• CloudFormation terbaik untuk tim AWS-only yang butuh integrasi native — gratis, drift detection, dan rollback otomatis, tapi verbose dan vendor lock-in.
• Pulumi tepat untuk tim yang ingin menggunakan bahasa pemrograman umum (TypeScript, Python, Go) untuk IaC — kuat untuk abstraksi kompleks tapi punya complexity leakage.
• CDK cocok untuk tim AWS yang nyaman TypeScript — wrapper CloudFormation yang powerful tapi tetap terikat CloudFormation limitation.
• Crossplane ideal untuk tim Kubernetes yang ingin mengelola infrastruktur melalui GitOps — native K8s experience tapi butuh expertise Kubernetes.
• OpenTofu adalah alternatif open-source Terraform dengan state encryption — cocok untuk tim yang memprioritaskan open-source dan butuh client-side encryption.
• Framework keputusan: Single cloud → CDK/CloudFormation, Multi-cloud → Terraform/Pulumi, Hybrid → Terraform + Ansible, Kubernetes-native → Crossplane.
• Tidak ada tool yang sempurna — pilih berdasarkan konteks tim, skala proyek, dan kebutuhan multi-cloud kamu.

← Sebelumnya: Tool Imperatif   Berikutnya: Kapan Digunakan? →