アカウント名:
パスワード:
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。 例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。 で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方がAWSとか使うより安くなるような気がするけど、どうでしょうね。（構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら）
「サーバーが年間通して常に26台でOK」みたいに、スケールする必用がないならクラウドのメリットも半減するからな。
「学習するときは百万台単位で必用だけど、それが終わったら不要になる。」という負荷の変動が激しい分野なら、学習するときだけ時間貸しした方が安くなるだろう。
変動が少ないし、事業も安定している企業ならメリットも少ない。＃そんなことは百も承知で利用してたんじゃないの？
一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。企業の常用研究用だと、常になんかしらぶん回すから結局占有プランの方の割引率に時間貸しプランが負ける。そして、借りるぐらいなら自前で持った方が格段に安い。1年以内にで元が取れるので比較の俎上にすら上がらん。
おかげで弊社は毎年EPYCの研究開発用サーバーが増えてってる。(EPYCの前はXeonだったけど、Zen2以降のEPYCはコスパとワッパが段違い)
＞一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。反例をもう一つ挙げておこう。基幹システムでもなんでも、開発環境やテスト環境はIaaSで必要な時に必要なリソースで使うことでメリット出ます。
それは結局TCOで見ると本番環境のクラウド化に伴うコスト増でつぶれると思うよ。いや本番を社内サーバで開発だけクラウドという手もあるが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
スケールメリットだよね (スコア:1)
管理対象がある限界を越えれば自前で設備を整えて、スタッフを抱えた方が安くなることって一般的な気がする。
例えば、運送会社で小規模なところは整備工場を持ってないけど、昔の日通みたいに大規模なところだと整備工場を持っていて、壊れたトラックから部品を集めてトラックの再生までしていたと聞いたことがある。
で、クラウドといえばガバメントクラウドが、これから本格化するけど、政府や自治体のシステムを集約して載せるならデータセンターを何ヶ所か建設した方がAWSとか使うより安くなるような気がするけど、どうでしょうね。
（構築・運用のノウハウやスキルをもった人材がいない、とか言われるのかしら）
スケールの必要がないなら (スコア:3, すばらしい洞察)
「サーバーが年間通して常に26台でOK」みたいに、スケールする必用がないなら
クラウドのメリットも半減するからな。
「学習するときは百万台単位で必用だけど、それが終わったら不要になる。」
という負荷の変動が激しい分野なら、学習するときだけ時間貸しした
方が安くなるだろう。
変動が少ないし、事業も安定している企業ならメリットも少ない。
＃そんなことは百も承知で利用してたんじゃないの？
Re: (スコア:1)
一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。
企業の常用研究用だと、常になんかしらぶん回すから結局占有プランの方の割引率に時間貸しプランが負ける。
そして、借りるぐらいなら自前で持った方が格段に安い。1年以内にで元が取れるので比較の俎上にすら上がらん。
おかげで弊社は毎年EPYCの研究開発用サーバーが増えてってる。(EPYCの前はXeonだったけど、Zen2以降のEPYCはコスパとワッパが段違い)
Re:スケールの必要がないなら (スコア:0)
＞一時的な拡大縮小が効果的に効く分野はゲーム屋とチケット屋しか結局無かったのよ。
反例をもう一つ挙げておこう。
基幹システムでもなんでも、開発環境やテスト環境はIaaSで必要な時に必要なリソースで使うことでメリット出ます。
Re: (スコア:0)
それは結局TCOで見ると本番環境のクラウド化に伴うコスト増でつぶれると思うよ。
いや本番を社内サーバで開発だけクラウドという手もあるが。