Mengapa Situs E-Commerce Anda Memerlukan Pendekatan Multi-Awan Aktif-Aktif Selama Musim Liburan Ini

Bagi pemimpin e-commerce, liburan membawa dua kepastian: peningkatan besar dalam jumlah pembeli dan peningkatan risiko gangguan penyedia awan. Gangguan awan besar tampaknya menjadi lebih umum dan lebih menghancurkan. Wilayah AWS US-East-1, misalnya, memiliki sejarah gangguan signifikan selama musim liburan. Demikian pula, setiap tahun sekitar Januari, Microsoft Azure cenderung mengalami masalah keterlambatan jaringan atau gangguan jaringan karena rencana rilis atau pengujian di beberapa wilayah. Dan kita hanya perlu melihat kembali ke Juni lalu, ketika gangguan besar Google Cloud mempengaruhi 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. Tren gangguan dan masalah penyedia awan ini mungkin tidak ada dalam radar Anda, dan sebenarnya, mereka tidak seharusnya. Jika Anda adalah insinyur keandalan situs, Anda tidak seharusnya khawatir tentang apakah gangguan platform awan akan mempengaruhi aplikasi Anda, atau mencoba menyesuaikan infrastruktur Anda secara langsung selama gangguan. Sebaliknya, Anda harus memeriksa kembali apa yang Anda ketahui tentang multi-awan.

Aplikasi multi-awan

Jika organisasi Anda membayar biaya AWS, Azure, dan GCP, Anda memang memiliki ketiga awan tersebut. 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 untuk AWS, Azure, atau GCP? Apakah mereka akan terus berfungsi jika satu penyedia awan mengalami gangguan dan Anda perlu beralih ke yang lain?

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

Selain itu, mengandalkan satu penyedia memperkenalkan keterbatasan bawaan pada kapasitas komputasi, pembatasan laju API, dan ketersediaan regional. Arsitektur multi-awan 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-hari belanja puncak. Namun, memiliki aplikasi yang portabel dan netral awan hanya langkah pertama; langkah berikutnya adalah mengirimkannya dalam arsitektur yang benar-benar tangguh.

Menskalakan ke pendekatan aktif-aktif

Hal ini memerlukan persiapan yang serius oleh DevOps. Sangat sulit untuk memiliki strategi Business Continuity Disaster Recovery (BCDR) yang 100% akurat karena ketika datang ke menjalankan operasi 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.

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

Selama musim liburan, umum untuk jumlah pengunjung 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 lengkap yang diduplikat, berjalan di tempat lain. Jika penyedia awan primer Anda mengalami degradasi parah atau gangguan, Anda dapat dengan mudah beralih 100% lalu lintas Anda ke penyedia sekunder melalui DNS atau load balancer global, membuatnya menjadi titik masuk utama tanpa gangguan pada pelanggan Anda.

Biaya nyata dari tidak menggunakan multi-awan

Sementara biaya menjalankan awan sekunder tidaklah sepele, biaya tersebut tidak signifikan dibandingkan dengan dampak bisnis dari gangguan besar: meminta maaf kepada pelanggan setelah kegagalan keandalan, mencoba 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 Anda menangkan kembali. Di FluidCloud, saya telah melihat skenario ini berulang kali: perusahaan berinvestasi besar-besaran pada satu penyedia, hanya untuk menemukan diri mereka di sisi yang salah dari gangguan tanpa solusi segera.

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

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

Pemikiran Akhir

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

Musim liburan ini, jangan hanya berharap pada keandalan. Bangun untuk itu. Rancang sistem Anda untuk berjalan konsisten, tidak peduli penyedia awan atau wilayah mana yang gagal. Berikan pengalaman pelanggan yang sempurna dengan menerima arsitektur multi-awan aktif-aktif yang sebenarnya.