クラウドがまだ良い考えだと信じている友人に、この記事を送ってください
(rameerez.com)- AWSから自前サーバーへ移行して月間インフラ費用を10分の1に削減した開発者の体験談で、月1,400ドルから120ドルにまで下げつつ、より高性能なサーバーを確保
- Hetznerのような事業者が提供するベアメタルサーバーは80コアで月190ドル程度で、AWSの同等スペックのインスタンスと比べて7〜18倍安い
- クラウドエンジニアが自前サーバー運用に反対する理由は、雇用の安定性と複雑なインフラへの依存にあり、実際のコスト負担は雇用主が負うため
- ほとんどの小規模ビジネスには、高可用性、マルチゾーン複製、自動フェイルオーバーのようなエンタープライズ級機能は不要で、単一サーバーでも1日数百万リクエストを処理可能
- サーバー管理は初期設定後は安定して維持でき、AIツールの助けによってLinuxサーバー運用の参入障壁は過去最低レベルになっている
クラウドコスト削減の事例
- 最近、すべてのプロジェクトをクラウドから移行し、月間AWS費用を10分の1に削減し、数千ドルを節約することに成功
- 月間AWS料金は約1,400ドルから120ドル未満に減少
- より強力なサーバーインフラを、より安いコストで確保
- パフォーマンスは2倍向上し、ベンダーロックインからも解放された
- このツイートがバズったことで2つの発見があった。多くの開発者が方法に関心を示した一方で、多数がこのアイデアに強い反感と対立的な態度を示した
- ビジネスの観点では、コスト10分の1、性能2倍、ベンダーロックインからの脱却という明白な利益を達成したにもかかわらず、強い反発に直面した
クラウド擁護派の利害関係
- 反対意見を述べた人の大半は、プロフィールに**"devops"、"cloud engineer"、"serverless guy"、"AWS certified"**などのキーワードを持っていた
- 彼らは自分のプロジェクトをクラウドで運用しているわけではなく、クラウド費用を直接負担していない
- 雇用主のAWS請求額に無関心で、毎月数千ドルが浪費される痛みを実感していない
- AWSが彼らにとって便利な理由
- 技術的に複雑に見えるため、他の開発者の前で賢く見せられる
- 依存関係とロックイン効果を生み、従業員として代替しにくくなる
- クラウド利用が高い給与を保証するため、ビジネスにとって効率的な判断をするインセンティブがない
- むしろビジネスインフラが複雑で難解であるほど、自分の仕事は安全になる
- 彼らはサーバーは実際には安いという真実を語らない
安価なサーバーレンタルの選択肢
- Hetznerへ移行（提携なし、ただ安いサーバーを提供しているだけ）
- 80コアのベアメタルサーバーを月190ドル未満でレンタル可能
- AWSのC5〜C6系の同等スペックのインスタンスは月2,500〜3,500ドルで、13〜18倍高い
- リザーブドインスタンスでも月1,300ドル程度で依然として7倍高く、46,000ドルの前払いと3年契約が必要
- VPSの選択肢も魅力的
- 48 vCPUマシンを月300ドルで提供し、セットアップ料金や長期契約なしで完全な柔軟性を確保
- 8コア、32GB RAMのマシンを月50ドルで提供し、1日数百万リクエストでもない限りすべてのプロジェクトを同時に実行できる
サーバー購入とデータセンター活用
- 長期的にはサーバー購入のほうが安い
- 44 CPU、256GB RAM、2TB NVMe SSDを備えたラックマウントサーバーを1,000ドル未満で購入可能
- 月間クラウド費用より安い価格で、アプリを何年も運用できる
- データセンターのラックスペースを借りる選択肢
- 電力、インターネット、冷却、セキュリティを提供するデータセンターのケージまたは共有ラックスペースを借りられる
- DatacenterMapのようなWebサイトで地域のデータセンターを検索可能
- 小規模開発者には複雑すぎる
- エンジニアの採用や価格交渉など、面倒な手続きが必要
- 主に中〜大企業向けで、小規模チームには実用的ではない
- Hetznerのような事業者から、すでにマウント済みのサーバーを借りるのと実質的に同じであり、ハードウェア管理の負担も減る
「それでもクラウドでは？」という批判への反論
- 最もよくある批判は「それでもクラウドでは？」「クラウドを出たのではなく、クラウド事業者を変えただけだ」というもの
- こうした批判は重要な論点を見落としている
- 大事なのは、自前でサーバーを管理することと、クラウドを当然の前提とすることとの価値の差だ
- 小さなLinuxマシンを運用して、RDSのようなコストのかかるマネージドサービスを置き換えれば、10〜100分の1のコストで済む
- ほとんどの開発者はサーバーを恐れており、安価に自前サーバーをセットアップできるという少しの後押しが必要なだけ
- 現実には、クラウドの高価なマネージドサービスを本当に必要としている人はほとんどおらず、数台のLinuxボックスと一般的なソフトウェアで十分だ
- 命名論争は本質をぼかす
- VPSでも、ベアメタルでも、オンプレミスでも、coloでも名前は重要ではない
- サーバーをどこかに置く必要があるのは事実であり、大事なのはより多くのお金を自分のポケットに残したのか、それともAmazonの株主に渡したのかという点だ
- こうした主張をする人たちは本質的に**門番(gatekeeper)**の役割を果たしている
- 「それは正しいやり方ではない。スイッチも自分で買い、ラックも自作し、イーサネットケーブルも自分でつながなければならない」
- 有害で怠惰な議論であり、表面的な細部に執着して中心的な論点を回避している
クラウドコストは本質的に高い
- クラウド擁護派のガスライティング的な試み
- 「クラウドの使い方が間違っている」「高いのはやり方が悪いからだ」「クラウドの使い方を理解すべきだ」
- 彼らは実際に代替案を試したことがなく、自分のプロジェクトのためにサーバーを管理した実体験がない
- 筆者自身はAWSに精通しており、AWS認定資格の勉強もしていた
- インフラが過剰にプロビジョニングされていないか確認
- 使っていないサービスに料金を払っていないか確認
- AWSコスト最適化に数え切れないほどの時間を費やし、月5,000ドル超のAWS請求を半分以下に減らした成功体験もある
- サーバーレスコンピューティングやリザーブドインスタンスなどもすべて理解している
- リザーブドインスタンスは問題を悪化させるだけで、ベンダーロックインを生み、3年契約で自分を縛る
- クラウド離れを検討している状況で3年契約は最悪の選択だ
- あらゆる試行の末に出した結論は、クラウドは単純に高すぎるということだった
反発の原因
- なぜこれほど多くの人がコスト削減に過敏なのか？
- 2つの主な結論
- 生活がかかっている: 自分のような人々が十分な人数を説得してしまうと、仕事を失う可能性がある
- 恐怖による非合理な議論: 過去10年、クラウド構築はトレンドであり、何百万人もの"devops"や"cloud engineers"という職種を生み出した。今度はクラウドを離れることがトレンドになれば、多くのクラウド専門家のキャリアは終わりかねない
- 多くの開発者は、クラウドが当初の約束ほど良いものではないと密かに知っている
- 雇用主のAWS支出が妥当な水準の10倍であるのを見ても、「まあいいか」で済ませてしまう
- 管理者を怒らせたり、責任を負わされたりするリスクを取りたくない
- チームで最も声の大きい人と意見が異なることの政治的コストを恐れている
- AWSには強いカルト的追随がある
- 認定制度を通じて、実質的に販売ページや製品説明を暗記するよう訓練される
- 実用主義ではなく教条主義を唱える**伝道師(evangelists)**がいる
- 外の世界への恐怖を植え付ける（サーバーは危険だ！ スケールしない！）
- 「クラウドエンジニア」というアイデンティティを作り、入りやすくする一方で抜け出しにくくする
- 生活がかかっているため、AWS追随者は教義に縛られ、非合理な議論を繰り返す
- AWSの販売ランディングページにある論点を一つひとつ繰り返し、それが本当に必要かを考えない
- 信念体系をめぐる議論なので、人は非合理になりやすい
クラウドの歴史
- 昔は誰もが自前サーバーを運用していた
- VPS、ホスティングサービス、データセンターのベアメタル、会社の暗い部屋、あるいは自宅で
- 皆、マシンにSSH接続することに慣れ、抵抗がなかった
- 2010年代初頭、クラウドのマーケティングによるサイオプス(psyops)キャンペーンが始まった
- エンタープライズ技術を初期段階のスタートアップに売り込もうとする意図的な動き
- できるだけ早い段階でロックインし、資金調達時に搾り取るための戦略
- AWSの戦略
- スタートアップ向けクレジットの提供を開始
- スタートアップアクセラレーターを回り、あらゆるスタートアップをオンボーディングしようとした
- 仕掛けは単純: スタートアップがインフラを構築する段階では極端に安く（無料で！）し、成長したら一気に高くし、ロックインされてエコシステムから抜け出しにくくなった状況を楽しむ
- IBM Cloudも同様の戦略を取っていた（2014年のイベント）
- 当時はHerokuで全てを運用しており、うまく動いていた
- 「このクラウドって何で、どう使うんだ？」という疑問があった
- 自分たちのために設計されていないものを売りつけられている感覚だった
- こうした企業は過去数年にわたり、数百万ドル規模でクラウド宣伝キャンペーンに投資し、初期スタートアップをエンタープライズ技術の採用へと誘導してきた
- 過去10年のゼロ金利環境も、今の状態に至る一因となった
- 今ではカウンターカルチャー的な動きがある
- 主に@dhhとRailsコミュニティが主導
- 地球上の大半のソフトウェアビジネスの現実と、根本的に新鮮で正しく、整合している
ほとんどのビジネスにクラウドは不要
- 一部の人は、実際のソフトウェアビジネスの姿とかけ離れた認識を持っている
- Fortune 500の視点で考え、エンタープライズが標準だと信じている
- 平均的なビジネスにも高可用性、マルチゾーン複製、自動フェイルオーバー、分散Kubernetesクラスターなど、クラウドの機能一式が必要だと思い込んでいる
- 実際にそうしたものが必要なソフトウェアビジネスはごく少数だ
- ほとんどのビジネスはべき乗則に従い、常に小規模なままだ
- 米国では中小企業が全ビジネスの99.9%を占める
- 欧州連合ではSME（従業員250人未満）が全ビジネスの99%を占める
- ほとんどの開発者はスケーリング要件を過大評価している
- 「高トラフィック」の基準が低すぎる
- 参考までに、現在2台構成で1日数百万リクエストを、月間数百万人の訪問者に対して処理している
- @levelsioのようなインディーメーカーは、すべてを単一サーバーで回している
- ほとんどの開発者は、実ユーザーと本番トラフィックを持つ自分のプロジェクトを単一サーバーで運用した経験がない
- 技術要件も過大評価されている
- こうした機能を本当に必要とするソフトウェアビジネスはごく少数で、通常は技術的判断に十分な理由がある
- Netflixのようなケースでは、世界中の顧客向けに膨大な量の動画をトランスコードし、配信する必要があるため、分散システム、CDN、エッジコンピューティングが必要になる
- ユーザー1,000人の小さなアプリがJSONオブジェクトをやり取りするだけなら、そんなものは絶対に不要だ
- 多くの開発者は、自分のプロジェクトをNetflixのように考える魔法のような発想を持っている
- 希望的観測であり、理解はできるが、誤った技術的判断につながる
- ボタンをタップした際の数ミリ秒の遅延差をユーザーが気づくと思い込み、世界中に分散サーバーが必要だと信じている
サーバーは大丈夫
- 多くの人はデータセンターの動作について魔法のような考え方をしている
- データセンターのサーバーは脆弱で不安定で、空中に消えてしまうかのように思っている
- ひどい場合には、雷が落ちるだけでデータセンター全体が崩壊すると考える人までいる
- 現代のデータセンターはすでにあらゆる問題を想定し、多くの保護策を備えている
- 雷のようなありふれた事象だけでなく、稼働率を脅かしうるほぼすべてに対する保護がある
- 冗長電源、冗長冷却、冗長インターネット接続、冗長消火設備、冗長セキュリティシステムに加え、多くの物理セキュリティ
- データセンター内のあらゆるものは、稼働率を保証するため、回復力と冗長性（最低でもN+1、ときには2N）を前提に設計されている
- これは主に恐怖に基づく意見であり、成功したクラウドのマーケティングとサイオプスキャンペーンの結果だ
- AWSはどこにマシンを置いているのか？ 虹の下の魔法の場所か？
- なぜAWSのマシンだけが、他のデータセンターにもある問題から魔法のように守られているのか？
- 災害が起きる可能性はある（OVHの2021年火災）が、復旧のためにバックアップは必要
- 約15年間サーバーを運用してきた経験では、それは稀であり、数分以上のダウンタイムを経験したことはない
サーバー管理はフルタイムの仕事ではない
- 十分長くサーバーを管理してきた人なら、時間の大半は初期設定に費やされ、その後は比較的安定することを知っている
- ハードウェア障害は比較的稀で、サーバーが立ち上がれば、たいてい何年も大きな介入なしに完全に動作する
- 自前サーバーの管理はフルタイムの仕事ではない
- 5人のdevopsチームを雇う必要はない
- サーバー担当者を雇う必要もない。自分でできるし、そこまで難しくない
- ClaudeやChatGPTはLinuxシステムやその管理方法についてよく理解しており、助けを求められる
- ツイート投稿後、人々はこれが初めてのサーバー運用だと思い込み、サーバー運用の実態について過度に楽観的だと主張した
- 2006年からサーバー管理の経験がある
- PHPスクリプトの編集と、FTPでサーバーにアップロードすることから始まった
- WordPressのインストール方法を学び、WPテンプレートを編集し、それ以降のすべてがそこから続いた
- これは貴重な経験であり、基礎を教えてくれた
- Linuxとは何か、どう操作するかを学んだ
- 2007年にはCanonicalにUbuntuのCD-ROMを請求し、郵送で受け取って親のPCのパーティションにインストールしてLinuxを学んだ
- こうした初期経験がWeb開発の基礎を教えてくれ、他のすべてはその上に築かれた
Linuxを学ぶ重要性
- 新世代の開発者（Z世代、アルファ世代）は、ソフトウェアを動かしているハードウェアから完全に切り離されている
- この種の基礎的な経験が不足している
- YouTubeのどこかの人が特定ベンダーを宣伝し、特定のコマンドを実行すればインフラの問題が魔法のように解決すると教える時代に生まれ育った
- サーバーとは何か、どう動くのかについて、魔法的な前提を持ってしまうのも無理はない
- 「サーバーレス」で仕事ができると主張していても、実際には複数の別の箱でコードを実行していることに気づいていない
- もちろんLinuxやサーバーについてより深く学ぶ人も多いが、平均的なブートキャンプ卒業生には、20年前のFTPハッカーたちが持っていたような実践的Linux経験がない
- これを道徳的に裁くつもりはないし、良し悪しを論じるつもりもない。これは単に現在のWeb開発の状態だ
- その結果、Vercelのような企業は、自分が何をしているのか分からず、生涯一度もサーバーを運用したことのない新世代の開発者を資本化して何百万ドルも稼いでいる
- 無知には二重の代償がある。無知そのものの代償と、その無知を利用する人々に支払う代償だ
- 物事がどう動いているかを知らないことは、実際にお金がかかる
今こそサーバーを学ぶ最良の時期
- 自前サーバーを管理したことがなく、バックエンドっぽいものすべてが怖くても大丈夫
- 実際、サーバーをうまく扱うには今ほど良い時代はなかった
- ClaudeもChatGPTもLinuxに非常に詳しく、技術史上前例のない形でステップごとに案内してくれる
- セットアップ方法や仕組みの理解だけでなく、変更が必要になったときも、誰かを雇わずに質問して手順に従えばいい
- そこまで怖いものではないし、そんなに頻繁にやる必要もない
- コード生成が標準となり、コードがコモディティ化しうるAI時代において、そのコードを安価な本番サーバーにデプロイし、実際にエンドユーザーに役立つものにする方法を知っていることは、開発者としての重要な差別化要因になりうる
- セキュリティのようなものを心配すべきなのは事実
- EC2インスタンスがハッカーから魔法のように守られているかのように、自前サーバー運用はAWSでサーバーを運用するより安全でないという主張は無視してよい
- 実際には、正しく設定することはそこまで難しくなく、ガイドや設定スクリプトを参照すればよい
- 多くの開発者は、AIを活用するあなたより経験があっても、本番環境ではもっとひどい仕事をしている
- ChatGPTにLinuxサーバーのハードニング方法と、セキュリティのベストプラクティス（パスワード認証を使わず、強力なSSHキーだけを使う）を尋ねれば、90%は完了する
- Cloudflareで追加の保護層を提供
- Linuxボックスを堅牢化したあと、その前段にCloudflareを置く
- DNSでサーバーIPをプロキシして露出させなければ完璧
- DDoS保護、エッジキャッシュ、最高クラスのDNSを実質無料で提供
24件のコメント
オンプレミスで必要なインフラを自前で構築するのにかかる時間と労力を考えると、クラウドサービスがそれほど高いとは思えません。
そして、クラウドサービスは高可用性のために使うのであって、コストのために使うものではありません。
IKEA やダイソーみたいな概念だと思います。
とてもコスパがよくて合理的なクラウドサービスもあるはずです。
でもそれを使っていると、今度は少し高く見えるものも一緒に使うことになるんですよね。
（ざっくりした例です）Lambda を使うと今度は API Gateway を使うことになって、これはちょっと高いし不便 -_-^
こういう感じです。
それはさておき、すごく共感したのは。
AWS が彼らにとって便利な理由
技術的に複雑に見えて、他の開発者の前で賢く見せられる
この文章です。
正直、AWS サービスは長く続いて進化してきたぶん、deprecated にすらできなかった機能がいくつもあるのですが、そういうものをよく知っていて使いこなしているのがかっこよく見えて、私も SA を取ったりしていたので（笑）、めちゃくちゃ共感です~~
クラウド、オンプレミス、IDCにはそれぞれ長所と短所があるので、結局は利用目的と規模に合った選択をすることが重要でしょう。
最大の前提が「ハードウェア障害はほとんどない」なんですが……
自分の経験では、会社でIDCにラックを借りてサーバーを運用していたとき、3日に1回くらいの頻度でディスクが死んでいて、
ディスク交換やRAIDの復旧をしに走り回っていた記憶があります……
よほどの事情がなければ、やはりクラウドを使えと言います。
ハードウェアが壊れたときに「カチッ」で立て直せることの価値は本当に大きいので……
3日に1回くらいの頻度でディスクが壊れるのは、ちょっと異常ですね...
一般的なケースではない気がします。
10年以上前の話で、たしか Seagate…だったと思います。
backblaze は昨年 4372 台が故障したと発表しているので、その規模なら 2 時間ごとに 1 台ずつドライブが故障する計算にはなります…
非常に大規模な場合に発生しうる頻度です。
ええと、私は42Uラック100台規模の電算室で、HPC、HCI、初期のHadoopで構成した分散ファイルシステム、ありとあらゆるストレージがある環境でかなり長く勤務していましたが、3日に1回ずつディスクが故障するようなことは見たことがありません。
Hacker Newsの意見
私は何年も 自前でサーバーを運用 してシンプルさを保ち、多くの時間とコストを節約してきた
AWSやAzureは設定が複雑でUIもいまひとつなので避けている
重要なのは、サーバーをいつでも 設定ファイルだけで再構築 できるように管理することだ。だからAnsibleのようなツールが必須になる
どうしてもクラウドを使うならDigitalOceanを勧める。シンプルで直感的なので精神衛生にいい
私はDOを 災害復旧の第3段階 用途でしか使わず、TerraformとAnsibleでクラスターを自動構成している
たいていの開発者コミュニティは流行に流されがちだが、私はそんな空気の中でも物理サーバークラスターにJVMベースのClojureモノリスをデプロイして安定した収益を上げている
ulimitの設定、SYN cookiesの性能問題、セキュリティアップデート、ゼロデイ攻撃 への対応、メール送信（IPウォームアップ、スパムリスト管理）、GDPR準拠などこれらすべてが自分の責任になるので、クラウドを使う人たちが単に「だまされている」わけではない
私は白黒思考が嫌いだ。ほとんどのスタートアップはEC2の代わりにHetzner、Linode、DigitalOceanのようなところへ移ればコストを大きく削減できる
ただしクラウドにも利点は多い — バックアップ、マネージドDB、マルチAZ のような機能を数クリックで使える
初期ハードウェア投資が不要で、ピーク負荷が大きい場合はむしろ安くなることもある
ただ、エンジニアリング時間の価値は大きいので、急成長段階ではクラウドが合理的なこともある
結局クラウドが高いのは、値段そのものというより 不要な機能を使っているから だ
マルチクラウド戦略が災害を防いだ事例も多い
VPSや専用サーバーにも初期費用はほとんどなく、ピーク負荷が極端でなければクラウドが必ずしも安いわけではない
マネージドDBは便利だが 強制アップグレード が多く、大規模でないなら自分で管理したほうがよいと思う
昔はハードウェアの拡張が難しかったが、今では単一サーバーでも昔のラック単位の性能を出せる
中規模プロジェクトは、以前ならクラウドが解決していた問題を今では自前で解決できる
ただし 外部人材の支援 を受けるにはクラウドのほうが圧倒的に容易で、セルフホスティングは支援人材を見つけにくい
私自身はセルフホスティングを好むが、インフラを直接触りたくない人にはクラウドのほうが向いていると思う
以前、ヘッジファンドのスタートアップでITを担当していた
デュアルXeonサーバー（512GB RAM）でC++の分析プログラムを回していたのだが、社長が昼食の席で「なぜAWSを使わないのか」と言われて不安になっていた
「バズワード準拠」 が効率より重要視される現実を見た
多くのCTOはこうした空気のせいで不要に大きな予算を使っており、効率的な構成はむしろマーケティング上の弱点になる世界だ
「10倍節約」という表現は論理的には誤りだ。10倍とはより多いことを意味する
サーバー費用より 保守の人件費 のほうが大きい
EC2インスタンスを10台運用していてもSystems Managerで自動パッチ適用ができるので、自前で自動化を構築する必要はない
クラウド論争は白黒ではない
小規模ならHetznerでもAWSでも大差なく、大企業では自前のツーリングを作れるかが鍵になる
中堅企業（SME） の領域がいちばん曖昧だ。顧客ごとに完全分離されたシステムが必要ならAWSが有利で、24時間365日の一定負荷なら自前サーバーのほうがよい
クラウドをVMホスティング用途にしか使わないなら損だ。クラウド機能を使わずにコストだけ払っている ケースが多い
自前サーバーは1か月ずっと最大容量分のコストを払う必要があるが、クラウドなら必要な数日分だけ払えばよい
クラウドは MVP構築と市場検証 に非常に有用だ
スタートアップ向けクレジットや無料枠で素早く実験でき、その後コストが問題になれば移行すればよい
ただし最初から サーバー非依存のアーキテクチャ で設計しておく必要があり、移行時間を確保するのは難しい
私たちのチームはGoogle Cloudを使っているが、支出が少ないせいで営業担当が不満を持っている
クラウド間を移れる可能性は交渉力として機能する
またクラウドはSLAやデータ保護規制への対応がしやすく、企業顧客の信頼確保 に有利だ
AWSが初期に爆発的に成長した理由が気になる
2010年代初頭はラック賃貸とサーバー構築が高価で遅く、マルチリージョン構成 もほぼ不可能だった
AWSはこうした問題を解決したが、今は状況が変わっている
SquarespaceがハリケーンSandyの際に自ら燃料を運んでサーバーを救った逸話もあった
Hetznerでサーバーを注文してから10分でUbuntuのインストールとAnsible設定を完了できる
固定料金、帯域無制限、予測可能な性能 — 不要な抽象化のないシンプルさ が魅力だ
EC2はそうした不便をなくし、Lambdaはさらに先へ進めた。今では ベアメタルのレンタルがはるかに安い
かつてのAWSの無料クレジット施策は事実上 ロックイン戦略 だった
自分でサーバーをデータセンターに入れるのは思ったほど難しくない
私は ゲームサーバー のために高クロックCPUが必要だったが、クラウドでは入手しづらかったので自前で構築した
設置費込みで月15ポンドほどで運用でき、何年も問題なく動いた。結果として大きなコスト削減になった
シアトルのデータセンターに機材を置き、モデムベースのKVM でリモート管理していた
私たちは数年前に Hetznerへ移行 しており、節約効果が大きかったので再びクラウドへ戻ることはなさそうだ
例外は Cloudflare Workers で、品質が高く無料枠も大きい
AIのおかげで自動化・デプロイ・バックアップ用スクリプトの作成がずっと簡単になり、以前より管理しやすくなった
参考までに、AnthropicのClaude Code はPro/Maxユーザー向けに11月18日まで 250ドル分の無料クレジット を提供している
関連告知は このツイート で確認できる
バックアップからの復旧を一度でも経験すれば、おそらく価値を実感できるのではないでしょうか。オンプレミスはバックアップ復旧がいちばん厄介です。
うーん……「クラウドのコストは必要以上に高い」「多くの場合、大手クラウドの機能は不要だ」という点までは全面的に同意しますが、まるでクラウドサービスは全部詐欺だと主張しているかのような文体が、読んでいて引っかかりますね。「保険商品は全部詐欺だ」と言っているように聞こえます。
クラウドは、サーバーを管理したくないときや、需要の予測が簡単ではないときに、迅速なスケーリングのために使うものですよね。それ以外の用途に意味があるのかは分かりません。
おおむね同意しますが、実際にサーバーを年単位で運用する際のセキュリティ観点についての記述がないのは残念です。
私もこの意見に一票を投じたいですね。
その通りです。
クラウドが高いという点には100パーセント同意します。
とはいえ、今200個を超えるコンテナをベアメタル上で Kubernetes を自前で設定して使わなければならないと考えると、
バックエンド開発者1人、DevOps なしの状況で、1人分の人件費のさらに半分のコストでサーバー管理・運用の負担が減ると考えれば、それなりに悪くない選択なのも事実です。
サーバーインフラ管理"だけ"を担当する人員がいるなら、脱クラウドは確かに良い選択肢になり得るかもしれません。
個人的に、できるだけクラウドを排除してサービスを構築しようとしてみたら、本当に気が狂いそうでした。
コンテナイメージのレジストリが必要だったのですが、構築しようとするとローカルストレージは負担が大きく、バックアップのしやすさのためにS3互換を調べ、外部アクセスを遮断するためにVPNサービスも立て、リバースプロキシのHTTPS証明書管理に、CI/CDのセキュリティのための各種設定まで……自前構築……
クラウドで単純なサービスをいくつか使うだけなら、当然ベアメタルのほうが安いですし、そうするのが正しいのでしょう。ただ、ほかのサービスとの連携が必要で、あれこれの負担を減らしたいなら、今この瞬間のサーバー費用が高くても、そうしたサービスを一つひとついちいち構築する必要がないという点で、導入・運用コストが省けるぶん、結果的に得になることもある気がします。
イメージストレージのオープンソースは数多くあります。
ありますね。直接運用しなければならない負担のことを言っていました。私も Nexus や Harbor を使っています。
個人的な経験では負担や問題はありませんでした。
負担の基準は人それぞれ違うので、そのように感じることもあるのでしょう。
どのようなサービスを開発するために、コンテナイメージレジストリが必要なのですか？
どのようなサービスを開発するとしても、コンテナデプロイを好むからです。デプロイもできるだけ SSH の直接接続なしで行うほうを好みますしね。コストだけを考えるなら……レジストリなしで直接デプロイできる方法もあるとは思いますが、あくまで例として考えてみたもので、メールサービスのようなものなど、少し不便な部分が生じることに焦点を当てたいです。