Cloud vs On-Premise: Perdebatan yang Diselesaikan Semalam oleh COVID

🇬🇧 Read this article in English

Executive Summary

Perdebatan mengenai cloud vs on-premise telah menjadi diskusi rutin di ruang direksi selama lebih dari satu dekade. Kemudian Maret 2020 terjadi, dan perdebatan itu secara fungsional berakhir. Organisasi yang menjalankan arsitektur cloud-first beradaptasi dengan kerja jarak jauh dalam hitungan hari. Mereka yang bergantung pada infrastruktur on-premise menghabiskan berminggu-minggu—bahkan berbulan-bulan—berjuang keras memulihkan kemampuan operasional dasar. Artikel ini mengupas apa yang diungkapkan COVID-19 tentang strategi infrastruktur, mengapa argumen lama untuk on-premise tidak lagi relevan, dan apa yang harus dilakukan para eksekutif saat ini.

Pagi Ketika Segalanya Berubah

Saya telah menghabiskan sebagian besar dari dua dekade terakhir memberikan saran kepada berbagai organisasi mengenai strategi IT, dan saya belum pernah melihat satu peristiwa pun yang merestrukturisasi pemikiran eksekutif secepat COVID-19. Selama bertahun-tahun, diskusi cloud vs on-premise adalah latihan yang terukur, bahkan terkesan filosofis. Para CIO menimbang Total Cost of Ownership (TCO). Para CFO memperdebatkan CapEx versus OpEx. Tim keamanan menyuarakan kekhawatiran tentang kedaulatan data (data sovereignty). Semua orang punya waktu untuk menimbang-nimbang.

Kemudian, nyaris dalam semalam, pemerintah memerintahkan penutupan kantor. Jutaan pekerja kantoran harus mengakses sistem perusahaan dari meja makan dan kamar tidur cadangan mereka. Pertanyaannya bukan lagi “haruskah kita beralih ke cloud?” Melainkan “bisakah karyawan kita bekerja besok pagi?”

Jawabannya, bagi sejumlah besar organisasi yang mengkhawatirkan, adalah tidak.

Apa yang Diungkap COVID Tentang Infrastruktur On-Premise

Biar saya perjelas: infrastruktur on-premise pada dasarnya tidak rusak. Saya telah merancang dan mengelola lingkungan on-premise yang berkinerja sangat baik untuk tujuan yang dimaksudkan. Masalahnya tidak pernah pada kapabilitas—melainkan pada asumsi. Arsitektur on-premise mengasumsikan kedekatan fisik. Arsitektur ini berasumsi bahwa karyawan akan berada di dalam gedung, terhubung ke jaringan lokal, mengakses server di ujung lorong.

Ketika asumsi tersebut runtuh pada bulan Maret, konsekuensinya langsung terasa dan parah:

• Kapasitas VPN yang tersendat: Organisasi yang mengandalkan konsentrator VPN yang dirancang hanya untuk 10-15% penggunaan jarak jauh tiba-tiba harus menyalurkan 100% tenaga kerja mereka melalui sistem tersebut. Banyak perangkat VPN tidak mampu menangani beban tersebut. Biaya lisensi untuk menskalakannya sangat besar—dan waktu pengiriman perangkat keras memakan waktu berbulan-bulan.
• Kebutuhan akses fisik: Beberapa sistem ERP, alat pelaporan keuangan, dan aplikasi legacy memerlukan akses di tempat atau instalasi thick client. Tim IT harus secara fisik mendatangi kantor yang di-lockdown untuk mengonfigurasi ulang server, terkadang harus mengurus proses pengecualian dari pemerintah daerah untuk melakukannya.
• Celah pembaruan dan pemeliharaan: Tanpa staf di lokasi, jadwal pemeliharaan rutin berubah menjadi mimpi buruk logistik. Patch keamanan tidak diterapkan. Verifikasi backup tertinggal. Risiko menumpuk secara diam-diam.
• Silo komunikasi: Organisasi yang masih menjalankan server email on-premise atau berbagi file tanpa lapisan yang dapat diakses cloud mendapati tim mereka terfragmentasi. Kolaborasi terhenti total.

Saya berbicara dengan seorang CFO manufaktur skala menengah pada bulan April yang mengatakan bahwa tim keuangannya tidak dapat menutup buku untuk Kuartal 1 karena tiga laporan penting hanya dapat dihasilkan dari komputer yang terhubung secara fisik ke ERP on-premise mereka. Pada akhirnya, mereka harus mengirim dua karyawan ke gedung kantor yang kosong, bekerja dalam isolasi, demi menghasilkan laporan yang sebetulnya bisa disajikan oleh sistem berbasis cloud dari peramban (browser) mana pun.

Itu bukanlah masalah teknologi. Itu adalah kegagalan strategis.

Mengapa Organisasi Cloud-First Beradaptasi Lebih Cepat

Kontrasnya sangat mencolok. Perusahaan yang telah berkomitmen pada arsitektur cloud-first atau berbasis cloud memang mengalami gangguan—semua orang mengalaminya—tetapi mereka memulihkan kemampuan operasional dalam hitungan hari, bukan minggu.

Pertimbangkan apa yang diberikan oleh infrastruktur cloud modern selama krisis:

• Skalabilitas instan: Platform cloud seperti Azure dan AWS memungkinkan organisasi untuk menskalakan komputasi dan penyimpanan sesuai permintaan. Tidak perlu pengadaan perangkat keras. Tidak ada penundaan pengiriman. Kapasitas tersedia dalam hitungan jam.
• Akses tanpa batas lokasi: Aplikasi SaaS—baik itu Salesforce, NetSuite, Microsoft 365, atau puluhan lainnya—hanya memerlukan peramban dan koneksi internet. Karyawan langsung produktif sejak hari pertama lockdown.
• Redundansi bawaan: Penyedia cloud utama beroperasi di berbagai wilayah geografis dengan failover otomatis. Kelangsungan bisnis (business continuity) bukan sekadar fitur tambahan—itu sudah tertanam dalam arsitektur.
• Kolaborasi sebagai standar: Perangkat seperti Microsoft Teams dan Slack, yang berjalan di atas infrastruktur cloud, menjadi penghubung vital bagi tim yang tersebar. Penggunaan Microsoft Teams melonjak dari 32 juta pengguna aktif harian di bulan Maret menjadi 75 juta pada akhir April [Sumber: Laporan pendapatan kuartalan Microsoft, April 2020].

Klien jasa keuangan yang pernah bekerja sama dengan saya pada tahun 2018 untuk migrasi cloud mengatakan kepada saya di bulan Mei bahwa transisi mereka menuju operasi jarak jauh sepenuhnya hanya memakan waktu dua hari. Dua hari. Kompetitor on-premise mereka di pasar yang sama masih sibuk mengatasi masalah VPN pada minggu ketiga.

Cloud vs On-Premise: Menilai Kembali Argumen Tradisional

Sebelum COVID, perdebatan cloud vs on-premise memiliki segelintir argumen berulang yang membuat organisasi tetap terpaku pada pusat data (data center) mereka. Setiap argumen tersebut layak untuk dievaluasi kembali mengingat apa yang baru saja kita alami.

“On-Premise Lebih Aman”

Argumen ini selalu memiliki nuansa yang lebih kompleks dari yang terdengar. Ya, memiliki kontrol fisik atas perangkat keras memang memberikan jenis keamanan tertentu. Namun, keamanan bukan sekadar tentang di mana data itu berada—ini tentang bagaimana data dilindungi, dipantau, dan dipelihara.

Penyedia cloud besar menginvestasikan miliaran dolar setiap tahun untuk infrastruktur keamanan, mempekerjakan tim intelijen ancaman siber khusus, dan mempertahankan sertifikasi kepatuhan (SOC 2, ISO 27001, FedRAMP) yang tidak dapat disamai oleh sebagian besar departemen IT perusahaan skala menengah. Model tanggung jawab bersama (shared responsibility model) mengharuskan pelanggan untuk mengamankan konfigurasi mereka sendiri, di situlah sebagian besar pelanggaran sebenarnya terjadi. Namun, keamanan platform dasar dari AWS, Azure, atau Google Cloud, secara objektif, jauh lebih unggul daripada apa yang dapat dibangun dan dipertahankan oleh satu organisasi.

COVID menambahkan dimensi lain: organisasi yang tidak dapat melakukan pembaruan (patch) pada sistem on-premise karena staf tidak dapat mengakses pusat data, secara objektif menjadi kurang aman selama pandemi dibandingkan rekan-rekan mereka yang menggunakan cloud dan menerima pembaruan otomatis.

“Kita Membutuhkan On-Premise untuk Kepatuhan (Compliance)”

Persyaratan regulasi memang nyata, dan industri tertentu—layanan kesehatan, pertahanan, jasa keuangan—memiliki kewajiban terkait residensi dan penanganan data yang sah. Namun, lanskap kepatuhan telah berkembang secara signifikan. Setiap penyedia cloud utama kini menawarkan pusat data spesifik wilayah, lingkungan cloud standar pemerintah, dan perangkat kepatuhan yang memenuhi atau bahkan melampaui apa yang ditawarkan oleh sebagian besar pengaturan on-premise.

Pertanyaan bagi para petugas kepatuhan bukan lagi “dapatkah cloud memenuhi persyaratan kita?” Melainkan “apakah kita mengonfigurasinya dengan benar untuk memenuhi persyaratan kita?” Keduanya adalah pertanyaan yang secara fundamental berbeda.

“Total Cost of Ownership Lebih Menguntungkan On-Premise”

Argumen TCO selalu bergantung pada asumsi tentang tingkat pemanfaatan, siklus pembaruan perangkat keras, biaya kepegawaian, dan horizon waktu. Dalam kondisi stabil, lingkungan on-premise yang dikelola dengan baik terkadang dapat menunjukkan TCO yang menguntungkan selama lima hingga tujuh tahun.

Namun, model TCO jarang memperhitungkan gangguan bencana. Berapa biaya dari tiga minggu operasi yang menurun? Berapa biaya dari kegagalan penutupan buku akhir kuartal? Berapa biaya kehilangan pelanggan yang beralih ke kompetitor yang tetap beroperasi?

Jika model TCO Anda tidak memasukkan komponen biaya untuk “pandemi global yang membuat infrastruktur fisik tidak dapat diakses,” maka model tersebut tidak lengkap. Dan itulah pelajaran mendalamnya: perhitungan TCO yang hanya memodelkan kondisi stabil pada dasarnya cacat untuk pengambilan keputusan strategis.

Kerangka Kerja untuk Keputusan Infrastruktur Pasca-COVID

Saya tidak menyarankan setiap organisasi harus membongkar pusat datanya besok. Itu tindakan sembrono. Yang saya sarankan adalah setiap tim eksekutif harus melakukan penilaian infrastruktur yang jujur saat ini juga, selagi pelajarannya masih segar dan urgensinya nyata.

Berikut adalah kerangka kerja praktis yang selama ini saya gunakan bersama klien:

1. Klasifikasikan Beban Kerja Berdasarkan Kekritisan dan Mobilitas

Petakan setiap aplikasi dan beban kerja utama pada dua sumbu: seberapa kritis aplikasi tersebut terhadap operasi harian, dan seberapa mudah aplikasi tersebut diakses dari jarak jauh. Apa pun yang mendapat skor tinggi pada kekritisan dan rendah pada aksesibilitas jarak jauh adalah kandidat prioritas utama Anda untuk migrasi.

2. Identifikasi Titik Kegagalan Tunggal (Single Points of Failure)

COVID adalah sebuah stress test. Dokumentasikan setiap titik di mana operasi terhenti atau menurun. Batas kapasitas VPN. Aplikasi yang memerlukan akses di tempat. Proses manual yang tidak dapat dilakukan dari jarak jauh. Ini bukan sekadar risiko pandemi—ini adalah risiko untuk setiap skenario yang mengganggu akses fisik: bencana alam, kerusakan fasilitas, pemadaman listrik yang berkepanjangan.

3. Evaluasi Arsitektur Hybrid

Bagi sebagian besar organisasi, jawabannya bukanlah 100% cloud atau 100% on-premise—melainkan model hybrid yang dirancang dengan cermat. Pertahankan beban kerja di on-premise jika ada alasan yang benar-benar kuat dan aktual (persyaratan kepatuhan spesifik, kebutuhan latensi sangat rendah, ketergantungan perangkat keras eksklusif). Pindahkan sisanya ke cloud atau platform SaaS yang memberikan kebebasan lokasi dan skalabilitas elastis.

4. Bangun Ulang Model TCO dengan Skenario Gangguan

Perbarui model keuangan Anda untuk memasukkan biaya downtime, biaya skalabilitas darurat, dan biaya peluang dari gangguan operasional. Jalankan skenario: apa yang terjadi jika 100% tenaga kerja Anda bekerja dari jarak jauh selama 30 hari? 90 hari? Bagaimana jika fasilitas utama tidak tersedia selama enam bulan? Angka-angka tersebut akan mengubah perspektif percakapan Anda.

5. Tetapkan Lini Masa Migrasi — dan Berikan Anggarannya

Strategi tanpa anggaran hanyalah daftar keinginan. Jika penilaian Anda mengungkapkan risiko on-premise yang signifikan, alokasikan modal dan tetapkan tonggak pencapaian (milestones). Migrasi bertahap selama 12-18 bulan adalah hal yang realistis untuk sebagian besar organisasi skala menengah. Menunggu krisis berikutnya bukanlah sebuah strategi.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah infrastruktur on-premise sudah mati setelah COVID?

Tidak, dan siapa pun yang mengklaim demikian terlalu menyederhanakan masalah. On-premise masih masuk akal untuk kasus penggunaan spesifik: beban kerja dengan persyaratan kedaulatan data yang ketat, aplikasi dengan sensitivitas latensi ekstrem, atau lingkungan di mana kerangka regulasi benar-benar mewajibkan kontrol fisik. Yang berubah adalah asumsi dasarnya. Sebelum COVID, banyak organisasi menjadikan on-premise sebagai pilihan standar dan harus membenarkan alasan pindah ke cloud. Standar tersebut kini harus dibalik. Cloud harus menjadi asumsi awal, dan on-premise harus membutuhkan pembenaran yang eksplisit.

Seberapa cepat perusahaan skala menengah dapat memigrasikan sistem kritis ke cloud?

Hal ini bergantung pada kompleksitas, tetapi migrasi terfokus untuk beban kerja paling kritis—email, kolaborasi, CRM, dan pelaporan keuangan—biasanya dapat diselesaikan dalam tiga hingga enam bulan. Migrasi ERP secara penuh lebih rumit, sering kali memakan waktu 12-18 bulan dengan perencanaan yang tepat. Kuncinya adalah memprioritaskan menggunakan kerangka kerja kekritisan-mobilitas yang dijelaskan di atas, daripada mencoba memindahkan semuanya secara bersamaan. Mulailah dengan sistem yang paling berdampak buruk jika offline.

Apa kesalahan terbesar yang dilakukan perusahaan saat terburu-buru beralih ke cloud?

Kesalahan paling umum yang saya lihat saat ini adalah: memindahkan aplikasi secara mentah-mentah (lift and shift) tanpa merancangnya ulang untuk cloud (yang sering kali meningkatkan biaya tanpa meningkatkan ketahanan), mengabaikan konfigurasi manajemen identitas dan akses (sumber nomor satu insiden keamanan cloud), meremehkan biaya egress dan biaya transfer data, serta gagal melatih staf mengenai operasi cloud-native. Kecepatan memang penting, tetapi kecepatan yang tidak disiplin akan menciptakan masalah baru. Fase penilaian dan perencanaan selama 90 hari sebelum migrasi dimulai adalah waktu yang diinvestasikan dengan sangat baik.

Apakah beralih ke cloud menghilangkan kebutuhan akan staf infrastruktur IT?

Tidak. Hal ini hanya mengubah keahlian yang dibutuhkan. Anda membutuhkan lebih sedikit orang untuk mengelola perangkat keras fisik, menambal sistem operasi, dan menarik kabel. Namun, Anda membutuhkan lebih banyak orang yang memahami arsitektur cloud, infrastructure-as-code, konfigurasi keamanan, optimalisasi biaya, dan manajemen vendor. Peran bergeser dari pemeliharaan ke desain dan tata kelola. Organisasi yang memperlakukan migrasi cloud sebagai dalih pengurangan jumlah karyawan biasanya berakhir dengan lingkungan yang dikonfigurasi dengan buruk, kelebihan kapasitas (over-provisioned), dan memakan biaya lebih besar daripada pusat data yang mereka gantikan.

Langkah Kita Selanjutnya

Tiga bulan lalu, saya mungkin akan mengatakan kepada Anda bahwa perdebatan cloud vs on-premise masih memiliki argumen yang sah di kedua belah pihak. Hal itu benar, di dunia di mana kita dapat mengasumsikan akses fisik yang stabil ke fasilitas kita dan kondisi operasi yang dapat diprediksi.

Dunia itu telah tiada—atau setidaknya, telah terbukti jauh lebih rapuh daripada yang kita asumsikan.

Organisasi yang akan bangkit paling kuat dari krisis ini belum tentu mereka yang memiliki anggaran IT terbesar. Mereka adalah organisasi yang membuat keputusan infrastruktur dengan pandangan yang jernih saat ini juga, selagi rasa sakit dari tiga bulan terakhir masih segar di ingatan. Mereka adalah pihak yang menyadari bahwa fleksibilitas infrastruktur bukanlah preferensi teknis—itu adalah persyaratan mutlak untuk kelangsungan bisnis.

Jika Anda seorang eksekutif yang masih memperdebatkan apakah akan mempercepat strategi cloud Anda, pertimbangkan ini: kita baru saja melewati gelombang pertama pandemi ini. Ketidakpastian ekonomi akan terus berlanjut selama beberapa kuartal, mungkin bertahun-tahun. Kemampuan untuk beroperasi dari mana saja, menskalakan sesuai permintaan, dan mempertahankan kelangsungan melalui gangguan bukan lagi sekadar pelengkap (nice-to-have) dalam peta jalan tiga tahunan. Itu adalah ekspektasi dasar.

Perdebatan sudah selesai. Satu-satunya pertanyaan adalah seberapa cepat Anda bertindak atas jawaban tersebut.