11週間のKubernetes移行後、会社は存在理由を忘れる（2020）

 (theolognion.com)
1 ポイント 投稿者 GN⁺ 2024-03-02 | 1件のコメント | WhatsAppで共有
  • シリコンバレーのスタートアップ Xenobroom Inc. は、2020年5月、パンデミック中に日次利用量が急増したことを受け、既存のサーバーインフラを Kubernetes に移行することにした
  • 移行は単なるデプロイ改善にとどまらず、bashスクリプト とVPSベースの構成を見直し、再設計する長期作業へと膨らんだ
  • 依存関係やライブラリのアップグレード、PostgreSQLの一部の 分散KVストレージ への移行、AWSの柔軟性活用まで同時に進められ、スコープは拡大し続けた
  • 既存のstagingサーバーとdevelopブランチベースの日次デプロイは、production-only CI ワークフロー、動的ルーティング、A/Bテスト、地域依存性サポートに置き換えられた
  • 移行が完了したように見えた時点で、メンバーの誰も プロダクトの目的 を覚えておらず、ユーザーと投資家も元のプロダクトを理解していなかったと認めたため、復元は事実上困難になった

Kubernetes移行で膨らんだ作業範囲

  • Xenobroom Inc. は2020年5月、サーバーインフラのアップグレードを開始した
    • CEOの日誌の断片とCTOのエンジニアリングノートによると、パンデミック中に日次利用量が急激に増えた
    • その後、既存インフラを Kubernetes に移行することを決定した
  • 作業は予想より長引いた
    • 単純な bashスクリプト とVPSマシンを作り直し、見直し、再エンジニアリングする必要があった
    • 社内では、この機会にソフトウェアの依存関係とライブラリもアップグレードできると考えられた
  • インフラ変更は、より大きな構造改革につながった
    • 単一マシンで動いていた PostgreSQL データベースの大部分を、分散KVストレージに置き換えられると判断した
    • AWSの柔軟性を活用するという名目も加わった
    • developブランチから毎日デプロイしていた単純なstagingサーバーはなくなった
    • 代わりに、動的ルーティングを備えた production-only CI ワークフローが導入され、A/Bテストと地域依存性をシームレスにサポートする構成になった

プロダクト目的の喪失と外部の助け

  • 移行手順が完了したように見えたとき、社内では誰も プロダクトの目的 を覚えていなかった
  • ユーザーと投資家も状況を解決できなかった
    • 両者とも、そもそもプロダクトをきちんと理解したことがなかったと公に認めた
    • 数週間のダウンタイムの後、プロダクトの意味を復元することは事実上不可能になった
  • CEOは Phutar Afrayughum という霊能者であり超感覚的知覚の専門家に助けを求めた
    • 彼はGoogleのメッセージングアプリ市場シェア拡大を支援し、Material Designフレームワークの開発にも関与した人物として紹介されている
    • ただし、この助けは「allegedly」とされており、事実として断定されてはいない

関連記事

1件のコメント

 
GN⁺ 2024-03-02
Hacker Newsのコメント

  • この記事のほうがもっと笑える: 中間管理職の20%を解雇したら、開発生産性が偶然3倍になったという内容
    https://www.theolognion.com/p/company-accidentally-increased...

    • これは風刺と見るのも難しい

  • うちの$dayjobでもこういう移行作業を進めていて、2年前に始めたのに、まだ30%も終わっていない
    以前は「Kubernetesへ行くべきだ、モノリスを殺すべきだ」と一番大声で叫んでいた人たちが、今ではLLMをいじるのに夢中でKubernetesのことは忘れている
    ある種の人たちは概念実証やピカピカの新しいものが本当に好きで、その役割もそれなりに役には立つようだ

    • 新しくてピカピカした技術で職務満足を得る構造になっている
      だから賢い人たちが、非倫理的な巨大テック企業、広告会社、監視企業でもかなり満足して働いているように見える
      会社がなぜ存在するのか、自分のコンピューターの外で実際に何をしているのかはあまり重要ではなく、技術と新しいものを追求する自由が重要なのだ
      会社は彼らが生み出す生産性と情熱を好み、報酬もよく払う
      たいていこういう開発者にも良心はあるが、その良心は企業に都合のよい善良な社会運動の形に吸収され、展示されることが多い
    • これはスコープ拡大というより、意図的な履歴書駆動開発に近い
      誰かが「Xをやったことがある」と言うために、チェックボックスを一つずつ消しているのだ
      小さなチームでは、こうしたやり方が生産性を本当に素早く止めてしまうことがあり、よく「すべての問題を解決したい」という欲求で包装される
      しかしその結果、何の問題も解決されず、むしろ新しい問題がさらに増える
    • FAANG周辺の会社では昇進が非常に難しく、レベル制度のせいで給与を上げる方法も昇進しかない場合が多い
      昇進には昇進パッケージが必要で、昇進パッケージには大きく重いプロジェクトが必要だ
      結局、解決しようとする中核問題が事業上の必要ではなく昇進になり、問題を探す巨大プロジェクトが生まれる
    • 会社の金を燃やす役には立つかもしれない
      説明されているものは概念実証ですらなさそうだ。概念実証の基本条件は、とにかく動くことだが、これは群れについていき、忙しそうに見せるための構成を作り出すほうに近い
      従業員の立場でも、長く留まるのに良い環境ではなさそうだ
    • そういう人たちのほうが、むしろ一番昇進する人たちなのだと思う。本当にひねくれた構造だ

  • そのブログにはもっと笑える記事も多い。特にこれが気に入った:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    それからこれもある:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • 冗談なのは分かっているが、ポストモーテムをするなら失敗原因はおそらく「社内の多くの人が、この機会にソフトウェア依存関係とライブラリのアップグレードも一緒にやろうと考えた。単一マシンで動いていたPostgreSQLデータベースの大部分も、AWSの途方もない柔軟性を活用して分散キー・バリューストアに置き換えられると見た」になると思う
    スコープを守るべきだ

    • それこそがこの冗談の核心に近い
      世の中には、自分たちが作るプロダクトより、使う技術にばかり集中する人が多い
      プロダクトに集中するというのは、スコープを理解し、早すぎる過剰設計をしないという意味だ
      冗談はKubernetesに焦点を当てているが、サーバーサイドレンダリング、AI、$modernFrontendLib、$modernLanguageでも同じように作れる
    • 会社のスコープも守るべきだ
      事業がクラウドインフラ販売でないなら、既製のクラウドプロバイダーを使えばいい
      すでにクラウドプロバイダーにお金を払っているなら、特にKubernetesは使わないほうがいい

  • 現実では、11週間のKubernetes移行なら大成功と認められていただろう

    • 実際には11か月かかり、今や「クラウドネイティブ」みたいな状態になっていただろう
      もちろんデータベース運用は少し大変だったはずだ。Kubernetesのストレージ設定をきちんとしておくのを忘れて、Podが突然移動した後にデータが消えただろうから
    • すでにDockerを使っているなら、そんなに長くかかる理由はほとんどない
      Dockerすら使っていなかったなら、似たような移行作業での問題はKubernetes自体ではない可能性が高い

  • システムを運用するのが、今ほど簡単で安価だったことはない
    それなのにエンジニアは、ピザ1枚を配達するために遠征隊を組み、エベレストに登り、山頂でピザの写真を撮ってから、再び飛行機で家に持ち帰り、Lamborghiniを借りてモンゴル・ラリーを走った後、18か月後になってようやくそのピザを配達しようとするほうを好む
    その間、ただ安いスクーターに乗って道を下っていけば勝てる

    • エンジニアが注入した複雑さが、経営陣が注入した複雑さに匹敵するような場所で働いたことはない

  • 複雑な技術なら、まず学ぶべきだ。小さくて重要でないサービスで先に試すべきだ
    一度に一つだけ行い、シンプルに始めるべきだ
    私は自分たちのサービスを問題なくKubernetesへ移行したが、小さなサービスを移しながら学び、実験するのに2年かかった
    複数のアプローチを試した後で最適な方法にたどり着いたが、インターネットですぐ見つかるような方法ではなかった
    GitOpsは使うが自動化はせず、必要なものに対してただkubectl apply -kを実行する。当時はfluxが、始めるには不要に複雑だと判断したためだ
    今ではサービスが数十個になり、理解も深まったので、fluxの導入を考えている

  • 1977年に、時間単位で請求する法律事務所で若い法廷弁護士として働いていた。
    案件ごとに何をしたかを紙に記録し、事務スタッフが記入済みの紙から切り取れる帯を切って、各案件の紙フォルダー内側のボードに貼っていた。
    1979年にRadioShack Tandy Iを買い、ほどなく自宅でDOSベースのデータベースプログラムであるFoxbaseに深くのめり込んだ。後にFoxProとなり、1990年代初頭にMicrosoftに買収された。
    1981年に自分の法律事務所を開いた。当時、事務生産性における最新の革新は、FAXと、1行表示の画面、メモリ、フォーム保存用の小さなディスクを備えた電動タイプライターだった。企業はまだパーソナルコンピューターを使っていなかった。
    私の法律事務所はすぐに弁護士約10人、サポートスタッフ12人ほどの規模になり、すべての秘書にCompaqコンピューターを買い与えた。
    手作業で帯を貼る方式に代わる時間・請求プログラムを書くのに多くの時間を費やし、ネットワークの設置方法も学んで自分で設置した。
    私が知っていた他の法律事務所にはコンピューターが1台もなかったが、私たちはサポートスタッフ用に10台以上、顧客に送る前に請求書を確認する弁護士用に「ポータブル」なCompaqを4〜5台備えていた。
    その一方で、私は事業を台無しにしていた。他の人たちがコンピューターを1台も持っていなかった時代に世界最高水準の技術を持っていたのに、弁護士業務や法人顧客の営業に集中せず、ドアを閉めてプログラミングばかりしていた。
    結局、1994年に法律事務所を閉じた。
    それでも刺激的な時期だった。まもなくすべての法律事務所がワープロ用のコンピューターを備えるようになったが、商用の請求プログラムはまだなかった。
    約24か月のあいだ、一緒に仕事をした他の法律事務所の弁護士は皆、私の請求プログラムを欲しがった。
    しかし私は案件対応に追われながらも、楽しいプログラミングにばかり没頭していた。自分の法律業務はそのプログラムにとって完璧な実験場だった。残念ながら、そのプログラミングが私の事業を台無しにした。

    • その切り取る帯の方式は本当に興味深い。当時の時間追跡では一般的な方式だったのか気になる。
      もし写真が残っているなら見てみたい。

  • 私の分野では「Kubernetes」をGraphQL/React/Nextに置き換えても、そのまま当てはまる。
    もちろん、完全に問題なく動作しているアプリ、それも大半がCRUDのアプリを移行するための作業だ。
    GraphQLやインタラクティブなフロントエンドがもたらすトレードオフなどまったく必要ないのに、それをやる。
    この業界に長くいるほど、責任ある立場にいる人たちが自分たちのしていることを分かっていないケースをますます多く目にする。

    • 人は、動き続けるように保守する仕事では報われない。
      変化に対して報われるのであり、その変化が成果を出している、あるいはいずれ出すように少なくとも見せかけられればよい。

  • 自社ホスティングのMinIOからマネージドなBlobストレージへ50万個のBlobを移そうとして、4か月間昼夜を問わず格闘しているが、政治や官僚主義ではない実際に生産的な作業は1週間にも満たない。
    だから11週間のKubernetes移行なら大成功に聞こえる。