Flynn: kenapa tidak tsuru?

Ini dibahas tentang golang-kacang . Kesan saya adalah bahwa meskipun beberapa fiturnya serupa, tujuan intinya berbeda.

/ cc @fsouza

@titanous Saya melihat utas ini. Jika perbedaan terbesar antara tsuru dan flynn adalah tsuru khusus untuk web, dengan sedikit usaha dapat dimodifikasi.

Saya percaya bahwa jika kedua proyek ini bersatu akan lebih baik untuk proyek ini dan akan membuat lebih mudah untuk membangun komunitas yang lebih kuat untuk membuat dan memelihara proyek baru ini (tsuru + flynn) seperti yang terjadi dengan rel + merb.

Kami sedang mengerjakan spesifikasi yang lebih lengkap yang akan merinci komponen dan tujuan yang kami rencanakan. Saya pikir akan konstruktif, tunda diskusi ini sampai kita mendorong dokumen itu.

Menutup, karena menurut saya lebih jelas apa perbedaannya sekarang.

Apa perbedaannya? Tidak jelas bagi saya, apakah ada beberapa sumber di luar sana yang dapat Anda rekomendasikan yang memahami semua pekerjaan PaaS yang sedang dilakukan?

Saya telah mencoba mencari tahu melalui penelitian tetapi saya terus belajar tentang semakin banyak sistem PaaS yang dibuat dengan Docker, hal-hal terasa benar-benar terfragmentasi; sangat sulit untuk mengikutinya ... Masing-masing sistem ini membutuhkan waktu dan dedikasi untuk menyiapkan dan mencoba sebelum orang benar-benar mengetahui apa itu - adakah cara yang lebih mudah untuk mengenal semua proyek yang terjadi di sini? ruang tanpa butuh waktu lama dan menjadi lubang kelinci yang tidak pernah berakhir?

Dari apa yang saya lihat sejauh ini, Flynn terlihat cukup manis - saya sangat senang untuk segera mencobanya.

PS Saya sampai di sini dengan Googling "tsuru flynn"

@keyvanatehi Terima kasih atas minat Anda.

Sulit untuk mengikuti perkembangan semua proyek PaaS di luar sana, terutama karena banyak yang mengikuti peta jalan pribadi atau tidak konsisten. Secara umum, inilah yang menurut kami perbedaan antara Flynn dan sebagian besar proyek PaaS lainnya (bukan perbandingan langsung dengan tsuru, hanya ruang secara umum):

Flynn lebih ambisius. Flynn dapat menjalankan apapun yang berjalan di Linux termasuk layanan stateful. Kami memanfaatkan kemampuan ini untuk mengemas database umum bersama dengan Flynn, sehingga sebagian besar pengguna dan proyek tidak akan pernah lagi mengelola database secara manual. Komponen Flynn bersifat modular yang memudahkan penggunaan kembali, modifikasi, dan penggantinya untuk menciptakan solusi yang tepat untuk kebutuhan Anda. Kami benar-benar ingin Flynn menjadi perangkat tunggal yang "menyelesaikan" operasi untuk setiap proyek dan organisasi. Masih banyak lagi yang akan datang termasuk agregasi log, metrik, integrasi berkelanjutan bersama dengan solusi generasi berikutnya untuk alur kerja jaringan dan pengembangan.

Sebagian besar proyek PaaS lainnya setidaknya salah satu dari yang berikut: sulit / lambat untuk disiapkan dan diterapkan, hanya berguna untuk jenis aplikasi tertentu, mengharuskan pengembang untuk merancang ulang aplikasi mereka, dan monolitik. Singkatnya, kami percaya Flynn mencoba memecahkan masalah sulit dan sebagian besar proyek lain tidak, karena usia mereka, basis pengguna yang ada, dan motivasi desain.

Saat Flynn mencapai stabilitas produksi dan penyelesaian fitur, kami akan mencoba mendokumentasikan perbedaan per proyek.

@danielsiders terima kasih! Saya menantikan untuk melihat kalian berinovasi di ruang ini. Saya pasti menderita karena memiliki terlalu banyak operasi yang jatuh di pundak saya (Itulah sebabnya saya melihat Docker dan alat-alat di sekitarnya). Saya ingin percaya bahwa operasi dapat diselesaikan, seolah-olah ...

Sejauh ini pengalaman saya telah menggunakan flynn-demo (berhasil) yang sepertinya seperti deis (yang belum saya coba secara langsung, tetapi mereka memiliki video perulangan yang bagus yang menunjukkan perilaku seperti heroku). Jadi pada level yang dangkal ini, deis, flynn dan heroku tampak identik.

Itu poin bagus tentang peta jalan pribadi - saya pikir mungkin ini terlalu dini bagi saya untuk berharap untuk memahami semua itu. Tampaknya jauh lebih mudah untuk hanya berkomitmen pada satu upaya atau lainnya daripada mencoba melacak, membedakan perbedaan antara, dan mencoba menilai setiap upaya ... masing-masing inovatif dan menarik!

bagaimanapun, saat-saat yang menyenangkan - terima kasih telah menjadi bagian dari membuat ini semua terjadi, bahkan jika saya belum dapat sepenuhnya memahaminya :)

@keyvanfatehi kebanyakan PaaS mendukung penerapan aplikasi bergaya Heroku (git push). Hal yang sangat berbeda adalah jenis aplikasi yang dapat diterapkan dan apa yang terjadi setelah aplikasi diterapkan.

(nb: Flynn juga mendukung banyak paradigma penerapan lainnya seperti docker pull dan git pull dan apa pun yang ingin Anda bangun. Bahkan FTP tidak akan sulit)

@keyvanfatehi , di Tsuru kami percaya bahwa akan lebih efisien jika memerlukan beberapa perubahan aplikasi kecil (seperti konfigurasi berdasarkan lingkungan dan penggunaan penyimpanan objek untuk file statis), karena mau tidak mau Anda perlu mendesain aplikasi Anda agar sesuai dengan paradigma cloud ( misalnya: perlu diskalakan secara horizontal tanpa masalah). Tapi kami melakukannya dengan sangat baik sehingga pengguna kami mendapatkannya dengan sangat cepat, kami sudah memiliki produk yang sedang diproduksi di sini (di Globo.com).
Tentang layanan, mereka terlalu spesifik untuk ditangani dengan baik dengan satu aplikasi (bayangkan betapa sulitnya menangani database, nosql, redis, memcache, elasticsearch, penyimpanan objek, dll). Kami lebih suka menentukan api layanan (di mana logika bisnis untuk menangani layanan akan ditempatkan) dan tsuru akan menangani dengan cara yang sama dengan layanan apa pun, tidak peduli betapa berbedanya mereka.

Kami sangat ramah, dan sangat terbuka untuk kontribusi dan ide-ide baru. Kami masih berpikir bahwa akan sangat bagus untuk bekerja dengan flynn dalam satu solusi (kami dapat memperluas tsuru untuk bertemu dengan flynn ideal di masa depan), tetapi kami sangat menghormati pendapat dan visi mereka, karena mereka sangat berambisi seperti milik kami :-)

TL; DR
Kami tahu betapa pentingnya layanan, jadi kami mengembangkan cara yang elegan untuk menangani kebutuhan itu. Tsuru dapat menangani layanan apa pun dengan api layanan yang terdefinisi dengan baik (dengan beberapa titik masuk sederhana seperti buat, hapus, ikat, rencanakan). Jadi, semua kerumitan layanan tertentu akan ditangani oleh api-layanannya sendiri. Mari beri Anda contoh tentang Redis API kami: ketika Anda menjalankan # tsuru service-add redis (nama layanan) redis_blognews (serviceinstancename) plus (plan), itu akan membuat instance redis dengan nama redis_blognews dan plan plus (yang menyediakan 2 instance redis dengan ketersediaan tinggi). Tsuru tidak tahu bagaimana itu akan dibuat (bahkan jika itu akan memiliki ketersediaan tinggi), itu akan ditangani sepenuhnya oleh api-layanan. Ini juga memungkinkan untuk menggunakan layanan eksternal (bahkan berpemilik) hanya membuat layanan-api untuk itu tanpa menyentuh kode tsuru. Jadi, akan jauh lebih fleksibel untuk menangani layanan, dan menghindari peningkatan kompleksitas itu di Tsuru. Setelah itu Anda dapat menggunakan # tsuru bind redis_blognews --app yourblognewsapp dan tsuru akan memasukkan kredensial layanan ke dalam aplikasi Anda

Saya baru mengenal PaaSes dan itu membingungkan. Aku memilih Tsuru dan aku sudah sedikit mengotak-atiknya. Tampak bagi saya bahwa itu tidak jauh berbeda dari tujuan Flynn. Anda dapat menjalankan stateful menggunakan API layanan mereka dan ini sangat modular, di mana Anda memiliki tsuru-api, docker-cluster, gandalf, dll.

Saya masih bertanya-tanya apakah upaya menggabungkan akan menghasilkan produk yang lebih baik.

Saya harus setuju dengan @msabramo di sini, saya masih tidak melihat ada gunanya mengapa membangun PaaS baru yang memiliki semua fitur Tsuru. Saya juga setuju bahwa menggabungkan upaya akan menghasilkan produk yang luar biasa.