こんにちは、
どこかで(どこにも表示されなかったので、間違っている場合は修正してください)、Kubyでデプロイする必要があるアプリと配置しないアプリの種類を教えてください。
趣味のアプリをEKSにデプロイするのは高くつくかもしれないと思いますか? 使用したことはありませんが、彼らのWebサイトには次のように書かれています。 You pay $0.10 per hour for each Amazon EKS cluster that you create.
これは月額約72米ドルですよね? サーバーやデータベースなどであるかどうかはわかりません。
この場合、DokkuやHerokuのようなものの方がはるかに安価です。
とにかく、そのような議論はおそらくお金だけでなく、全体的な技術的なやり過ぎなどについてであるべきです。
ねえ@hovancik。 あなたは絶対に正しいです、さまざまなクラウドプロバイダーとそれらがいくらかかるかについてのドキュメントには多くはありません。 ドキュメントに価格マトリックスを追加することを考えていましたが、展開ソリューションは実際にはクラウドプロバイダーとは何の関係もありません。 たとえば、カピストラーノに同じ質問をすることを想像してみてください:)
Kubyは、クラウドプロバイダーやコストに関係なく、アプリを任意のKubernetesクラスターにデプロイするように設計されています。 開発者としてのあなたは、ニーズに最適なクラウドプロバイダーを自由に選択できるはずです。 たとえば、趣味や個人的なプロジェクトにEKSやAzureを選択することはありません。これは、はるかに高額です。 EKSの場合、あなたが言及した月額72ドルは、文字通りKubernetesコントロールプレーンのみであり、コンピューティングリソース、ブロックストレージなどのコストは含まれていません。代わりに、はるかにコストの高いDigitalOceanまたはLinodeを利用します。 -効果的(4GB RAM、2CPUインスタンスで月額約$ 20)で、コントロールプレーンを無料で提供します。 他の多数のAWSまたはAzureサービスのいくつかを使用したいビジネスの一部である場合は、EKSが適切なソリューションである可能性があります。 重要なのは、あなたが選択できるということです。 Kubyは気にしません-どこでも動作するように設計されています。
そうは言っても、ドキュメントで価格マトリックスを確認することは役に立ちますか? 1)上記の理由、2)価格が頻繁に変わる、3)クラウドプロバイダーを推奨したり、一方を優先していると見なされたりするビジネスに参入したくないため、1つ追加するのをためらっています。
考え?
こんにちは@camertron 、ええ、価格設定マトリックスは悪い考えです。
タイトルが言うように、私が尋ねようとしているのは、Kubyでどのような種類のアプリをデプロイする必要があるか(しないか)です。 ある意味で:仕事の観点からツールを説明してください:)
簡単なのでhobby vs professional
(= money)から始めましたが、どのようなアプリを目指しているのか、もっと知りたいです。 これは、dbを使用した単純なサーバーレンダリングされたRailsアプリにとってはやり過ぎですか? それともそれは完璧な候補ですか? または、アプリが複雑であればあるほど、このツールは開発者にとって優れていますか?
多分私は誤解していて、これはあらゆる種類のアプリを対象としていますか? あなたが知っている、彼らがuse this tool if
とdon't use this tool if
と言う種類のページは私がそれらをチェックするときに探すものです:)
ああ、わかりました。 Kubyはすべての種類のアプリを対象としていると思いますが、他の種類よりもメリットが得られる種類も確かにあります。 トラフィックをあまり見ず、数百(またはそれ以下)のデータベース行しか管理しない超小型アプリには、無料のHerokudynoを使用する方がよいでしょう。 重要なのは、Kubyがこれらのタイプのアプリに悪い選択であるということではなく、Herokuをセットアップするために費やすお金と頭脳が少なくなる可能性が高いということです。 単純さで彼らを打ち負かすのはかなり難しいです。 ただし、より多くのリソースが必要になると、Herokuは高価になり始めます。一般的に、単一ノードがKubyでデプロイされたマネージドKubernetesクラスターは、同等のHerokuセットアップよりも費用効果が高いことがわかりました。 はい、Kubyは構成するためにより多くの頭脳を必要とします(繰り返しますが、 git push heroku master
を打ち負かすのはかなり難しいです)が、結果として得られる柔軟性は私見の価値があります。
また、Kubyは、Railsの規則から大幅に逸脱した、非常に大規模で高度にカスタマイズされたアプリには適切な選択ではない可能性があります。 Kubyをそのようなアプリで動作させることができると確信していますが、それはおそらくKubyを大幅にカスタマイズすることを意味します。 そのためには、Docker、Kubernetes、Kubyがどのように機能するかをより深く理解する必要があります。 つまり、テクノロジーの学習にどれだけ時間を費やしても構わないと思っているかということです。
おそらく、KubyはRails自体と同じオーディエンスにサービスを提供するように設計されており、アクティブレコード、アクティブストレージなどと同じレベルに存在すると考える必要があります。ORMは非常に小さなアプリであり、大規模な特注のアプリでは邪魔になると合理的に言うかもしれません。 Active Recordは、データベース通信の複雑さを抽象化するように設計されており、Kubyは、デプロイメントでも同じことを行うように設計されています。 DHHが言うのが好きなように、両方ともバッテリーが含まれています。
ありがとう! これのいくつかの形式はおそらくどこかのウェブ上にあるはずです:)
同意しました、これを@hovancikに持ち込んでくれてありがとう:)