Mulai Persiapan Sekarang untuk Kegagalan Cloud Berikutnya

Insiden cloud besar seperti yang terjadi minggu ini dari AWS adalah tak terhindarkan. Empat metode ini dapat membantu perusahaan Anda untuk menghadapinya.

Dengan jumlah jam produktivitas yang hilang, sistem keuangan yang terganggu untuk jutaan pengguna, dan potensi ratusan miliar dolar yang hilang, kegagalan AWS minggu ini membuat hari yang sangat buruk bagi tim IT global. Tentu saja, ini juga merupakan bencana cloud terburuk sejak yang terakhir… dan sampai yang berikutnya.

Apakah Anda menggunakan AWS, GCP, Azure, atau platform lainnya, kegagalan besar adalah kenyataan dari komputasi cloud. Jadi, apa yang dapat perusahaan Anda lakukan untuk mengurangi dampaknya? Di bawah, saya akan menawarkan empat langkah yang tim Anda dapat ambil segera.

Bawa skeptisisme Anda – dan lakukan tugas Anda.

Seringkali, tim akan mengundang bencana dengan berjalan ke dalam pengaturan cloud dengan menganggap bahwa perusahaan cloud besar secara inheren dapat diandalkan. Tentu saja, perusahaan yang paling dipercaya telah mendapatkan reputasi mereka untuk alasan yang tepat. Namun, setiap cloud dan hyperscaler menawarkan berbagai pilihan infrastruktur – AWS Amerika Utara saja memiliki 31 Zona Ketersediaan dan 31 Lokasi Jaringan Tepi – dan beberapa pilihan jauh lebih dapat diandalkan daripada yang lain.

Memang, Wilayah US-EAST-1 AWS, penyebab kegagalan minggu ini, telah menyebabkan gangguan besar pada 2020, 2021, dan 2023, dan telah lama diketahui di lingkaran IT tertentu sebagai wilayah yang paling tidak dapat diandalkan. Banyak perusahaan mungkin memahami situasi ini tetapi mengambil risiko yang dihitung karena biaya rendah dan penawaran yang melimpah di wilayah tersebut. Namun, mengingat skala kegagalan, tidak mungkin untuk tidak mempertimbangkan berapa banyak perusahaan yang terkejut sepenuhnya – dan pasti akan memilih wilayah yang lebih dapat diandalkan jika mereka menyadari pertukaran. Saya secara pribadi telah bertemu dengan pemimpin IT yang memilih untuk pindah ke wilayah AWS lain setelah pengalaman buruk dengan US-EAST-1 di masa lalu.

Pelajaran di sini adalah untuk melakukan tugas Anda dengan baik ketika datang ke pilihan infrastruktur cloud, tidak peduli cloud mana yang Anda gunakan. Tempat untuk memulai termasuk alat gratis seperti cloudprice, Cloudping, dan tampilan insiden historis dari alat Kesehatan Layanan Cloud yang disediakan oleh hyperscaler.

Pilih portabel daripada cloud-asli.

Ketika Anda merancang konfigurasi cloud, rute yang lebih sederhana adalah untuk pergi ke cloud-asli. Namun, meskipun lebih mudah untuk memilih aplikasi yang sudah dibangun oleh dan untuk penyedia cloud Anda, pilihan cloud-asli ini meninggalkan Anda lebih terbuka jika cloud Anda turun.

Untuk menghindari lapisan ketergantungan cloud tambahan, pilih produk independen dan/atau open-source di mana memungkinkan. Beberapa contoh pengganti termasuk yang berikut:

Tentu saja, membangun lebih banyak tumpukan cloud dari awal berarti lebih banyak pekerjaan untuk tim Anda. Namun, dalam pengalaman saya, setelah infrastruktur berjalan, tidak ada perbedaan antara menambahkan beban kerja ke infrastruktur yang sudah ada atau beroperasi pada cloud-asli. Dan manfaatnya dalam hal ketahanan – tidak hanya mengurangi ketergantungan cloud – membuat pilihan independen sangat berharga.

Desain untuk kegagalan.

Mengingat kegagalan cloud akan terjadi, pastikan untuk merancang produk Anda dengan kegagalan cloud dalam pikiran. Salah satu contoh untuk dilihat adalah Datadog: dalam insiden 2023, perusahaan tersebut tiba-tiba kehilangan akses ke lebih dari setengah node Kubernetes di produksi dan merancang ulang pendekatan bencana. Perubahan termasuk menghapus bottleneck arsitektur dan mengatasi utang teknis sehingga kegagalan sebagian tidak akan menyebar melalui sistem, memperbaiki pengambilan dan penyimpanan data untuk ketersediaan data yang lebih besar selama kegagalan, dan membangun sistem untuk pulih secara otomatis pada skala besar. Salah satu tempat yang baik untuk memulai dalam perjalanan Anda adalah untuk mengikuti rekomendasi Datadog untuk “memulai dengan apa yang penting bagi pengguna akhir,” dan membangun pengaman untuk melindungi apa yang paling penting.

Jalankan pada setidaknya dua cloud.

Tentu saja, cara terbaik untuk tidak terikat pada kegagalan cloud adalah redundansi multicloud. Mencapai fluiditas multicloud yang sebenarnya adalah tugas besar bagi banyak perusahaan, karena sangat sulit untuk menerjemahkan infrastruktur dari satu cloud ke cloud lain. Namun, membangun infrastruktur pada dua cloud saja adalah tempat yang kuat – dan sering kali dapat dilakukan – untuk memulai. Kritis untuk membuat ini berhasil adalah memiliki tim yang berpengalaman di setiap cloud yang Anda jalankan.

Tentu saja, tidak ada yang dapat melindungi perusahaan sepenuhnya dari dampak kegagalan besar seperti yang kita lihat minggu ini. Namun, dengan due diligence yang tepat, pendekatan cloud-portabel, desain untuk kegagalan, dan menggunakan “dual-cloud” sebagai batu loncatan untuk multicloud yang sebenarnya, perusahaan dapat jauh lebih gesit ketika insiden cloud besar berikutnya terjadi.