Kuby-core: ما نوع التطبيقات التي يجب (لا) نشرها مع Kuby؟

يا @ hovancik. أنت محق تمامًا ، لا يوجد الكثير في التوثيق حول مختلف موفري السحابة ومقدار تكلفتهم. كنت أفكر في إضافة مصفوفة أسعار إلى المستندات ، لكن حل النشر لا علاقة له حقًا بموفر السحابة. تخيل ، على سبيل المثال ، طرح نفس السؤال على Capistrano :)

تم تصميم Kuby لنشر تطبيقك في أي مجموعة Kubernetes ، بغض النظر عن موفر السحابة ومقدار تكلفته. أنت كمطور يجب أن تكون حراً في اختيار أي مزود سحابي يخدم احتياجاتك بشكل أفضل. على سبيل المثال ، لن أختار EKS أو Azure لهواية أو مشروع شخصي - فهي باهظة الثمن. بالنسبة إلى EKS ، فإن مبلغ 72 دولارًا / شهرًا الذي ذكرته مخصص حرفيًا فقط لطائرة التحكم Kubernetes ، ولا يشمل تكلفة أي موارد حسابية ، أو تخزين كتلة ، وما إلى ذلك. بدلاً من ذلك ، سأصل إلى DigitalOcean أو Linode ، وهما تكلفة أعلى بكثير - فعال (حوالي 20 دولارًا / شهرًا لذاكرة وصول عشوائي سعتها 4 جيجا بايت ، و 2 وحدة معالجة مركزية) ويمنحك مستوى التحكم مجانًا. إذا كنت جزءًا من شركة تريد استخدام بعض خدمات AWS أو Azure العديدة الأخرى ، فربما يكون EKS هو الحل المناسب لك. النقطة المهمة هي أنك تختار. Kuby لا يهتم - إنه مصمم للعمل في كل مكان.

بعد قولي هذا ، هل سيكون من المفيد رؤية مصفوفة تسعير في الوثائق؟ أنا متردد في إضافة واحد لأن 1) الأسباب المذكورة أعلاه ، 2) تتغير الأسعار بشكل متكرر ، و 3) لا أريد الدخول في أعمال التوصية بموفري الخدمات السحابية أو أن يُنظر إلي على أنني أفضّل أحدهم على الآخر.

أفكار؟

مرحبًا camertron ، نعم ، مصفوفة التسعير فكرة سيئة.

كما يقول العنوان ، ما أحاول طرحه هو: ما نوع التطبيقات التي يجب (لا) نشرها مع Kuby؟ بمعنى: صِف الأداة في مصطلح الوظيفة :)

لقد بدأت hobby vs professional (= المال) ، لأنه سهل ، لكني أود أن أسمع المزيد عن نوع التطبيقات التي تستهدفها. هل هذا مبالغة في تطبيق القضبان البسيط الذي يقدمه الخادم مع db؟ أم أن هذا هو المرشح المثالي؟ أو كلما كان التطبيق أكثر تعقيدًا ، كانت هذه الأداة أفضل للمطورين؟

ربما أنا أسيء فهم وهذا مخصص لجميع أنواع التطبيقات؟ كما تعلم ، فإن نوع الصفحات التي يقولون فيها use this tool if و don't use this tool if هو ما أبحث عنه عند التحقق منهم :)

آه حسنًا ، أرى ما تعنيه. أود أن أقول إن Kuby مخصص لجميع أنواع التطبيقات ، ولكن هناك بالتأكيد بعض الأنواع التي ستستفيد منه أكثر من غيرها. ربما يكون من الأفضل لك استخدام Heroku dyno المجاني لتطبيق صغير جدًا لا يرى الكثير من حركة المرور والذي يدير فقط بضع مئات (أو أقل) من صفوف قاعدة البيانات. الأمر ليس أن Kuby هو خيار سيء لهذه الأنواع من التطبيقات ، إنه من المحتمل أن تنفق أموالًا أقل وقدرة ذهنية أقل على إعداد Heroku. من الصعب التغلب عليهم بالبساطة. يبدأ Heroku في أن يصبح مكلفًا عندما تحتاج إلى المزيد من الموارد ، ووجدت ، بشكل عام ، أن مجموعة Kubernetes المُدارة مع عقدة واحدة منتشرة مع Kuby تكون أكثر فعالية من حيث التكلفة من إعداد Heroku المكافئ. نعم ، يتطلب Kuby مزيدًا من القدرات العقلية لتكوينه (مرة أخرى ، من الصعب جدًا التغلب على git push heroku master ) ، لكن المرونة التي تحصل عليها نتيجة لذلك تستحق العناء IMHO.

قد لا يكون Kuby أيضًا هو الخيار الصحيح للتطبيقات الكبيرة جدًا والمخصصة للغاية والتي انحرفت بشكل كبير عن اتفاقيات ريلز. أنا متأكد من أنه يمكنك جعل Kuby يعمل مع مثل هذه التطبيقات ، ولكن من المحتمل أن يعني ذلك تخصيص Kuby إلى حد كبير. للقيام بذلك ، من المحتمل أن يكون لديك فهم أعمق لكيفية عمل Docker و Kubernetes و Kuby. أعتقد أن الأمر يتلخص في مدى استعدادك لاستثمار الوقت في تعلم التقنيات.

ربما تكون أفضل طريقة لقول ذلك هي أن Kuby تم تصميمه لخدمة نفس الجمهور مثل Rails نفسها ، ويجب اعتباره مقيمًا في نفس مستوى السجل النشط والتخزين النشط وما إلى ذلك. قد تقول بشكل معقول أن ORM مبالغة في تطبيق صغير جدًا ، وقد تقول أيضًا بشكل معقول أنه يقف في طريقك في تطبيق كبير مفصل حسب الطلب. تم تصميم السجل النشط للتخلص من تعقيدات اتصال قاعدة البيانات ، وتم تصميم Kuby للقيام بنفس الشيء للنشر. يأتي كلاهما ، كما تحب DHH ، مع البطاريات المضمنة.

شكرا! من المحتمل أن يكون هناك شكل من أشكال هذا على الويب في مكان ما :)

متفق عليه ، شكرًا على طرح هذا الموضوع @ hovancik :)