Kuby-core: Quel type d'applications devrions-nous (ne pas) déployer avec Kuby ?

Salut @hovancik. Vous avez tout à fait raison, il n'y a pas grand-chose dans la documentation sur les différents fournisseurs de cloud et leur coût. Je pensais ajouter une matrice de tarification aux documents, mais la solution de déploiement n'a vraiment rien à voir avec le fournisseur de cloud. Imaginez, par exemple, poser la même question à Capistrano :)

Kuby est conçu pour déployer votre application dans n'importe quel cluster Kubernetes, quel que soit le fournisseur de cloud et son coût. En tant que développeur, vous devriez être libre de choisir le fournisseur de cloud qui répond le mieux à vos besoins. Par exemple, je ne choisirais pas EKS ou Azure pour un passe-temps ou un projet personnel - c'est beaucoup trop cher. Pour EKS, les 72 $ / mois que vous avez mentionnés ne concernent littéralement que le plan de contrôle Kubernetes et n'incluent pas le coût des ressources de calcul, du stockage de blocs, etc. Au lieu de cela, j'opterais pour DigitalOcean ou Linode, qui coûtent beaucoup plus cher. -efficace (environ 20 $ / mois pour une instance de 4 Go de RAM, 2 CPU) et vous donne le plan de contrôle gratuitement. Si vous faites partie d'une entreprise qui souhaite utiliser certains des nombreux autres services AWS ou Azure, alors EKS est peut-être la bonne solution pour vous. Le fait est que vous pouvez choisir. Kuby s'en fiche - il est conçu pour fonctionner partout.

Cela dit, serait-il utile de voir une matrice de tarification dans la documentation ? J'hésite à en ajouter un parce que 1) les raisons énumérées ci-dessus, 2) les prix changent fréquemment et 3) je ne veux pas me lancer dans la recommandation de fournisseurs de cloud ou être perçu comme favorisant l'un par rapport à l'autre.

Les pensées?

Salut @camertron , oui, la matrice de tarification est une mauvaise idée.

Comme mon titre l'indique, ce que j'essaie de demander est : quel type d'applications devrions-nous (ne pas) déployer avec Kuby ? En un sens : décrire l'outil en terme de métier :)

J'ai commencé avec hobby vs professional ( =money) , parce que c'est facile, mais j'aimerais en savoir plus sur le type d'applications que vous visez. Est-ce exagéré pour une simple application de rails rendus par un serveur avec db ? Ou c'est le candidat idéal ? Ou plus l'application est compliquée, meilleur sera cet outil pour les développeurs ?

Peut-être que je me trompe et que cela est destiné à toutes sortes d'applications? Vous savez, le genre de pages où ils disent use this tool if et don't use this tool if est ce que je recherche en les vérifiant :)

Ah d'accord je vois ce que tu veux dire. Je dirais que Kuby est destiné à tous les types d'applications, mais il y a certainement certains types qui en bénéficieront plus que d'autres. Vous feriez probablement mieux d'utiliser un dyno Heroku gratuit pour une super petite application qui ne voit pas beaucoup de trafic et qui ne gère que quelques centaines (ou moins) de lignes de base de données. Le fait est que ce n'est pas que Kuby soit un mauvais choix pour ces types d'applications, c'est juste que vous dépenserez probablement moins d'argent et moins d'intelligence pour configurer Heroku. Il est assez difficile de les battre sur la simplicité. Heroku commence à devenir cher lorsque vous avez besoin de plus de ressources, et j'ai constaté que, d'une manière générale, un cluster Kubernetes géré avec un seul nœud déployé avec Kuby est plus rentable que la configuration Heroku équivalente. Oui, Kuby nécessite plus d'intelligence pour être configuré (encore une fois, il est assez difficile de battre git push heroku master ), mais la flexibilité que vous obtenez en vaut la peine à mon humble avis.

Kuby pourrait également ne pas être le bon choix pour les applications très volumineuses et hautement personnalisées qui se sont considérablement écartées des conventions Rails. Je suis sûr que vous pourriez faire fonctionner Kuby pour de telles applications, mais cela signifierait probablement personnaliser Kuby dans une large mesure. Pour ce faire, vous devrez probablement avoir une compréhension plus approfondie du fonctionnement de Docker, Kubernetes et Kuby. Je suppose que cela se résume à votre volonté d'investir du temps dans l'apprentissage des technologies.

Peut-être que la meilleure façon de le dire est que Kuby a été conçu pour servir le même public que Rails lui-même, et devrait être considéré comme résidant au même niveau que l'enregistrement actif, le stockage actif, etc. Vous pourriez raisonnablement dire qu'un ORM est exagéré pour une très petite application, et vous pourriez aussi raisonnablement dire qu'elle vous gêne dans une grande application sur mesure. L'enregistrement actif est conçu pour faire abstraction des complexités de la communication de la base de données, et Kuby est conçu pour faire de même pour le déploiement. Les deux viennent, comme DHH aime le dire, avec des piles incluses.

Merci! Une forme de ceci devrait probablement être sur le Web quelque part :)

D'accord, merci d'avoir soulevé cette question @hovancik :)