Pertanyaan "cloud atau on-premise" jarang benar-benar soal teknologi. Di ruang rapat, perdebatan itu biasanya berujung pada tiga hal yang jauh lebih membumi: siapa yang menanggung biaya ketika trafik meledak, siapa yang bertanggung jawab saat data bocor, dan seberapa cepat perusahaan bisa memulihkan layanan ketika sistem tumbang pada Jumat malam. Menjawab tiga hal itu lebih berguna daripada menghafal daftar kelebihan dan kekurangan masing-masing model.
Bagaimana biaya sebenarnya bekerja
Bayangkan sebuah peritel daring dengan trafik harian yang stabil, tetapi melonjak sepuluh kali lipat pada kampanye tanggal kembar. Jika ia membangun server sendiri, kapasitas harus dibeli untuk menahan puncak tertinggi itu. Artinya, selama sebelas bulan sisanya perusahaan membayar listrik, pendingin ruangan, dan penyusutan perangkat yang utilisasinya mungkin hanya 15 persen. Di model cloud, kapasitas tambahan dinyalakan beberapa jam sebelum kampanye dan dimatikan setelahnya, sehingga yang dibayar hanya jam pemakaian.
Namun logika itu berbalik pada beban kerja yang datar. Server basis data internal yang menyala 24 jam sepanjang tahun dengan konsumsi sumber daya nyaris konstan justru sering lebih murah dijalankan sendiri setelah tahun kedua atau ketiga. Persoalannya, banyak perusahaan salah menghitung karena hanya membandingkan harga sewa bulanan dengan harga beli server. Biaya on-premise yang sesungguhnya mencakup UPS dan genset, pendingin presisi, lisensi sistem operasi dan basis data, kontrak dukungan vendor, gaji teknisi yang siaga di luar jam kerja, serta siklus penggantian perangkat setiap empat sampai lima tahun.
Sebaliknya, tagihan cloud punya jebakan sendiri. Komponen yang paling sering mengejutkan bukan biaya komputasi, melainkan biaya keluar data (egress): memindahkan data dari penyedia cloud ke luar dikenai tarif per gigabyte. Perusahaan yang menyimpan puluhan terabyte arsip video atau log transaksi bisa mendapati bahwa pindah penyedia harganya nyaris sama dengan membangun ruang server baru. Inilah yang membuat keputusan awal terasa mudah dibatalkan di atas kertas, tetapi mahal dibatalkan pada kenyataannya.
Regulasi Indonesia yang menentukan pilihan
Untuk sebagian sektor, jawabannya bukan soal preferensi karena aturan sudah membatasi. POJK No. 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum mewajibkan bank menempatkan pusat data dan pusat pemulihan bencana di wilayah Indonesia, dan penempatan di luar negeri hanya dimungkinkan dengan persetujuan Otoritas Jasa Keuangan disertai kajian risiko. Di sisi sistem pembayaran, Bank Indonesia melalui PBI No. 23/6/PBI/2021 tentang Penyedia Jasa Pembayaran juga mengatur kewajiban pemrosesan data transaksi di dalam negeri bagi penyelenggara berizin.
Untuk instansi pemerintah dan penyelenggara sistem elektronik lingkup publik, PP No. 71 Tahun 2019 mengharuskan pengelolaan dan penyimpanan data dilakukan di wilayah Indonesia, sementara penyelenggara lingkup privat diberi keleluasaan lebih besar sepanjang tetap memberi akses pengawasan kepada Kementerian Komunikasi dan Digital (sebelumnya Kominfo) dan mendaftar sebagai PSE.
Di luar sektor spesifik, UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi berlaku untuk semua. Pasal 56 mengatur bahwa pengiriman data pribadi ke luar wilayah Indonesia hanya boleh dilakukan bila negara tujuan memiliki tingkat pelindungan setara, atau ada perjanjian yang mengikat, atau ada persetujuan subjek data. Poin penting yang sering terlewat: memakai cloud pihak ketiga tidak memindahkan tanggung jawab hukum. Perusahaan tetap berstatus pengendali data, sedangkan penyedia cloud hanya prosesor. Ketika terjadi kebocoran, kewajiban memberitahukan dalam 3x24 jam kepada subjek data dan lembaga pengawas tetap melekat pada perusahaan, bukan pada vendor.
Pelajaran dari kegagalan, bukan dari brosur
Insiden ransomware yang melumpuhkan Pusat Data Nasional Sementara pada Juni 2024 memberi pelajaran yang relevan untuk kedua model. Yang membuat pemulihan berlarut bukan semata jenis infrastrukturnya, melainkan ketiadaan cadangan yang terpisah dan teruji. Server milik sendiri di ruang berpendingin tidak otomatis aman, dan menaruh sistem di cloud besar tidak otomatis membuat data punya salinan. Sebagian besar penyedia cloud menjual ketersediaan layanan, bukan jaminan bahwa data yang terhapus atau terenkripsi pelanggan akan dikembalikan.
Karena itu, pertanyaan yang lebih tajam adalah: kapan terakhir kali tim mencoba memulihkan sistem dari cadangan, dan berapa lama waktunya? Badan Siber dan Sandi Negara secara berkala mengingatkan pentingnya pola pencadangan berlapis dan pemisahan jaringan cadangan dari jaringan produksi. Uji pemulihan yang dijadwalkan dua kali setahun sering kali lebih menentukan kelangsungan bisnis daripada memilih merek server atau nama penyedia cloud.
Kerangka memutuskan
- Pola beban kerja. Trafik yang naik-turun tajam condong ke cloud; beban konstan bertahun-tahun condong ke on-premise.
- Kepatuhan sektor. Perbankan, sistem pembayaran, dan layanan publik memiliki batasan lokasi data yang eksplisit dan harus dicek lebih dulu.
- Kesiapan tim. On-premise menuntut personel yang mampu menangani insiden tengah malam; tanpa itu, kontrol penuh hanya ilusi.
- Kualitas jaringan. Laporan survei APJII menunjukkan penetrasi internet nasional terus tumbuh, tetapi kualitas dan keandalan koneksi antardaerah masih timpang. Pabrik atau gudang di lokasi dengan konektivitas rapuh sebaiknya menaruh sistem operasional kritis secara lokal.
Dari kombinasi faktor itulah pendekatan hybrid berkembang bukan sebagai kompromi setengah hati, melainkan sebagai pembagian tugas. Data pelanggan dan catatan transaksi yang tunduk pada aturan lokalisasi tetap di pusat data sendiri, sementara situs, aplikasi seluler, analitik, dan pengujian perangkat lunak dijalankan di cloud yang mudah dinaikturunkan. Yang perlu diantisipasi, model ini menambah kompleksitas: identitas pengguna, kebijakan keamanan, dan pemantauan harus disatukan agar celah tidak muncul di sambungan antara dua dunia tersebut.
Pada akhirnya tidak ada jawaban tunggal yang berlaku untuk semua perusahaan. Yang membedakan keputusan baik dari keputusan buruk adalah apakah pilihan itu diambil setelah menghitung biaya lima tahun, memeriksa kewajiban regulasi yang mengikat sektornya, dan menguji seberapa cepat bisnis bisa bangkit ketika sistem berhenti bekerja.
