Mengapa Situs E-Commerce Anda Memerlukan Pendekatan Multi-Cloud Aktif-Aktif di Musim Liburan Ini

Bagi pemimpin e-commerce, liburan membawa dua kepastian: arus masuk besar-besaran pembeli dan risiko gangguan penyedia cloud yang tinggi. Gangguan cloud besar tampaknya menjadi lebih umum dan lebih menghancurkan. Wilayah AWS US-East-1, misalnya, memiliki sejarah gangguan signifikan di musim liburan. Demikian pula, setiap tahun sekitar Januari, Microsoft Azure cenderung memiliki masalah keterlambatan jaringan atau gangguan jaringan karena rencana rilis atau pengujian di wilayah tertentu. Dan kita hanya perlu melihat kembali ke Juni lalu, ketika gangguan besar Google Cloud memengaruhi berbagai aplikasi, untuk diingatkan bahwa tidak ada penyedia tunggal yang kebal.

Jika Anda bertanggung jawab atas operasi e-commerce, Anda tidak ingin menemukan bahwa meskipun Anda telah mengatur semuanya dengan benar, sesuatu telah berhenti berfungsi selama waktu paling kritis dalam setahun. Kecenderungan gangguan dan masalah penyedia cloud ini mungkin tidak ada dalam radar Anda, dan jujur, mereka tidak seharusnya. Jika Anda adalah insinyur keandalan situs, Anda tidak seharusnya khawatir tentang apakah gangguan platform cloud akan memengaruhi aplikasi Anda, atau mencoba menyesuaikan infrastruktur Anda secara langsung selama masalah. Sebaliknya, Anda harus memeriksa kembali apa yang Anda ketahui tentang multi-cloud.

Aplikasi multi-cloud

Jika organisasi Anda membayar biaya AWS, Azure, dan GCP, Anda memang memiliki ketiga cloud tersebut di disposal Anda. Namun, sementara Anda mungkin menggunakan ketiganya, penting untuk memeriksa apa yang terjadi ketika Anda pergi ke lapisan yang lebih dalam. Apakah beberapa aplikasi Anda khusus AWS, Azure, atau GCP? Apakah mereka akan terus berfungsi jika satu penyedia cloud mengalami gangguan dan Anda perlu beralih ke yang lain dengan cepat?

Aplikasi Anda harus berfungsi dengan sempurna di salah satu cloud. Itulah yang dimaksud dengan setup multi-cloud yang sebenarnya. Jika Anda ingin menjadi cloud-agnostik, Anda tidak bisa hanya membayar untuk multi-cloud; Anda harus memastikan bahwa aplikasi Anda juga multi-cloud.

Selain itu, mengandalkan satu penyedia memperkenalkan keterbatasan bawaan pada kapasitas komputasi, pembatasan laju API, dan ketersediaan regional. Arsitektur multi-cloud yang sebenarnya meningkatkan daya komputasi agregat Anda dan menyediakan ketahanan terhadap keterbatasan ini. Ini membuka kemampuan Anda untuk menskalakan permintaan di luar batas penyedia tunggal, memperluas kapasitas dengan cepat di seluruh geografi, dan memastikan kinerja konsisten selama hari belanja puncak. Namun, memiliki aplikasi yang portabel dan cloud-agnostik hanya langkah pertama; langkah berikutnya adalah mengirimkannya dalam arsitektur yang benar-benar tangguh.

Menskalakan ke pendekatan aktif-aktif

Ini memerlukan persiapan serius oleh DevOps. Sangat sulit untuk memiliki strategi Business Continuity Disaster Recovery (BCDR) yang 100% akurat karena ketika datang ke menjalankan operasi secara langsung, ada beberapa titik kegagalan. Anda tidak ingin menguji strategi BCDR Anda selama gangguan, sehingga Anda mungkin merasa bahwa semua yang dapat Anda lakukan hanyalah memprediksi skenario yang mungkin dan kemudian mempersiapkan diri sesuai dengan itu.

Saran saya kepada insinyur keandalan situs adalah untuk merancang untuk kegagalan secara default. Ini berarti memiliki cloud sekunder atau bahkan cloud tersier yang berjalan dalam keadaan aktif. Strategi BCDR yang terbatas pada satu penyedia adalah satu titik kegagalan; jika penyedia kontrol plane atau backbone jaringan gagal, seluruh rencana pemulihan Anda menjadi tidak berguna.

Selama musim liburan, umum bagi jumlah pengunjung untuk tiba-tiba meningkat, memaksa platform atau aplikasi Anda untuk mulai bekerja dengan kemampuan yang berkurang. Jika Anda telah membuat salinan aplikasi yang berfungsi, sekunder, Anda dapat beralih ke melakukan load balancing sehingga Anda dapat mengalihkan beberapa permintaan ke instance lain dari aplikasi Anda.

Pendekatan aktif-aktif ini berarti Anda memiliki produk yang sepenuhnya digandakan, berjalan di tempat lain. Jika penyedia cloud primer Anda mengalami degradasi parah atau gangguan, Anda dapat dengan mudah beralih 100% lalu lintas ke penyedia sekunder melalui DNS atau load balancer global, membuatnya menjadi titik masuk primer tanpa gangguan bagi pelanggan Anda.

Biaya sebenarnya dari tidak menggunakan multi-cloud

Sementara biaya menjalankan cloud sekunder tidaklah sepele, biaya tersebut tidak signifikan dibandingkan dengan dampak bisnis dari gangguan besar: meminta maaf kepada pelanggan setelah kegagalan keandalan, berusaha untuk meyakinkan mereka bahwa itu tidak akan terjadi lagi, dan meyakinkan mereka untuk tidak meninggalkan Anda untuk salah satu pesaing Anda. Mari kita juga tidak lupa semua pendapatan yang hilang dari penjualan yang tidak dapat dimenangkan kembali. Di FluidCloud, saya telah melihat skenario ini terjadi berulang kali: perusahaan berinvestasi besar-besaran pada satu penyedia, hanya untuk menemukan diri mereka di sisi yang salah dari gangguan tanpa solusi langsung.

Namun, cukup sulit untuk mengontrol biaya jika Anda hanya menggunakan satu penyedia cloud; biaya cloud Anda mungkin terlihat seperti grafik eksponensial. Jika Anda mengadopsi beberapa cloud, grafik eksponensial tersebut hanya akan terlihat lebih curam.

Ketika Anda menggandakan infrastruktur dari cloud primer Anda, Anda secara alami tidak ingin biaya Anda meningkat dua kali lipat. Oleh karena itu, saya sarankan untuk fokus pada cloud yang lebih murah yang menawarkan kinerja kompetitif dengan harga yang lebih rendah. Jika Anda memiliki sekunder yang berjalan di cloud yang lebih murah, Anda masih akan memiliki redundansi aktif-aktif penuh, tetapi dengan biaya yang lebih rendah. Ini adalah situasi yang menguntungkan semua pihak.

Pemikiran Terakhir

Menjalankan aplikasi Anda aktif-aktif di seluruh penyedia cloud tidak hanya berarti membuat cadangan. Ini berarti membangun untuk ketahanan waktu nyata, memastikan bisnis Anda tidak memiliki satu titik kegagalan, dan dapat menawarkan kecepatan konsisten bahkan selama lonjakan lalu lintas.

Di musim liburan ini, jangan hanya berharap untuk keandalan. Bangun untuk itu. Rancang sistem Anda untuk berjalan konsisten, tidak peduli penyedia cloud atau wilayah mana yang gagal. Berikan pengalaman pelanggan yang tanpa cela dengan menerima arsitektur multi-cloud aktif-aktif yang sebenarnya.