Figmaが12か月以内にK8sへ移行した方法
(figma.com)- Figmaは、すでにコンテナ化されていた中核サービスをECSからEKSベースのKubernetesへ移し、ダウンタイムなしで長期的なプラットフォームの限界を減らす移行を目標にした
- ECSではStatefulSets不在、Helm chartベースのOSS運用の難しさ、ノード分離の制約が大きく、KubernetesはCNCFエコシステムとKeda・Karpenter・Istioのような選択肢を開いた
- マイグレーションは、サービスの実行・デプロイ・ツールの抽象化は維持し、オーケストレーションだけを変える形で範囲を絞り、Bazelベースのサービス定義と3つのEKSクラスター構成を初期スコープに含めた
- 移行過程では、負荷テスト、Weighted DNSベースの段階的なトラフィック移行、実サービスの早期移行、生YAMLの隠蔽、サービスオーナーとの協業によってロールバック可能性を確保した
- 2024年1月までに最優先サービスの大半がEKSへ移行され、過剰プロビジョニングのコスト削減・信頼性向上・開発者体験の改善を得た後、ロギング・自動スケーリング・Graviton移行を継続している
ECSからKubernetesへ移行した理由
- Figmaは2023年初頭の時点で、すでにすべてのサービスをコンテナで実行しており、オーケストレーションプラットフォームとしてAWS Elastic Container Service（ECS）を使っていた
- 次世代コンピュートプラットフォームを検討する中で、ECSの上に積み増していくやり方では、長期的に必要な機能を作るのが難しいと判断した
- Figmaは何千ものマイクロサービスを運用する会社ではなかったため、Kubernetes移行の範囲を現実的に管理できた
- 分離や性能上の理由で新しいサービスが必要になることはあるが、中核サービスが基本的なモジュール化とトラフィック分離を提供していた
- 新製品でも、新しいサービスを作るより、既存の中核サービス内にロジックを追加して対応するケースが多かった
ECSで不足していた機能
- ECSはKubernetesのStatefulSetsをサポートしておらず、etcdのような強整合な合意型データストアの運用が難しかった
- Figmaは、etcdコンテナの起動時にクラスターのメンバーシップを動的に更新するカスタムコードで回避していた
- この方式は脆く保守しにくく、KubernetesではStatefulSetsのステートフルなネットワーク割り当てを使うのが一般的だった
- ECSでは、Helm chartsで定義されたサービス群を実行しづらかった
- ECS on EC2では、問題のある単一のEC2マシンを安全に停止する作業も煩雑だった
- EKSでは、不調なノードをcordonすれば、APIサーバーが終了手順を尊重しながらPodを別のマシンへ移せる
CNCFエコシステムとプラットフォーム選択
- ECSを使い続けると、**Cloud Native Computing Foundation（CNCF）**エコシステムのオープンソース技術を活用しにくかった
- 自動スケーリングは、次世代コンピュートプラットフォームにおける重要な関心事だった
- サービスメッシュも、長期的には必要になる可能性があった
- 既存のサービス間トラフィックは、AWS Application Load Balancers（ALB）とNetwork Load Balancers（NLB）を通じてルーティングされていた
- NLBは、新しいターゲットの登録や既存ターゲットの削除に数分かかり、緊急デプロイの速度を落とし、インシデント時の平均復旧時間を延ばしていた
- Envoyは、より高いカスタマイズ性とカスタムフィルター実行を提供する
- Figmaはすでに主要サービスの前段に独立したEnvoyマシンクラスターをプロキシとして置き、障害時に負荷を下げるカスタムフィルターを使ったことがあった
- EKSではIstioのようなオープンソースの選択肢が多い一方、ECSでは同様の機能を自前で作り直す必要があった
人気プラットフォームがもたらす運用上の利点
- Figmaは、どのサービスやソフトウェアにおいても最大ユーザーにならないようにしている
- 最大ユーザーは、粗さやスケール限界に最初にぶつかりやすい
- Kubernetesは多くの大企業が巨大なコンピュートプラットフォームで利用しており、Figmaはそれよりはるかに小さいユーザーに属する
- Kubernetesはベンダーロックインの軽減にも役立つ
- EKSは、ベンダーがサポートするコントロールプレーンの利点を提供する
- サービスは汎用的なKubernetes上で動くように書かれるため、他ベンダーのKubernetesプラットフォームや自社ホスティング環境へ移る負担は大きくない
- Kubernetes経験のあるエンジニアを採用しやすい
- 既存経験を持つエンジニアが素早く適応でき、Figmaにとって新しい意思決定になりうる領域へ文脈を持ち込める
マイグレーションのスコープを定める原則
- 大規模なマイグレーションでは、置き換えたい中核システムだけを差し替え、プラットフォーム利用者に見える抽象化は可能な限り維持するのが安全だ
- Figmaは、ECSの代わりにEKSで動くように移行しつつも、サービスの実行方法・デプロイ方法・サービス間相互作用のツールは変えない方向にスコープを絞った
- 機能変更のように見えない作業でも二次効果を生みうるため、大規模マイグレーションのスケジュールは簡単に膨らみうる
- 例外は2つあった
- 新システムを旧システムのように振る舞わせるために過度な追加作業が必要な場合は、二次効果を受け入れて新方式を採用できる
- 後から変えにくい、またはコストの高いone-way doorの意思決定は、最初から新方式を適用できる
スコープに含めた改善
-
開発者体験
- 従来のECSサービス定義は主にTerraformで生成・変更していた
- Terraformの適用によってインスタンス数0のECS task setテンプレートを作り、その後デプロイ過程でテンプレートを複製してイメージハッシュを差し替え、インスタンス数が0ではないtask setをECSにデプロイしていた
- 環境変数を1つ追加するだけでも、Terraformの記述・適用後にデプロイを実行する必要があり、順番を守らないとコード内で環境変数を安全に使えずバグが発生した
- EKSでは、サービス定義を1か所にまとめ、変更を1段階でデプロイするようにした
- Figmaは、Bazel設定ファイルでサービスを定義するシンプルな社内方式を作り、サービス定義のYAMLやIngressなどの設定YAMLを自動生成した
- YAMLはコードコミット時にCIツールで生成され、社内デプロイシステムを通じて適用される
-
信頼性
- 各サービスについて、3つのEKSクラスターがPodを実行し、トラフィックを受けるよう構成した
- すべての運用がクラスター単位で行われるなら、全面障害の影響をサービスの3分の1に抑えられる
- リトライ要求や非同期処理が可能なサービスでは、ユーザー影響を最小化できる場合が多い
- この構成は、デプロイパイプラインなどの運用複雑性を大きく高めたが、後から追加するより移行時点で導入する価値があると判断した
-
コスト効率
- 複雑なコスト最適化作業はマイグレーションのスコープにあまり入れなかったが、ノード自動スケーリングは最初からサポートした
- ECS on EC2のサービスでは、デプロイ中の急増に対応するためにマシンを過剰プロビジョニングしていた
- EKSでは、Karpenterを使って需要に応じてノードを動的に拡張・縮小する
スコープから除外した作業
- 既存のロギングパイプラインは複雑だった
- すべてのログをまずCloudWatchに記録する
- Lambdaがログを読み、特定パターンの削除やタグ追加などの変換を行う
- その後、DatadogとSnowflakeへ記録する
- 中間ストレージであるCloudWatchのコストが大きくなっていた
- Figmaは、EKSスタックでサイドカーとしてログを処理・転送できるCNCFプロジェクトVectorの導入を計画している
- しかし、ログフォワーダーのロジックをVector設定へ移植する二次効果を受け入れる価値はないと判断し、マイグレーションのスコープから外した
- Podレベルの自動スケーリングもマイグレーションには含めなかった
- 複雑性が高すぎると判断した
- 後から容易に追加できる作業と見なしていた
- 除外した作業はその後のフォローアップとなり、他サービスのEKS移行と並行して改善を提供できた
安全な実行方法
- 既存のECSスタックが比較的安定していたため、新しいEKSスタックと移行プロセスも少なくとも同程度には信頼できる必要があった
-
負荷テスト
- Figmaは「Hello, World」サービスを作り、Figma最大のサービスと同じ数のPodが動くまでスケールさせた
- このテストにより、プラットフォーム全体を支える中核コンピュートサービス群のサイズとスケールを調整する必要があると分かった
- Kyvernoはクラスターのセキュリティ検証ツールであり、十分に大きく構成されていないと新しいPodの起動を遅らせることがあった
-
段階的ロールアウト
- Weighted DNSエントリを使って、既存のECSサービスからEKS対応サービスへトラフィックを少しずつ移した
- 細かなトラフィック切り替えと差し戻し制御が、安全なマイグレーションの鍵だった
- 想定外の影響は未知の転換点で起こりうるため、影響範囲を小さくし、すばやくロールバックできる必要があった
-
実サービスの早期実行
- 実際のワークロードをシステムに載せると、ステージングだけでは分からない多くのことを学べる
- Figmaは、ステージング環境の構築を完了する前に、1つのサービスを先に移行した
- この早期移行は、ワークロード実行能力をエンドツーエンドで検証し、ボトルネックやバグを見つけるのに役立った
-
YAMLの抽象化
- 利用者に生のKubernetes YAMLで直接サービスを定義させると混乱を招く可能性がある
- Figmaは、利用者にgolden pathを提供し、特別な場合にのみカスタマイズできるようにした
- 利用者が何をどこまでカスタマイズでき、何をすべきかを明確にしつつ、基本的な一貫性を強制することで、保守や将来変更を簡素化した
-
サービスオーナーとの協業と人員配置
- 新しいサービス設定はプラットフォームチームが担当し、監視とアラートの更新はサービス状態を最もよく知るサービスオーナーと密接に協業した
- マイグレーション開始前から、サービスオーナーと選択肢やトレードオフを十分に議論した
- 大規模マイグレーションは、予期しない問題、複雑な相互作用、一般的なバグを生みうるため、深い技術的専門性とデバッグ能力を持つチームが必要だった
実際のマイグレーション日程と結果
- 2023年第1四半期に計画を作成し、マイグレーション実施の合意を得た
- 2023年第2四半期にはステージング環境を構築し、単一サービスを移行した
- 2023年第3四半期には本番化、負荷テスト、追加サービス移行の準備に集中した
- 2023年第4四半期から2024年1月第1週まで、サービストラフィックをゆっくり切り替えた
- 2024年1月までに、最優先サービスの大半を新しいEKSクラスターへ移行した
- 中核ビジネスロジックを担うモノリス
- Figmaファイル編集のマルチプレイヤー面を処理する複雑なサービス
- すべてのクライアントへリアルタイム更新をプッシュするLivegraph 100x構成サービス群
- その結果、デプロイのための過剰プロビジョニングコストを削減し、3クラスター稼働で信頼性を高め、開発者の使い勝手も改善した
- 全体として作業は、小規模なインシデントと低い顧客影響の中で進んだ
- ある運用担当者が、本番クラスターの1つでCoreDNSを破壊して再作成してしまう事故があった
- 以前の構成であれば全面障害になっていた状況だった
- 3クラスター構成では、影響はリクエストの3分の1に限定された
- 多くのダウンストリームサービスがリクエストをリトライし、最終的に成功した
リリース後のツール改善
- Figmaは、サービスオーナーがクラスター内で起きていることをデバッグできるようツールを構築した
- 実行中インスタンス数の確認
- コンテナシェルへの接続
- 緊急スケーリングのような運用作業の実行
- リリース直後、このアクセス用ツールは十分にユーザーフレンドリーではないというフィードバックを受けた
- 複雑さの原因は2つあった
- 3クラスター導入により、利用者は複数クラスターにまたがってコマンドを実行し、各コマンドにクラスター名を追加する必要があった
- Kubernetes RBACロールを活用してより細かい権限を提供したことで、利用者は自分にどのロールがあり、特定作業にどのロールが必要かを理解しなければならなかった
- Figmaは他の作業をただちに止め、ツールが適切なクラスターとロールを自動推論するよう修正した
- 利用者は、特に深夜の緊急時にロールを探すための時間を無駄にせずに済むようになった
次のステップ
- 残るサービス移行を続けつつ、新しいコンピュートプラットフォームの改善を並行して進めている
- 現在の重点領域は次のとおり
- ロギングパイプライン設計の簡素化
- Kedaによる水平Podオートスケーリングのサポート
- Figmaで最もコストの高いサービスをGravitonプロセッサへ移行してコストを削減し、今後ほかのサービスもGravitonで動かす道筋を整える
- まだ深く投資できていない領域も探索する予定だ
- サービスメッシュの提供を調べ、ネットワークスタックの信頼性と可観測性を改善する
- AWS Controllers for Kubernetes（ACKs）でより多くのリソースを管理し、Terraform依存を減らしてスタックを簡素化・統合する
- 開発環境でのサービス実行方法と他環境での実行方法を統一するため、開発者体験チームと協業する
1件のコメント
Hacker News の意見
個人的には Kubernetes が好き。小規模ながら複雑なカスタムECサイトをいくつも運営していて、マーケティング、財務、カスタマーサポートまで兼任している
以前は専用サーバーで動かしていたが、スタックがかなり複雑でデプロイが悪夢のようで、結局デプロイに対する負担が小さな会社のスピードを落としていた
Kubernetesを学んで移行するのに1か月かかり、フロントエンド、商品管理、物流ダッシュボード、配送経路最適化、OSRM、ERP、レコメンドエンジン、検索など約25個のサービスを運用している
クラスター設定を一か所に集約することで、反復可能な構造に整理でき、各サービスの状態と稼働中のバージョンを正確に把握できるようになった。ダウンタイムなしの ローリングデプロイ も可能になったし、複雑ではあるが、プログラマーはそもそも複雑なものを扱うものだ。Nginxの設定ファイルだって複雑だ
深く入っていくほど、Kubernetesのアーキテクチャがなぜ妥当なのか理解できるようになり、12-factorを徹底的に守ることを強制してくれる。収益がスタックの可用性と安定性に直接結びついているなら、高可用性は単なる「あればうれしいもの」以上だ。ホスティング費用も月400ドル程度なので、そこまで高くない
Kubernetesを信頼しているほうだが、本当に複雑ではある。難しい問題を解決してくれる道具だ。マルチクラウドなら悩む必要はないし、ローカルと1:1で対応する複雑なインフラが欲しいならよく合う
ただし開発者が100人未満で、AWSにコンテナをデプロイするだけなら、2024年に ECS + Fargate の代わりにEKSを使うのは正気ではないと思う
インフラ基盤を改善しようとする移行自体は良い。ただ、動機の一つが、各チームにTerraformへ変換させるのではなく Helmチャート を使わせることだったという点は意外だった
実際、任意のHelmチャートを修正なしで安定して使っている例はあまり見たことがなく、利用を促すと結局チームがチャートをフォークして修正することになる。Helmはあまりにひどいツールなので、自前のカスタムHelmチャートを保守したいとは思わない
むしろTerraformで書き直したほうが、ローカル版を保守しやすいと思う。反例があるなら聞きたい。最近はHelmの
indent 4狂気や多段文字列テンプレート問題がなくなっているのかもしれないのでKubernetesワークロードをTerraformで管理することもできるが、おすすめはしない。Kubernetes自体に状態があるのにTerraformも状態を持つと、Terraform + Kubernetesの組み合わせはつらくなる。HelmはKubernetes用に作られており、Terraformはそうではない
とはいえHelmが好きなわけでもない。テンプレート化されたYAMLは好みではないし、
indent 4の狂気もまだある。Kustomizeは単純なときは良いが、アプリが複雑になるとHelmより悪いと思う。たとえば複数環境に対してIngress、TLS証明書、external-dnsを持つアプリをデプロイする場合、一つの変数を三か所で使えば済むことのために、リソースを三回パッチしなければならないHelmもTerraformも人気があるのでよく言及されるが、最終的にはこの二つに代わる、まだ一般化していないツールが出てくる気がする
Terraformの問題は、ワークスペースごとの推奨リソース数である約100〜200個を超えないようにワークスペースを設計しなければならない点にある。そうしないと、触ってもいないし触るつもりもないデータベースやネットワークまで確認するため、planが大幅に遅くなり、デプロイ時間が延びる
実際には互いをトリガーする Terraformワークスペース の格子を作ることになるが、これをきちんと支援する良いオープンソースツールは今のところない
現時点で最善に見えるのは、TerraformがArgoCDのような継続的デプロイツールをインフラの一部としてインストールし、日常的なデプロイはCDツールに任せることだ。そしてほとんどのCDツールは、デプロイをHelmのようなものでパッケージ化することを求める
しかし 落とし穴 があまりにも多く、他のエンジニアが作った作業をやり直したりデバッグしたりするのに時間を使う羽目になる
timoniという新しいツールが勢いを得ることを願っている。Helmに対して抱いている不満のほとんどすべてを解決してくれる。より良い解決策を探しているなら、timoniを確認してみる価値がある私たちは公開Helmチャートはそのまま使い、カスタマイズは
kustomize —enable-helmで処理する方式を選んだ私たちの場合、妥当なデフォルト値を提供する単一のアプリケーション/サービス基盤のHelmチャートがあり、すべてのデプロイがそれを拡張している。利用側で必要なHelm valuesの設定は最小限で、自前のテンプレートを入れなければならなかったケースもほとんどない。基盤チャートが十分な調整ポイントを公開しているからだ
サードパーティのチャートはかなりの数をそのままデプロイでき、たまに必要な機能をupstreamへPRで追加した。まれにラップしたりフォークしたりする必要はあったが、そのままデプロイしたサードパーティチャートのほうがはるかに多い
カスタムチャートを保守するときは helm unittest (https://github.com/helm-unittest/helm-unittest) がリグレッションを避けるのに大いに役立つ
TerraformでArgoCDを含むいくつかのKubernetesリソースを管理してはいるが、一般的にはArgoCD経由でHelmチャートをデプロイする方式のほうが、はるかに管理しやすく生産的だった
HNでこれほど反 Kubernetes 感情が多いのは不思議に思う。コメントしている人の多くが Heroku、fly.io、render.com のようなサービスに慣れた開発者だからなのか、それとも VM でアプリを動かしているからなのか気になる
これは特定の事例に限った問題ではなく、業界全体の大きくずれたインセンティブと、ある程度は低金利時代のゴールドラッシュが生んだ問題だ
正直、今の姿のままだと他の分野ではかなり役に立たない職人に見えると思う。ツールやメタ作業に不健全なほど執着し、特定のツールを使うために合理的なリソース利用を何度も窓の外へ放り投げている。一種の「一時的に困った立場にある FAANG エンジニア」のような状況だ
AWS で選べるデプロイモデル、たとえば EC2 の VM イメージ、Elastic Beanstalk、ECS/Fargate、Lambda の代わりに Kubernetes 上に構築すると、どれほど時間が余計にかかり、どれほど多くの専門性が必要になり、どれほど脆弱になり、どれほど多くの費用がかかるのかを説明するのは難しい
自分で ELK スタックや Prometheus をインストールして維持したくない。CNI プラグイン、Kafka、高可用性 Postgres、Argo、Helm、コントロールプレーンのアップグレードと格闘したくもない。AWS の対応サービスならほぼ即座に始められ、保守もほとんどなく、コストも通常はほぼゼロに近いところから線形に増え始める
ビジネス上の問題をはるかに速く効率的に解ける。期待を大きく上回れる状況と、チーム全体が数四半期遅れる状況との差だ
ただし、本当にマルチクラウドやオンプレミスの要件があるなら、Kubernetes 以外は使いたくない。Kubernetes を理解している熟練エンジニアが多い大企業なら、それほど悪くないのかもしれない。少なくとも私が働いた場所はそうではなかった
企業が主にオープンソースのインフラへ移行していく様子を見るのはよいことだ。その多くは CNCF (https://landscape.cncf.io)、ASF、そして GitHub 上のさまざまなプロジェクトから来ている
kata-containers がその不安を解消し、Kubernetes を楽しめるようにしてくれるかもしれない
全体として、Kubernetes には個人的に格好いいと感じるものがない。コンテナ、ロードバランサ、メガバイト単位の YAML はもう全部見たし、試してみるほど面白そうには感じない
この規模の会社では普通なのかもしれないが、こうした巨大なマイグレーションや技術プロジェクトの意思決定を追うのは難しい。決定がユーザーや会社の必要から出ているように見えないからだ
Figma が以前データベース関連で投稿した似た記事でも同じように感じた
たとえば Kubernetes に行きたい理由が ECS では etcd/Helm を使えないからだとしたら、まずなぜ etcd/Helm を使いたいのかを問うべきだ。それは本当にそれほど重要なのか。会社の目標を達成する方法は本当にそのやり方だけなのか。
決定がユーザーの欲求に基づいていれば、下位の決定が妥当かどうかを検証しやすいが、技術的欲求に基づいていると、その技術的欲求の文脈では下位の決定がもっともらしく見えても、なおユーザーの文脈で妥当なのかは不確かだ
私がこの規模の組織を理解できていないのか、あるいはこの規模の組織では価値ある仕事を特定し推論すること自体が根本的に難しいのか、そのどちらかなのだと思う
私たちは本質的にはプラットフォームチームであり、実際の製品体験を作る Figma の開発者たちを支援するツールを作る、別のプラットフォームチーム向けのツールを作ることが多いです。エンドユーザーから離れるほど正しい決定を推論するのは難しくなりますが、同時に大きなレバレッジも生まれます
プラットフォームを正しく作れば、その効果は他のすべてのエンジニアが効率的かつ効果的に働く能力に影響します。その影響の多くは間接的です
etcd と Helm をサポートできないので別の回避策を探すように言う選択肢も確かにありました。ただ、この2つは、私たちが Compute プラットフォームを誤った基本構成要素の上で運用しているという結論へ押し進めた追加のデータポイントでした
推論が難しくても、うまくやろうと努力する価値は大きいです。プラットフォームチームとして最高のプラットフォームに到達するために、正しいことをしているか確認する方法だからです。だからこそ、この決定を下すのに多くの時間を使いましたし、記事にするのに興味深いテーマだと思いました
大企業の Kubernetes マイグレーションのかなりの部分は、マルチクラウドやオンプレミスとのハイブリッドへの欲求、コスト・可用性・ロックインリスクの緩和が原動力である可能性が高い
VM のアップグレード、認証、バックアップ、ログローテーションなどをすべてそろえなければならない
Kubernetes では各自に名前空間、ポリシー、ボリュームを与えられ、DaemonSet と Kubernetes/クラウドネイティブスタックのおかげでログ集約も自動化できる
自己修復などもあり、どれほど良くなるか説明しにくいほどだ
たとえば分散環境における
.pidファイルに相当する用途で使える、高可用かつ一貫性のあるデータストアはあまりない。思い浮かぶのは Zookeeper くらいだが、運用面では本当に苦痛で、古い JVM バージョンを要求し、それでも全体として不安定だTerraform コードが適用されると、インスタンス 0 個の ECS task set を作ってサービステンプレートを立ち上げ、その後、開発者がサービスをデプロイする際にこのテンプレート task set を複製し、いくつもの手作業をしなければならなかったという部分は、ECS の問題というより Terraform + ECS のデプロイ管理方式を過度に複雑にしてしまったように聞こえる
実際のデプロイ前に検証するためにテンプレートを作る部分は理解できる。ただ、これは少し微妙だと思う
そのため、この項目は移行プロセスに含めることにした作業として意図的に分類し、移行を始めた根本的な理由には入れませんでした
ただ、この方式が必要になるシナリオはいくつか想像できる。たとえば ECS にデプロイされたサービスが多く、Terraform の状態サイズが大きくなる場合。そうなると plan と apply が大幅に遅くなり、テンプレートベースで構成をそのまま複製して Terraform の状態をシャーディングする方がずっと安全になることがある
環境変数を Terraform ファイルに追加し、マージした後に CI がデプロイする、という程度がすべてだった。私たちが行う設定変更のほとんどはその流れで処理できていた
「Kubernetes への移行には何年もかかることがある」って、いったい何を読んでいるのかわからない
誰にとってそうなのか？ 企業がなぜこうした移行をわざわざ行うのかもよくわからない。ビジネス価値はどこにあり、顧客へのメリットはどこにあるのか？ Figma ができるからやるという、「芸術のための芸術」プロジェクトのようなものなのか？
約 30 年の歴史があり、それに伴う負債もあるかなり成熟した会社でも、私たちはもっと短い期間で Kubernetes に移行した。ただし、すべてを Kubernetes に移そうとはせず、メリットがあるものだけを移した
私たちの提案はだいたいこうだった。Kubernetes に移行すれば、年末に予定されているデータセンター移転時には点検以外に何もする必要がない。そうでなければ、新しいマシンや VM にアプリを再デプロイし、それに伴うさまざまな厄介ごとに対処しなければならない。すでにコンテナ化されていないなら、今コンテナ化すれば残りはこちらで対応する
ほとんどが移行し、結果に非常に満足していた。一方で、レイテンシに敏感なサービスや高性能計算領域のサービスは、無理に移す理由がなく、押し込もうともしなかった
ここから抜け出すにはどれくらいかかるのだろう？
アプリがすでにマイクロサービス化されているなら、元に戻すのも簡単ではない
初めて聞くかっこいい名前の CNCF プロジェクトを 6 つも、見た目には単純な機能を得るために何気なく挙げているブログ記事を読むと、自分が時代遅れになった気がする
プロのソフトウェア開発者として、年を取って退場する時期なのかと真剣に考えてしまう
ただ、組織をスケールさせる一つのアプローチ、つまりプラットフォームチームがハードウェア、ロギング、リトライなどを抽象化するやり方に慣れていないというだけ
唯一のアプローチではないので、別のやり方には慣れているかもしれない
この記事は、Kubernetes で得られるメリットと理由を明確かつ筋道立てて説明していて良い
多くのチームは何を得られるのかも、そもそも必要なのかもわからないまま飛び込むが、ここで示されている理由は妥当に見える
すでに他のコメントがこの点を指摘している: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
純粋な疑問だが、正気の人が 1 年以内に移行したと自慢できるような、他の現代的なシステムやサービスには何があるだろう？
Kubernetes のようなシステムはたいていインフラの中核であり、稼働中のあらゆるものに影響する。そこに記事で触れられているチーム上の制約まで加えると、1 年はそれほど悪くは聞こえない
すぐ思い浮かぶ例としては、以前 Amazon が Oracle から完全に Amazon/オープンソースのリレーショナルデータベースへ移行した件がある。ただし、それは数年かかったと記憶している。1 年以内に終えていたなら、間違いなく自慢していただろう
技術そのものよりも、技術的負債、統合の複雑さ、投入できる人員の問題であることの方が大きい