Apa pro dan kontra AWS Elastic Beanstalk dibandingkan dengan strategi penempatan lainnya?

Saya cukup baru untuk seluruh tumpukan dan penyebaran Netflix OSS secara umum. Sebagai latar belakang untuk tingkat pengetahuan saya saat ini, di mana peran utama saya adalah sebagai insinyur aplikasi front-end. Namun, saya menikmati sisi operasi hal-hal, jadi saya mencoba untuk menyiapkan strategi penyebaran baru dan alat untuk proyek baru.

Tujuan kita

• Penyebaran super mudah (kami ingin menekan tombol untuk memperbarui produksi)
• Penyebaran otomatis untuk menguji lingkungan (menggunakan Jenkins)
• Kemudahan pemeliharaan (kami memiliki aplikasi untuk menulis, tidak ingin menghabiskan waktu kami mengutak-atik masalah produksi)
• Kemampuan untuk menangani arsitektur berorientasi layanan (banyak aplikasi kecil, berbagai bahasa dan penyimpanan data)
• Fleksibilitas yang cukup untuk memastikan kami tidak perlu mengubah strategi dalam waktu dekat (kami sudah berusaha untuk menjauh dari RightScale)

Kami baik-baik saja dengan waktu pengaturan awal yang lebih sedikit jika hal itu akan menyelamatkan kami dari sakit kepala di masa mendatang.

Jadi, di sepanjang baris ini, saya telah mendengarkan podcast, menonton pembicaraan Ops, dan membaca banyak posting blog dan berdasarkan tujuan kami dan apa yang saya anggap sebagai praktik terbaik, kami mulai membuat rencana menggunakan Asgard, menggulung paket kami ke dalam botol dan menggulungnya menjadi AMI.

Kami telah merencanakan semua ini dan menyukai manfaatnya dibandingkan menggunakan server Chef dan memusatkan instance dengan cepat (kami merasa ini adalah kesalahan yang cenderung terjadi karena timeline kami yang terbatas dan kurangnya pemahaman tentang alur kerja server Chef). Namun, seorang rekan kerja sedikit melihat-lihat sendiri dan merasa seperti Elastic Beanstalk memenuhi kebutuhan kami.

Saya telah melihat ke dalamnya dan memutar lingkungan uji dengan file WAR dan database RDS terlampir. Hal-hal tampaknya bekerja dan saya percaya bahwa kita dapat mengotomatiskan penyebaran ke lingkungan pengujian menggunakan Jenkins melalui AWS API. Tampak cukup sederhana ... mungkin terlalu sederhana.

Yang saya ingin tahu adalah, apa masalahnya? Jika Elastic Beanstalk sangat sederhana dan efektif, mengapa itu tidak dibicarakan lagi? Saya mengalami kesulitan menemukan pendapat dan fakta obyektif yang cukup tentang dua strategi penyebaran yang berbeda, jadi saya pikir saya akan bertanya-tanya.

Apakah Anda menggunakan Elastic Beanstalk? Jika demikian, mengapa dan faktor apa yang menyebabkan keputusan itu? Apa yang Anda suka dan tidak suka?

Jika Anda tidak menggunakan Elastic Beanstalk tetapi mempertimbangkannya, apa yang Anda gunakan dan mengapa Anda tidak menggunakan Elastic Beanstalk?

Apa kelebihan dan kekurangan strategi penyebaran berbasis Pohon Kacang Elastis untuk SOA? Yaitu, akankah Elastic Beanstalk bekerja dengan baik dengan banyak aplikasi kecil yang saling mengandalkan untuk bekerja?

Saya telah mengevaluasi Elastic Beanstalk sebagai tambahan dari penawaran AWS lainnya ketika mencoba untuk memperbaiki contoh AWS linting tangan kami. Alasan saya memilih untuk tidak menggunakannya adalah karena komplikasi yang akan memicu migrasi aplikasi saya yang sudah ada dan tidak dengan penawaran itu sendiri. Masalahnya adalah Anda tidak memiliki banyak kontrol tentang penyebaran aplikasi / konfigurasi server. Jika Anda memulai aplikasi baru maka mungkin bermanfaat untuk tidak menangani hal-hal itu sekarang, jika Anda memiliki aplikasi yang sudah ada maka itu lebih merupakan tantangan untuk masuk dalam model Beanstalk.

Beanstalk memberikan penawaran serupa ke Heroku dan vendor PaaS lainnya tetapi tidak banyak manfaatnya bagi mereka yang hanya ingin fokus membuat aplikasi mereka. Anda setidaknya bisa menentukan sumber daya tervirtualisasi ke tingkat yang lebih besar daripada vendor PaaS lainnya.

Masalah yang saya hadapi dengan aplikasi saya:

• Penyebaran berbasis Git - Saya suka mereka tetapi repo kami adalah 1+ GB. Agak besar untuk mendorong secara teratur. Repo ini juga berisi sekitar 40 aplikasi (yang benar-benar harus dibagi) tetapi itu akan memakan waktu. Mengunggah segala jenis paket bisa berhasil, tetapi sebagian besar aplikasi kita membutuhkan banyak pekerjaan untuk membuatnya menjadi sebuah paket.

• Integrasi dengan layanan lain - Dari apa yang saya lihat, Beanstalk berasumsi bahwa apa pun yang Anda hubungkan adalah layanan tunggal. Ini berfungsi baik jika layanan Anda di belakang dan ELB tetapi kami adalah node terpisah yang kami tekan melalui HAProxy yang berjalan di setiap server aplikasi. Jika Anda menjalankan datastore Anda dan layanan lainnya sebagai titik akhir tunggal, Anda akan baik-baik saja.

Dalam evaluasi saya, saya juga menyertakan OpsWorks dan CloudFormation. OpsWorks memiliki masalah integrasi yang serupa dengan cara otomasi yang ada bekerja untuk aplikasi ini. CloudFormation tidak melakukan lebih dari apa yang sudah dilakukan beberapa skrip Python dan Chef untuk kami.

Saya akhirnya memilih untuk menggunakan AWS Autoscaling Groups sebagai gantinya dengan beberapa otomatisasi yang disediakan oleh Asgard . Ini adalah perubahan terkecil dari kode konfigurasi / aplikasi yang ada dan memberi kami keuntungan yang kami cari, manajemen sederhana dari beberapa server yang tersedia melalui AWS API.

Pembatasan diberlakukan oleh Elastic Beanstalk pada aplikasi Anda sangat membantu. Anda harus memastikan bahwa sebagian besar aplikasi Anda tidak memiliki kewarganegaraan, menyediakan titik akhir untuk suatu layanan, dan bergantung pada layanan lain untuk keadaan. Jika Anda mencoba membuat layanan mandiri yang dapat digunakan kembali, banyak aplikasi di Beanstalk merupakan awal yang baik.

Jika / ketika Anda sampai pada titik menginginkan lebih banyak konfigurasi, OpsWorks adalah langkah besar berikutnya. Peran yang telah ditentukan harus membuat transisi mudah untuk memulai dan menyediakan kerangka kerja otomasi di sekitar Chef untuk membantu mengoordinasikan penyediaan beberapa server.

Saya melihat titik kehilangan kontrol, tetapi saya tidak perlu melihat kewarganegaraan yang diamanatkan. Semua eb benar-benar dilakukan adalah menyebarkan otomatisasi, yang omong-omong luar biasa. Saya melihat titik repositori besar. Saya pikir secara umum bahwa memisahkan fungsi aplikasi logis menjadi aplikasi kacang terpisah, dan kemudian memiliki lingkungan "pementasan", dan "prod" di bawahnya, sangat bagus. Kami memiliki lingkungan modul seperti pengunggah, itu tidak melakukan banyak hal dan secara teori menambahkan banyak biaya, tetapi kemudian Anda menggunakan contoh yang lebih kecil hanya lebih banyak. Kami menjalankan nginx terpusat, dan harus menulis banyak pegangan pesan kustom sns untuk memberi tahu ngnix perubahan dalam kebijakan skala otomatis. Masalah besar lainnya adalah ketidakmampuan untuk menyeimbangkan keseimbangan beban, karena kami menggunakan ngnix, mengapa? elb tidak mendukung websocket.