Cara Memilih Penyedia Cloud

Saat memilih penyedia cloud, Anda dapat melihat pengenalan merek, fitur keamanan dan penyimpanan, serta item lainnya. Tetapi penyedia cloud bergantung pada jaringan seperti kita semua, dan tidak semuanya dibuat atau dikonfigurasi sama.

Secara umum, bagi mereka yang mempertimbangkan cloud, penting untuk mencocokkan lokasi pengguna akhir Anda dan lokasi cloud yang akan melayani mereka. Anda juga harus menargetkan kinerja dasar yang berkelanjutan saat pertama kali memulai dengan penyedia cloud, yang akan membantu jika ada masalah kinerja.

Karena masing-masing penyedia cloud utama memiliki banyak titik kehadiran, penting bagi Anda untuk mempertimbangkan dampak jaringan dari pemindahan data atau aplikasi Anda dari kantor Anda ke cloud. Untuk mengilustrasikan dampak ini, kami telah menyiapkan perbandingan cepat dari tiga penyedia teratas.

Pengujian, Pengujian

Untuk melihat di balik sampul tiga besar penyedia, kami telah melakukan beberapa pengujian. Kami menyiapkan sistem demo SaaS CRM di titik kehadiran barat laut (lokasi tepatnya bervariasi tergantung penyedia) untuk tiga penyedia cloud publik terbesar:AWS, Azure, dan Google Cloud. Kemudian, kami menunggu hasilnya keluar, dan itu pasti menarik.

Pengujian dari Los Angeles

Grafik di bawah ini menunjukkan lalu lintas jaringan dari Los Angeles ke lokasi terdekat dari penyedia utama di wilayah barat laut. Dengan CRM kami yang berbasis di barat laut, tidak ada pemenang yang jelas. Google dan AWS berlokasi di Oregon yang berdekatan, sementara Azure tidak jauh dari mereka di California Utara. Di sini, AWS mungkin saja menang, tetapi semuanya menunjukkan variabilitas ekstrem selama satu bulan (lebih rendah lebih baik di sini). Perbedaan jarak fisik tidak sepenuhnya terlihat sebagai waktu jaringan tambahan untuk permintaan web (untuk referensi, dibutuhkan 40 mdtk untuk lalu lintas lintas negara). Yang paling mungkin terjadi adalah perubahan perutean.

Los Angeles → Wilayah Barat Laut  | AWS  | Azure  | Google

Pengujian dari Atlanta

Contoh berikut ini menunjukkan rute jaringan tiga penyedia dari monitor kami yang berbasis di Atlanta ke titik keberadaan atau zona ketersediaan di barat laut. AWS adalah penyedia cloud paling lambat, meskipun ketiganya mengalami variabilitas sepanjang jendela selama sebulan. Dengan pemisahan fisik yang lebih lama antara pengguna dan server sintetis, kami dapat mengabaikan variasi kecil dalam kecepatan jaringan. Namun, jelas bahwa AWS menderita latensi tambahan rata-rata 1,5 detik. Penyebabnya bisa beragam, tetapi dengan waktu tambahan hingga dua detik untuk permintaan web, ini dapat menyebabkan tingkat frustrasi pengguna yang lebih tinggi. Kami juga dapat melihat beberapa konsistensi dalam lonjakan yang diamati, yang menunjukkan bahwa lalu lintas mungkin berbagi rute dan masalah kemacetan harian.

Penting untuk diingat bahwa penerapan kami yang berbasis di Seattle mungkin bukan pilihan yang ideal, atau umum, untuk perusahaan yang berbasis di Atlanta. Namun dengan banyaknya startup yang keluar dari wilayah Silicon Valley, ada kemungkinan besar bahwa banyak aplikasi SaaS yang Anda gunakan setiap hari melakukan perjalanan pulang pergi jarak jauh ini.

Atlanta → Wilayah Barat Laut  | AWS  | Azure  | Google

Pengujian dari New York

Contoh terakhir kami di bawah ini menunjukkan kinerja jaringan di sepanjang jalur jaringan dari zona New York ke CRM kami yang berbasis di barat laut. AWS masih menunjukkan waktu respons paling lambat dari ketiga penyedia. Google dan Azure secara konsisten lebih cepat, kecuali satu masalah kemacetan yang diamati pada akhir Januari. Karena kita dapat berasumsi bahwa seiring waktu internet akan merutekan sebagian besar lalu lintas ini secara serupa di seluruh negeri, ada indikasi bagus bahwa perutean di belakang firewall AWS mungkin menjadi penyebab latensi tambahan.

New York → Wilayah Barat Laut  | AWS  | Azure  | Google

Apa yang Ditemukan Pengujian Cloud kami

Kami tidak memiliki ukuran sampel yang besar, dan penerapan pengujian kami tidak disesuaikan dengan kompleksitas sebagian besar aplikasi modern, tetapi hasil kami mengingatkan kami betapa pentingnya melakukan penelitian lokasi saat Anda merencanakan penerapan cloud Anda. Keluar dari peta untuk melihat lokasi layanan dan aplikasi Anda saat berada di cloud. Kemudian cocokkan dengan lokasi pengguna aplikasi dan layanan tersebut.

Ada sejumlah alasan yang dapat berkontribusi pada apa yang tampak seperti kegagalan di pihak AWS untuk memberikan respons cepat, seperti perjanjian mengintip di tengah negara atau perutean tambahan di belakang firewall mereka. Yang jelas adalah bahwa kinerja berbeda tergantung di mana pengguna akhir Anda berada. Menyadari fakta ini akan menghasilkan keputusan yang lebih baik dalam hal kinerja.

Menguji penyedia cloud bukanlah satu-satunya tujuan kami, tetapi Anda bisa mendapatkan visibilitas yang kami lakukan (dan Anda butuhkan) dengan alat AppNeta untuk semua aplikasi cloud Anda. Wawasan jaringan semacam ini dapat menyelamatkan hari ketika pengguna mengeluh tentang pelambatan atau pemadaman dan Anda perlu mengidentifikasi akar penyebab penurunan kinerja.