Apa itu Environment? #

Hampir semua tim yang mengelola infrastruktur serius memiliki lebih dari satu environment. Ada dev tempat developer bereksperimen, staging yang mencerminkan production untuk pengujian akhir, dan production yang melayani pengguna nyata. Tantangannya bukan membuat masing-masing — tapi memastikan ketiganya dikelola dari konfigurasi yang sama, konsisten, dan tidak terjadi situasi di mana staging berbeda secara diam-diam dari production sehingga bug lolos tanpa terdeteksi.

flowchart TD
    A["🌍 Environment"] --> B["Development"]
    A --> C["Staging"]
    A --> D["Production"]

    B --> E["Iterasi cepat\nRisiko rendah"]
    C --> F["Validasi\nSebelum prod"]
    D --> G["Stabilitas\nAvailability tinggi"]

    style A fill:#3b82f6,stroke:#1e40af,color:#fff
    style B fill:#10b981,stroke:#059669,color:#fff
    style C fill:#f59e0b,stroke:#d97706,color:#fff
    style D fill:#ef4444,stroke:#dc2626,color:#fff

Mengapa Environment Dibutuhkan #

Perbedaan environment bukan sekadar konvensi penamaan. Setiap environment punya tujuan yang berbeda, dan perbedaan tujuan itu memerlukan perbedaan konfigurasi yang terstruktur.

DEV (Development)
  Tujuan  : Eksperimen, iterasi cepat, debugging
  Sifat   : Boleh tidak stabil, data bisa dihapus kapan saja
  Ukuran  : Kecil, minimal — hemat biaya
  Akses   : Developer bebas akses penuh
  Contoh  : 1 instance t3.micro, DB single-AZ tanpa backup

STAGING
  Tujuan  : Validasi sebelum release ke production
  Sifat   : Harus semirip mungkin dengan production
  Ukuran  : Sedang — cukup untuk testing yang representatif
  Akses   : Terbatas — tim QA, developer senior
  Contoh  : 2 instance t3.small, DB dengan backup enabled

PRODUCTION
  Tujuan  : Melayani pengguna nyata
  Sifat   : Harus stabil, highly available, aman
  Ukuran  : Full scale sesuai kebutuhan traffic
  Akses   : Sangat terbatas — hanya operator terotorisasi
  Contoh  : 3+ instance t3.medium, DB multi-AZ dengan backup 30 hari

Apa yang Berbeda Antar Environment #

Environment yang berbeda bukan berarti konfigurasi yang berbeda total — justru strukturnya harus sama, hanya nilainya yang berbeda.

# Yang SAMA di semua environment (struktur konfigurasi):
#   - Resource apa yang dibuat (VPC, subnet, EC2, RDS)
#   - Bagaimana resource saling terhubung
#   - Security rules dan networking topology
#   - Cara deployment dilakukan

# Yang BERBEDA antar environment (nilai konfigurasi):
#   - Ukuran instance (t3.micro vs t3.medium vs t3.large)
#   - Jumlah instance (1 vs 2 vs 5)
#   - Multi-AZ (false vs false vs true)
#   - Backup retention (0 vs 7 vs 30 hari)
#   - Deletion protection (false vs false vs true)
#   - Nama dan tag resource
#   - CIDR block VPC (10.0.0.0/16 vs 10.1.0.0/16 vs 10.2.0.0/16)

# Ini tercermin dalam variable:
variable "instance_type" {
  # dev: "t3.micro", staging: "t3.small", production: "t3.medium"
}

variable "multi_az" {
  # dev: false, staging: false, production: true
}

variable "backup_retention_days" {
  # dev: 0, staging: 7, production: 30
}

Prinsip Environment yang Konsisten #

Ada satu prinsip yang paling sering dilanggar dalam pengelolaan multi-environment: production drift — kondisi di mana staging dan production berbeda secara diam-diam karena dikelola dengan cara yang berbeda.

ANTI-PATTERN: Environment yang tidak simetris

  Dev       → Dikelola dengan Terraform ✓
  Staging   → Dikelola dengan Terraform ✓
  Production → "Sudah jalan, jangan diubah" → dikelola manual ✗

  Akibat:
  - Production punya resource "misterius" yang tidak ada di staging
  - Bug yang lolos di staging bisa muncul di production
  - Tidak ada cara untuk reproduce production environment di tempat lain
  - Saat disaster recovery, tidak ada yang tahu persis kondisi production

BENAR: Semua environment dikelola dari konfigurasi yang sama

  Dev, Staging, Production → semua dari konfigurasi Terraform yang sama
  Perbedaan hanya pada nilai variable, bukan pada struktur konfigurasi

Tantangan Pengelolaan Multi-Environment #

TANTANGAN 1: ISOLASI STATE
  Setiap environment harus punya state sendiri.
  State dev tidak boleh campur dengan state production.
  → Solusi: remote backend dengan key terpisah per environment

TANTANGAN 2: ISOLASI KONFIGURASI
  Perubahan di konfigurasi dev tidak boleh otomatis masuk production.
  → Solusi: workflow yang eksplisit (PR, review, promotion)

TANTANGAN 3: CREDENTIAL TERPISAH
  Dev dan production tidak boleh menggunakan AWS account yang sama.
  → Solusi: AWS account terpisah per environment (multi-account strategy)

TANTANGAN 4: KONSISTENSI KONFIGURASI
  Struktur konfigurasi harus sama antar environment.
  → Solusi: modul yang sama, tfvars yang berbeda

TANTANGAN 5: PROMOTION WORKFLOW
  Bagaimana konfigurasi "naik" dari dev ke staging ke production?
  → Solusi: GitOps dengan branch atau tag per environment

Dua Pendekatan Utama #

Terraform menyediakan dua pendekatan utama untuk mengelola multi-environment — masing-masing dengan trade-off yang berbeda.

PENDEKATAN 1: WORKSPACE
  Satu direktori konfigurasi, state terpisah per workspace.
  terraform workspace new dev
  terraform workspace new production

  Kelebihan : Satu set kode, mudah dibuat konsisten
  Kekurangan: Semua environment berbagi provider dan backend config,
              sulit jika butuh AWS account terpisah per environment

PENDEKATAN 2: DIRECTORY BASED
  Direktori terpisah per environment, masing-masing punya
  konfigurasi dan state sendiri.

  environments/dev/        → state dev
  environments/staging/    → state staging
  environments/production/ → state production

  Kelebihan : Isolasi penuh, fleksibel untuk perbedaan besar
  Kekurangan: Risiko divergensi konfigurasi antar environment
              jika tidak dikelola dengan disiplin

Kedua pendekatan ini akan dibahas lebih detail di artikel berikutnya.

flowchart LR
    A["Terraform\nWorkspace"] -->|"Per environment"| B["Different\nState File"]
    B --> C["Same Code\nDifferent Values"]

    style A fill:#3b82f6,stroke:#1e40af,color:#fff
    style B fill:#f59e0b,stroke:#d97706,color:#fff
    style C fill:#10b981,stroke:#059669,color:#fff

Dampak Environment terhadap Arsitektur #

Pemilihan environment strategy mempengaruhi seluruh arsitektur — dari cara deploy hingga cara monitoring.

flowchart TD
    subgraph DEV["Development"]
        D1["Single instance
t3.micro"]
        D2["No HA"]
        D3["Self-signed cert"]
    end

    subgraph STG["Staging"]
        S1["2 instances
t3.small"]
        S2["Simulated HA"]
        S3["Test certificate"]
    end

    subgraph PRD["Production"]
        P1["Auto-scaling
m5.large"]
        P2["Multi-AZ HA"]
        P3["Real certificate"]
    end

    DEV -->|"Promote"| STG
    STG -->|"Promote"| PRD

    style DEV fill:#fff3e0,stroke:#e65100
    style STG fill:#e3f2fd,stroke:#1565c0
    style PRD fill:#e8f5e9,stroke:#2e7d32

# Perbedaan konfigurasi antar environment
# DEV:
#   - instance_type: t3.micro (minimal cost)
#   - multi_az: false (tidak perlu HA)
#   - backup_retention: 1 hari (hemat storage)
#   - deletion_protection: false (mudah di-cleanup)

# PRODUCTION:
#   - instance_type: m5.large (performa)
#   - multi_az: true (high availability)
#   - backup_retention: 30 hari (compliance)
#   - deletion_protection: true (safety)

Environment Promotion Workflow #

# Workflow umum: develop → staging → production

# 1. Developer push code ke feature branch
git push origin feature/add-cache

# 2. CI pipeline otomatis deploy ke dev environment
terraform workspace select dev
terraform apply -auto-approve

# 3. QA testing di dev, lalu merge ke main
git checkout main && git merge feature/add-cache

# 4. CD pipeline deploy ke staging
terraform workspace select staging
terraform plan -out=staging.tfplan
# Manual review plan
terraform apply staging.tfplan

# 5. Smoke test dan UAT di staging
# 6. Manual approval untuk production deploy
# 7. Deploy ke production dengan approval gate
terraform workspace select production
terraform plan -out=prod.tfplan
# Manual approval di CI/CD tool
terraform apply prod.tfplan

---

## Environment Isolation Patterns

Isolasi environment yang baik mencegah kesalahan cross-environment yang bisa berakibat fatal.

```hcl
# Pattern 1: Completely separate state files
# Setiap environment = directory + state terpisah
# infrastructure/dev/main.tf    → state: dev.tfstate
# infrastructure/staging/main.tf → state: staging.tfstate
# infrastructure/prod/main.tf   → state: prod.tfstate

# Pattern 2: Workspace-based isolation
terraform workspace select dev
terraform apply
# State disimpan di workspace "dev", terpisah dari workspace lain

# Pattern 3: Account-level isolation (paling aman)
# Dev: AWS Account 111111111111
# Staging: AWS Account 222222222222
# Prod: AWS Account 333333333333
provider "aws" {
  region = "ap-southeast-1"
  assume_role {
    role_arn = local.account_roles[terraform.workspace]
  }
}

locals {
  account_roles = {
    dev        = "arn:aws:iam::111111111111:role/TerraformRole"
    staging    = "arn:aws:iam::222222222222:role/TerraformRole"
    production = "arn:aws:iam::333333333333:role/TerraformRole"
  }
}

ISOLATION LEVEL COMPARISON:

Level 1: Directory + State Terpisah
├── Blast radius: Terbatas (bisa salah workspace)
├── Cost: Rendah
└── Kompleksitas: Rendah

Level 2: Workspace
├── Blast radius: Sedang (shared backend config)
├── Cost: Rendah
└── Kompleksitas: Rendah

Level 3: Separate AWS Accounts
├── Blast radius: Paling kecil (isolasi penuh)
├── Cost: Sedang (multi-account management)
└── Kompleksitas: Tinggi

REKOMENDASI: Level 3 untuk production,
Level 1-2 untuk development

Environment Configuration Matrix #

CONFIG MATRIX PER ENVIRONMENT:

                    dev         staging      production
────────────────────────────────────────────────────────
instance_type       t3.micro    t3.small     m5.large
instance_count      1           2            3 (auto-scale)
multi_az            false       true         true
backup_retention    1 day       7 days       30 days
deletion_protection false       false        true
monitoring          basic       detailed     detailed
ssl_certificate     self-signed ACM          ACM (renewed)
logging             stdout      CloudWatch   CloudWatch+SIEM
alerting            none        Slack        PagerDuty
cost/month          ~$50        ~$200        ~$2000+

# Implementation: configuration map per environment
locals {
  env_config = {
    dev = {
      instance_type        = "t3.micro"
      instance_count       = 1
      multi_az             = false
      backup_retention     = 1
      deletion_protection  = false
      monitoring_level     = "basic"
    }
    staging = {
      instance_type        = "t3.small"
      instance_count       = 2
      multi_az             = true
      backup_retention     = 7
      deletion_protection  = false
      monitoring_level     = "detailed"
    }
    production = {
      instance_type        = "m5.large"
      instance_count       = 3
      multi_az             = true
      backup_retention     = 30
      deletion_protection  = true
      monitoring_level     = "detailed"
    }
  }
  cfg = local.env_config[var.environment]
}

Ringkasan #

• Environment bukan sekadar nama — dev, staging, dan production punya tujuan berbeda yang memerlukan konfigurasi berbeda secara terstruktur.
• Struktur sama, nilai berbeda — prinsip dasar environment yang baik. Konfigurasi Terraform yang sama dipakai di semua environment, hanya nilai variable yang berbeda.
• Production drift adalah musuh utama — ketika staging tidak mencerminkan production, bug lolos tanpa terdeteksi dan disaster recovery menjadi tidak bisa diandalkan.
• Lima tantangan: isolasi state, isolasi konfigurasi, credential terpisah, konsistensi konfigurasi, dan promotion workflow.
• Dua pendekatan utama: workspace (satu konfigurasi, state terpisah) dan directory based (direktori terpisah per environment).
• Idealnya gunakan AWS account terpisah per environment untuk isolasi biaya, keamanan, dan blast radius yang lebih baik.

← Sebelumnya: Registry   Berikutnya: Jenis Environment →