Kuby-core: Aplikasi seperti apa yang harus kami (tidak) gunakan dengan Kuby?

Hai @hovancik. Anda benar sekali, tidak banyak dokumentasi tentang berbagai penyedia cloud dan berapa biayanya. Saya sedang berpikir untuk menambahkan matriks harga ke dokumen, tetapi solusi penerapan benar-benar tidak ada hubungannya dengan penyedia cloud. Bayangkan, misalnya, menanyakan pertanyaan yang sama kepada Capistrano :)

Kuby dirancang untuk men-deploy aplikasi Anda ke cluster Kubernetes mana pun, terlepas dari penyedia cloud dan berapa biayanya. Anda sebagai pengembang harus bebas memilih penyedia cloud mana pun yang paling sesuai dengan kebutuhan Anda. Misalnya, saya tidak akan memilih EKS atau Azure untuk hobi atau proyek pribadi - itu terlalu mahal. Untuk EKS, $72/bln yang Anda sebutkan sebenarnya hanya untuk bidang kontrol Kubernetes, dan tidak termasuk biaya sumber daya komputasi apa pun, penyimpanan blok, dll. Sebagai gantinya, saya akan menggunakan DigitalOcean atau Linode, yang jauh lebih mahal. -efektif (sekitar $20/bln untuk RAM 4gb, 2 CPU instans) dan memberi Anda bidang kontrol gratis. Jika Anda adalah bagian dari bisnis yang ingin menggunakan beberapa dari banyak layanan AWS atau Azure lainnya, maka mungkin EKS adalah solusi yang tepat untuk Anda. Intinya adalah Anda harus memilih. Kuby tidak peduli - itu dirancang untuk bekerja di mana saja.

Yang mengatakan, apakah akan membantu untuk melihat matriks harga dalam dokumentasi? Saya ragu untuk menambahkan satu karena 1) alasan yang tercantum di atas, 2) harga sering berubah, dan 3) saya tidak ingin masuk ke bisnis merekomendasikan penyedia cloud atau dianggap lebih menyukai satu dari yang lain.

Pikiran?

Hai @camertron , ya, matriks harga adalah ide yang buruk.

Seperti yang saya katakan di judul, yang ingin saya tanyakan adalah: Aplikasi seperti apa yang harus kami (tidak) gunakan dengan Kuby? Dalam arti: menggambarkan alat dalam hal pekerjaan :)

Saya mulai dengan hobby vs professional ( =money) , karena ini mudah, tetapi saya ingin mendengar lebih banyak tentang jenis aplikasi yang Anda tuju. Apakah ini berlebihan untuk aplikasi Rails yang dibuat server sederhana dengan db? Atau itu kandidat yang sempurna? Atau semakin rumit aplikasi, semakin baik alat ini untuk pengembang?

Mungkin saya salah paham dan ini dimaksudkan untuk semua jenis aplikasi? Anda tahu, jenis halaman di mana mereka mengatakan use this tool if dan don't use this tool if adalah apa yang saya cari saat memeriksanya :)

Ah oke aku mengerti maksudmu. Saya akan mengatakan Kuby dimaksudkan untuk semua jenis aplikasi, tetapi tentu saja ada beberapa jenis yang akan mendapat manfaat lebih dari yang lain. Anda mungkin lebih baik menggunakan dyno Heroku gratis untuk aplikasi super kecil yang tidak melihat banyak lalu lintas dan yang hanya mengelola beberapa ratus (atau kurang) baris basis data. Masalahnya, bukan karena Kuby adalah pilihan yang buruk untuk jenis aplikasi ini, hanya saja Anda cenderung menghabiskan lebih sedikit uang dan lebih sedikit kekuatan otak untuk menyiapkan Heroku. Cukup sulit untuk mengalahkan mereka dalam kesederhanaan. Heroku mulai menjadi mahal ketika Anda membutuhkan lebih banyak sumber daya, dan saya telah menemukan bahwa, secara umum, cluster Kubernetes yang dikelola dengan satu node yang digunakan dengan Kuby lebih hemat biaya daripada pengaturan Heroku yang setara. Ya, Kuby membutuhkan lebih banyak kekuatan otak untuk mengkonfigurasi (sekali lagi, cukup sulit untuk mengalahkan git push heroku master ), tetapi fleksibilitas yang Anda dapatkan sebagai hasilnya sangat berharga IMHO.

Kuby juga mungkin bukan pilihan yang tepat untuk aplikasi yang sangat besar dan sangat disesuaikan yang telah menyimpang secara signifikan dari konvensi Rails. Saya yakin Anda bisa membuat Kuby bekerja untuk aplikasi semacam itu, tetapi itu mungkin berarti menyesuaikan Kuby ke tingkat yang besar. Untuk melakukannya, Anda mungkin harus memiliki pemahaman yang lebih dalam tentang cara kerja Docker, Kubernetes, dan Kuby. Saya kira itu bermuara pada seberapa bersedia Anda menginvestasikan waktu untuk mempelajari teknologi.

Mungkin cara terbaik untuk mengatakannya adalah bahwa Kuby dirancang untuk melayani audiens yang sama dengan Rails itu sendiri, dan harus dianggap berada pada level yang sama dengan catatan aktif, penyimpanan aktif, dll. Anda mungkin dapat mengatakan bahwa ORM berlebihan untuk aplikasi yang sangat kecil, dan Anda mungkin juga mengatakan itu menghalangi Anda dalam aplikasi besar yang dipesan lebih dahulu. Rekaman aktif dirancang untuk mengabstraksikan kompleksitas komunikasi basis data, dan Kuby dirancang untuk melakukan hal yang sama untuk penerapan. Keduanya datang, seperti yang sering dikatakan DHH, dengan baterai disertakan.

Terima kasih! Beberapa bentuk ini mungkin harus ada di web di suatu tempat :)

Setuju, terima kasih telah mengemukakan ini @hovancik :)