Pemilihan Cloud Platform

Seluruh babasan section ini — jaringan, managed services, autoscaling, backup, hingga high availability — berlaku di semua penyedia cloud besar. Tapi manajemen TokoKita menuntut satu jawaban: platform mana yang dipakai untuk tiga tahun ke depan? Pertanyaan ini tidak punya jawaban universal; jawabannya bergantung pada regulasi yang menaungi data, layanan yang dibutuhkan, dan tim yang menjalankannya. Chapter penutup ini menyusun kerangka keputusan yang bisa dipertanggungjawabkan: matriks kebutuhan, peta layanan setara, skoring berbobot, dan jebakan biaya yang sering mengubah jawaban di bulan kesepuluh.

Matriks Kebutuhan #

Keputusan yang sehat dimulai dari kebutuhan, bukan dari brosur. Lima kriteria berikut hampir selalu menentukan:

Untuk konteksnya, jawaban TokoKita atas matriks ini: data pelanggan harus tinggal di region Indonesia, tim sudah nyaman dengan Python dan Docker, belum ada kontrak enterprise dengan penyedia mana pun, dan dashboard perusahaan dibaca oleh kantor cabang sehingga egress berkumpul tiap bulan. Jawaban Anda yang menentukan — kerangkanya yang penting sama.

Peta Layanan Setara #

Ketiga penyedia besar punya jawaban untuk setiap kebutuhan platform data — nama resminya berbeda, kategorinya sama. Ketiganya juga telah membuka region di Jakarta, sehingga kebutuhan residency data Indonesia tidak lagi memangkas pilihan secara drastis.

Peta ini penting karena pengetahuan arsitektur tetap berlaku lintas penyedia: konsep VPC, subnet, autoscaling, dan multi-AZ yang kita pelajari di seluruh section ini ada padanannya di ketiga platform dengan nama berbeda. Yang membedakan adalah rasa dan model harga — misalnya BigQuery menagih per data yang dipindai tanpa kluster untuk diurus, sementara pola Athena memberi pengalaman serupa di AWS di atas object storage. Gambaran umum layanan tiap penyedia dirangkum di AWS Overview dan Google Cloud documentation .

Matriks Keputusan Berbobot #

Ketika lima kriteria bertemu, kita butuh mekanisme yang transparan. Matriks berbobot memberi skor 1-5 per kriteria lalu mengalikannya dengan bobot yang disepakati sebelum melihat skor. Skor di bawah bersifat ilustratif untuk skenario TokoKita — tim kecil, tanpa estate lama, keahlian Python kuat; angka Anda pasti berbeda.

"""Matriks keputusan berbobot untuk pemilihan cloud platform TokoKita.

Skor 1-5 bersifat ILUSTRATIF untuk skenario TokoKita (tim kecil, beban
data campuran). Yang dihitung nyata adalah mekanisme pembobotannya:
skor akhir = jumlah (bobot x skor) per kriteria.
"""

# (kriteria, bobot) -- total bobot harus 1.00
KRITERIA = [
    ("Kepatuhan & data residency", 0.20),
    ("Kedalaman managed data services", 0.25),
    ("Estate & tooling yang sudah dipakai tim", 0.15),
    ("Biaya egress data", 0.15),
    ("Keahlian tim", 0.25),
]

SKOR = {
    "AWS":   [4, 5, 3, 2, 3],
    "GCP":   [4, 5, 2, 3, 4],
    "Azure": [4, 4, 3, 2, 3],
}


def skor_berbobot(platform, kriteria):
    return sum(bobot * skor for (_, bobot), skor in zip(kriteria, SKOR[platform]))


total_bobot = sum(b for _, b in KRITERIA)
print(f"Total bobot: {total_bobot:.2f} (harus 1.00)\n")

print("| Kriteria (bobot) | " + " | ".join(SKOR) + " |")
print("|---|---|---|---|")
for i, (nama, bobot) in enumerate(KRITERIA):
    print(f"| {nama} ({bobot:.2f}) | "
          + " | ".join(str(SKOR[p][i]) for p in SKOR) + " |")
print("| **Skor berbobot** | "
      + " | ".join(f"**{skor_berbobot(p, KRITERIA):.2f}**" for p in SKOR) + " |")

print()
for p in SKOR:
    rincian = ", ".join(f"{bobot:.2f}x{skor}"
                        for (_, bobot), skor in zip(KRITERIA, SKOR[p]))
    print(f"  {p:<6}: {rincian} = {skor_berbobot(p, KRITERIA):.2f}")

# uji sensitivitas: bobot didominasi estate yang sudah dipakai organisasi
print("\nUji sensitivitas: bila kompatibilitas dengan estate organisasi")
print("dominan (estate 0.45, managed 0.20, residency 0.15, egress 0.10, skill 0.10)")
KRITERIA_ALT = [
    ("Kepatuhan & data residency", 0.15),
    ("Kedalaman managed data services", 0.20),
    ("Estate & tooling yang sudah dipakai tim", 0.45),
    ("Biaya egress data", 0.10),
    ("Keahlian tim", 0.10),
]
for p in SKOR:
    print(f"  {p:<6}: {skor_berbobot(p, KRITERIA_ALT):.2f}")
print("Bobot berubah -> urutan berubah. Sepakati bobot bersama")
print("sebelum melihat skor, bukan menyetel bobot demi hasil yang diinginkan.")

Output yang Dihasilkan:

Total bobot: 1.00 (harus 1.00)

| Kriteria (bobot) | AWS | GCP | Azure |
|---|---|---|---|
| Kepatuhan & data residency (0.20) | 4 | 4 | 4 |
| Kedalaman managed data services (0.25) | 5 | 5 | 4 |
| Estate & tooling yang sudah dipakai tim (0.15) | 3 | 2 | 3 |
| Biaya egress data (0.15) | 2 | 3 | 2 |
| Keahlian tim (0.25) | 3 | 4 | 3 |
| **Skor berbobot** | **3.55** | **3.80** | **3.30** |

  AWS   : 0.20x4, 0.25x5, 0.15x3, 0.15x2, 0.25x3 = 3.55
  GCP   : 0.20x4, 0.25x5, 0.15x2, 0.15x3, 0.25x4 = 3.80
  Azure : 0.20x4, 0.25x4, 0.15x3, 0.15x2, 0.25x3 = 3.30

Uji sensitivitas: bila kompatibilitas dengan estate organisasi
dominan (estate 0.45, managed 0.20, residency 0.15, egress 0.10, skill 0.10)
  AWS   : 3.45
  GCP   : 3.20
  Azure : 3.25
Bobot berubah -> urutan berubah. Sepakati bobot bersama
sebelum melihat skor, bukan menyetel bobot demi hasil yang diinginkan.

Mari kita telaah baris-baris kode di atas:

1. Baris 11-17 (bobot dan skor): bobot menyatakan prioritas organisasi; skor menyatakan penilaian tiap platform. Keduanya dipisah agar perdebatan prioritas dan perdebatan penilaian tidak tercampur.
2. Baris 24-25 (skor_berbobot): fungsi zip memasangkan setiap kriteria dengan skor platform di posisi yang sama, lalu menjumlahkan hasil kalinya.
3. Baris 46-55 (uji sensitivitas): matriks dihitung ulang dengan bobot alternatif. Dengan bobot keahlian tim yang tinggi, GCP memimpin; begitu bobot estate organisasi dominan, AWS dan Azure menyalip. Hasil akhirnya bukan platform “terbaik”, melainkan platform yang paling cocok dengan prioritas yang disepakati.

Alur Keputusan #

Alur ini sengaja menjawab pertanyaan berbiaya tinggi lebih dulu (regulasi, estate) sebelum membandingkan fitur — membandingkan fitur layanan yang pada akhirnya tidak bisa dipakai adalah pekerjaan sia-sia. Perhatikan juga bahwa alur berakhir bukan di kotak keputusan semata, melainkan pada rencana eksit: keputusan yang tidak punya pintu keluar adalah keputusan yang paling berisiko.

Checklist Sebelum Menandatangani #

• Tetapkan bobot lima kriteria bersama pemangku kepentingan sebelum melihat harga maupun demo.
• Hitung biaya 12 bulan yang lengkap: compute, storage, egress, backup lintas region, dan transfer antar layanan.
• Jalankan PoC kecil — satu pipeline end-to-end TokoKita — di dua kandidat teratas, ukur biaya dan usaha nyatanya.
• Periksa ketersediaan region yang memenuhi residency data beserta layanan yang dibutuhkan di region tersebut.
• Tuliskan rencana eksit: format data terbuka, jalur ekspor, dan estimasi biaya keluar.

Checklist ini memakan satu hingga dua minggu kerja — waktu yang sangat kecil dibandingkan biaya berpindah platform di tahun kedua karena keputusan terburu-buru.

Dengan platform terpilih, platform data TokoKita siap dibangun. Namun infrastruktur yang kokoh hanya setengah cerita: pipeline yang ditulis tanpa pengujian akan tetap gagal di production persis seperti kode aplikasi. Section berikutnya, Data Engineering Testing, membawa disiplin pengujian — unit, integration, contract, hingga continuous integration — ke dalam dunia data.