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

 (theolognion.com)
1 ポイント 投稿者 GN⁺ 2024-03-02 | 1件のコメント | WhatsAppで共有

Kubernetesへの11週間の移行後、会社は存在理由を忘れてしまう

  • シリコンバレーの新興スタートアップ Xenobroom Inc. は、2020年5月にサーバーインフラのアップグレード作業を開始。

  • 世界的なパンデミックの中で日次利用量が急増したため、既存インフラをKubernetesへ移行することを決定。

  • 単純なbashスクリプトとVPSマシンを見直して再設計するのに、予想以上の時間がかかる。

  • 会社は、ソフトウェア依存関係とライブラリをアップグレードする良い機会だと捉える。

  • 単一マシンで稼働していたPostgreSQLデータベースの大部分を、AWSの柔軟性を活用した分散KVストレージへ変換。

  • develop ブランチで日次デプロイを行う一般的なステージングサーバーを、CI対応の本番専用ワークフローに置き換え。

  • 移行作業が完了したとき、社内の誰も製品の目的を思い出せなくなっていた。

  • ユーザーと投資家の双方とも元の製品を理解しておらず、数週間のダウンタイムの後では製品の意味を復元することは事実上不可能。

  • CEOは、Googleのメッセージングアプリ市場シェア拡大を助けたことで知られる霊能者 Phutar Afrayughum の助けを求める。

GN⁺の意見

  • この記事は、Kubernetesへのマイグレーション過程が企業に与える影響を風刺的に扱っている。現実でも技術移行は企業運営に大きな変化をもたらし、ときには本来の目標を見失うことがある。
  • 技術移行を検討する際には、技術的な側面だけでなく、組織のビジョンと目標についての明確な理解が必要。これは、技術が組織の目的を支えるべきだという原則を強調している。
  • Kubernetesは多くの企業で好まれるコンテナオーケストレーションプラットフォームだが、導入前には十分な準備と専門知識が必要。そうでなければ、複雑さと運用負荷が増す可能性がある。
  • この記事は、技術導入が常に肯定的な結果だけをもたらすわけではないことを思い出させてくれる。ときには技術が組織の本質的な価値と目標を曖昧にしてしまうことがあると警告している。
  • Kubernetesと類似した機能を提供する他のプラットフォームとしては、Docker Swarm、Apache Mesos などがあり、状況によってはKubernetesの代替となりうる。

関連記事

1件のコメント

 
GN⁺ 2024-03-02
Hacker Newsの意見

  • 中間管理職を20%解雇したことで開発生産性が3倍向上した事例

    ある会社では、中間管理職を20%解雇したことで、偶然にも開発生産性が3倍向上した事例があった。

  • Kubernetesへのマイグレーション経験の共有

    現在進行中のKubernetesへのマイグレーションは2年が過ぎても30%も完了しておらず、当初Kubernetesを強く推していた人たちが今ではLLMsに関心を移していることが指摘されている。新しくてきらびやかなものを好む人たちがいて、そうした役割自体は有用であり得ることも示唆している。

  • Theolognionブログの面白い記事群

    Theolognionブログにはいくつもの面白い記事があり、特に「完璧なノート集約システムを開発した開発者」と「Hacker Newsコメントを分析したAIがあらゆる政治・経済・医療問題を解決する」という記事が面白い。

  • 失敗の原因に関するジョーク

    失敗の原因を分析するポストモーテム(post-mortem)では、その会社がこれをソフトウェア依存関係やライブラリをアップグレードする絶好の機会と見なし、単一マシンで動いていたPostgreSQLデータベースのかなりの部分を、AWSの柔軟性を活用して分散KVストレージへ変換できたはずだ、という仮定が出てくる。

  • Kubernetesへの11週間マイグレーション成功事例

    実際、11週間でKubernetesへマイグレーションしたのであれば、それは大きな成功として認められるべきことだ。

  • Kubernetesへのサービスマイグレーションのコツ

    複雑な技術はまず学び、重要ではない小さなサービスから試すべきだ。一度に一つのことを行い、シンプルに始めるべきだ。筆者はKubernetesへサービスをマイグレーションする際に特に問題はなかったが、それは2年間の学習と試行、そしてインターネットでは見つからない最適なアプローチにたどり着くまで複数の方法を試した結果だった。筆者はgitopsを自動化なしで使い、必要なものを kubectl apply -k で適用している。今では数十のサービスと十分な理解があるため、fluxの導入を検討している。

  • システム運用の容易さと低コスト化

    システムを運用することはこれまでになく簡単かつ安価になったが、エンジニアはしばしば単純な作業を行うために複雑で非効率な方法を選ぶ傾向がある。

  • 技術選定に関する業界の問題点

    GraphQL/React/Nextのような技術を導入して、完全に機能しているアプリケーションをマイグレーションすることについて、この業界で長く働いてきた者として、多くの人が自分で何をしているのか分かっていないという印象を受ける。

  • クラウドストレージへのマイグレーション経験

    自前でホスティングしたMinIOから管理されたblobストレージへ500,000個のblobを移行するために4か月間昼夜を問わず格闘したが、実際に生産的だった作業は政治や官僚主義と無関係な1週間未満だけだったので、11週間でKubernetesへマイグレーションするのは大成功に見える。

  • 1970年代の法律事務所におけるコンピュータ導入体験談

    1977年に若い弁護士として働き、時間課金制で請求していた経験と、1979年にTandy Iコンピュータを購入してFoxbaseのようなデータベースプログラムを使った経験が共有されている。1981年に自分の法律事務所を開業した当時、FAX機と電動タイプライターは事務所の生産性を高める最新技術だったが、パーソナルコンピュータは使っていなかった。筆者はすべての秘書にCompaqコンピュータを購入し、手作業だった請求システムを置き換える時間・請求プログラムを書くことに多くの時間を費やし、ネットワークも構築した。しかしこうした技術に集中するあまり、弁護士としての業務やビジネス顧客との関係維持をおろそかにし、最終的に1994年に事務所を閉鎖した。当時はどの事務所もワードプロセッシングのためにコンピュータを使っていたが、市販の請求プログラムは存在せず、他の法律事務所の弁護士たちは筆者の請求プログラムを欲しがっていたにもかかわらず、筆者はプログラミングを楽しむことに集中してしまい、事業を潰した経験を語っている。