Kuby-core: 我们应该（不）使用 Kuby 部署什么样的应用程序？

嘿@hovancik。 您是绝对正确的，文档中没有太多关于各种云提供商及其成本的信息。 我正在考虑在文档中添加定价矩阵，但部署解决方案确实与云提供商无关。 想象一下，例如，向 Capistrano 提出同样的问题 :)

Kuby 旨在将您的应用程序部署到任何 Kubernetes 集群中，无论云提供商和成本如何。 作为开发人员，您应该可以自由选择最能满足您需求的云提供商。 例如，我不会为爱好或个人项目选择 EKS 或 Azure——它太贵了。 对于 EKS，您提到的 72 美元/月实际上仅适用于 Kubernetes 控制平面，不包括任何计算资源、块存储等的成本。相反，我会选择 DigitalOcean 或 Linode，它们的成本要高得多- 有效（大约 20 美元/月，4gb RAM，2 个 CPU 实例）并免费为您提供控制平面。 如果您所在的企业希望使用其他众多 AWS 或 Azure 服务，那么 EKS 可能是适合您的解决方案。 关键是你可以选择。 Kuby 不在乎——它被设计成可以在任何地方工作。

也就是说，在文档中查看定价矩阵会有所帮助吗？ 我犹豫要不要添加一个，因为 1) 上面列出的原因，2) 价格经常变化，以及 3) 我不想涉足推荐云提供商或被视为偏爱其中之一的业务。

想法？

嗨@camertron ，是的，定价矩阵是个坏主意。

正如我的标题所说，我想问的是：我们应该（不）使用 Kuby 部署什么样的应用程序？ 从某种意义上说：用工作术语描述工具:)

我从hobby vs professional ( =money) 开始，因为它很容易，但我想更多地了解您的目标是哪种应用程序。 对于带有 db 的简单服务器渲染的 rails 应用程序来说，这是否有点矫枉过正？ 或者那是完美的候选人？ 或者越复杂的应用程序对开发者来说这个工具就越好？

也许我误解了，这适用于所有类型的应用程序？ 你知道，他们说use this tool if和don't use this tool if的那种页面是我在检查它们时要寻找的:)

啊，好吧，我明白你的意思了。 我会说 Kuby 适用于所有类型的应用程序，但肯定有一些类型会比其他类型受益更多。 对于一个流量不大且只管理几百（或更少）数据库行的超小型应用程序，您可能最好使用免费的 Heroku dyno。 问题是，对于这些类型的应用程序来说，Kuby 并不是一个糟糕的选择，只是你可能会花更少的钱和更少的脑力来设置 Heroku。 在简单性上很难击败他们。 但是，当您需要更多资源时，Heroku 开始变得昂贵，而且我发现，一般来说，使用 Kuby 部署的具有单个节点的托管 Kubernetes 集群比等效的 Heroku 设置更具成本效益。 是的，Kuby 需要更多的脑力来配置（同样，很难击败git push heroku master ），但是您因此获得的灵活性是值得的，恕我直言。

对于明显偏离 Rails 约定的大型、高度定制的应用程序，Kuby 也可能不是正确的选择。 我相信您可以让 Kuby 为此类应用程序工作，但这可能意味着在很大程度上自定义 Kuby。 为此，您可能必须对 Docker、Kubernetes 和 Kuby 的工作方式有更深入的了解。 我想这归结为你愿意花时间学习技术。

也许最好的说法是 Kuby 被设计为服务于与 Rails 本身相同的受众，并且应该被认为与活动记录、活动存储等处于同一级别。你可能有理由说 ORM 对于一个非常小的应用程序，你也可以合理地说它在一个大型的定制应用程序中妨碍了你。 Active Record 旨在抽象出数据库通信的复杂性，而 Kuby 旨在为部署做同样的事情。 正如 DHH 喜欢说的那样，两者都包含电池。

谢谢！ 这种形式的某种形式可能应该在网络上的某个地方:)

同意，谢谢你提出这个@hovancik :)