アプリケーションをモダナイズする
概要
Kubernetes とクラウドネイティブアーキテクチャを取り入れて、アプリケーション提供を加速し、サイクルタイムを削減します。
課題: アプリケーションアーキテクチャをモダナイズする
私(VP Apps)はどんな課題に直面しているか?
- 保守と統合のコスト、特に人的リソースのコスト。IT 予算全体の大きな割合が、複雑なツールチェーンの統合と保守に必要なエンジニアチームのサポートに使われています。1,000 人の開発者を抱えるエンタープライズ企業では、これらのリソースをビジネス価値の提供に振り向ける代わりに、DevOps ツールチェーンの保守だけのために 40 人のエンジニアが必要になります。
- 開発が運用チームによって遅くされ / ブロックされている。DevOps 以前の世界の本質的な課題は、開発チームが新機能を出荷することでイノベーションのベロシティを上げるよう動機付けられているのに対し、運用 / インフラチームは安定性、稼働時間、エラー削減に動機付けられているということです。開発のベロシティが高いほどダウンタイムとエラーの可能性が大きくなるため、これらのチームは互いに対立しています。VP App Dev は、デプロイベロシティを向上させるよう VP IT Ops に働きかけるための魅力的な証拠やインセンティブを十分に持っていません。
- 開発者が運用をやっている 今日、チームと個々の開発者は、コードがデプロイされる環境を心配することに多くの時間を費やす必要があります。 おまけ: インフラの可用性 チームは物理サーバーが調達、ラッキング、構成されるのを待ち、開発チームはどこにデプロイできるかを ops によって指示されます。
今日それはどう見えるか(直面する問題)?
- リソースと予算の大部分が、差別化のない統合と保守に費やされている。(例: ツールの保守に費やすお金を減らし、ビジネス価値の提供にもっと使いたい?)チームはツールでサイロ化 している - 各チームにはお気に入りのツールがあり、それらのツールセットで作業するように最適化されている。彼らは自分の専門ツール「内」で作業したい。すべてのチームがすべてのツールにアクセスできるわけではないため、コラボレーションとスタックを越えたトラブルシューティングが難しい。
- コードが書かれてから企業にとって価値を生み出すまでに長い遅延があるか、最悪の場合、本番に到達することさえない。 コードが書かれるとデプロイされずに置かれ、企業にとっての価値を生み出さない。問題やエラーが発生して開発者に戻されるとき、コードが彼らの記憶に新鮮でないため、トラブルシューティングが困難になる(コンテキストスイッチング)。彼らは取り組んでいるコードの作業を止めて、前のコードに戻り、トラブルシューティングのために再認識する必要がある。本番に到達しないコードが書かれることもしばしば。時間とお金を浪費するだけでなく、これは自分の労働の成果を見られない開発者にとってモチベーションを下げる。
- 開発者は、ビジネスロジックの開発だけに集中できる代わりに、環境依存関係や設定について心配する必要がある。彼らはどのサイズの VM にデプロイするか決めるのに時間を費やしているかもしれません。この順序での「DevOps」は「開発者が dev と ops の両方をやらないといけない」を意味します。実際にこの取り決めを楽しむ開発者はごく一部で、ほとんどは「私は開発者です。運用をやらせるのはやめてください」と言います。
ビジネスへの負の結果は何か?
- 予算の大部分が差別化のないエンジニアリングに使われる。 保守エンジニアを価値駆動に再配置しないことの機会損失コストにより、イノベーションが遅くなり、価値実現が遅くなります。
- 遅延、さらには未実現の収益。コードが書かれてから、ビジネスがそのコードから価値を得るまで遅延があります。あるいは、ビジネスが価値を得ることのないコードが書かれることもあります。
- 低い開発者生産性、低い開発者の幸福度、信頼性の低いソフトウェア(ダウンタイム = 失われた収益)。開発者がインフラと設定の作業に時間を費やし、ビジネスロジックの提供にその時間を費やさないため、生産性が低下しています。彼らは自分のコアコンピテンシーの外で働いています。これは、開発者の採用と保持に悪影響を与えます。ドメインエキスパートでない人々がインフラの決定を担当するため、稼働時間とレジリエンシーが影響を受けます。
魔法の杖が今日それを解決するなら、どう見えるか?
- 保守ではなく、より多くのエンジニアがアプリに取り組んでいる。最大限の人的リソースがビジネス価値の駆動に専念しています。 - 差別化のない重労働の代わりに、最大限の人的リソースをイノベーション(または「ビジネス価値」)に専念させる。(400 人の代わりに 500 人のエンジニア)
- 開発者は自分のコードを素早く本番で見られる。
- インフラとデプロイメントが完全に自動化されている。
- 開発者のモチベーションが上がる(誰もが自分の仕事のアウトプットを見るのが好き)
- ビジネスはそれでお金を稼ぐ - デプロイされずに(または決してデプロイされず)放置されているコードでお金を稼ぐことはできない
- 小さなチャンクのコードを出荷することによりリスクが少ない
- GitLab を使うと、開発者はテスト用にセルフサービスができるため、専任 QA チームとのオーバーヘッドや調整が少なくて済む。
- 開発者はビジネス問題の解決に集中している。コードは環境とクラウド非依存に書かれる。開発チームは自分のサービスの稼働時間を所有しているが、ops/SRE チームに支援される。Ops/SRE はインフラを所有し、dev はサービスを所有する。(私の 400 人のエンジニアは、それぞれより生産的)
ビジネスへのポジティブな結果は何か?
- イノベーションのスピード と市場での競争力の向上。
- 収益が前倒しされる。本番のコードがデプロイ待ちのキューに座っているのではなく、お金を稼いでいるため。
- 「コードを早くデプロイすることで収益を前倒しする」
- 才能を引き付け、保持する 大きな能力。専門化(dev は dev に集中、ops は ops に集中)による高品質のコードと運用。
これを実現するためにどんな能力が必要か?
- DevOps ライフサイクル全体の機能を提供できる単一アプリケーション
- 堅牢な CI/CD
- コンテナと Kubernetes
成功はどう測るか(メトリクス)
- サイクルタイム、MTTR(Mean time to resolution)
- 価値実現までの時間(コードが書かれてから本番で動くまでの遅延)
- 稼働時間、エラーレート、インフラコスト、HR 保持率
GitLab はどう問題解決を支援するか?
- GitLab は DevOps ライフサイクル全体のための唯一の単一アプリケーションです。チーム全員がアクセスでき、単一の信頼できる情報源を持ち、シームレスにコラボレーションできます。
- GitLab の組み込み CI/CD はベストインクラスです。
- GitLab は組み込みコンテナレジストリと堅牢な Kubernetes 統合を持っています
なぜ私たちは競合より優れているのか?
- すべての機能が組み込まれた唯一の単一アプリケーション。
- 競合よりも優れた CI/CD アーキテクチャ。 SCM と同じアプリの一部としてシームレス。エラーと失敗が、より早い解決のために開発者のビュー(マージリクエスト)に直接表示されます。GitLab のランナーアーキテクチャは、ジョブのスケーリングと並行ジョブの実行をシンプルにします。
これを証明する証拠ポイントは何か?
- 顧客事例 / ケーススタディ
- Jaguar Land Rover Chris Hill ビデオ
- Human Geo が Jenkins から GitLab に移行しコストを ⅓ 削減
- CNCF マルチプロジェクトパイプライン ビデオ
- 顧客事例 / ケーススタディ
アナリストレポート
- Forrester CI wave
業界アワード
その他の資料
- GitLab と Google Cloud Platform を使ったスケーラブルなアプリデプロイメント(Kubernetes 101、GitLab GKE 統合) https://www.youtube.com/watch?v=uWC2QKv15mk
- Google + GitLab - Kubernetes とは何か? https://www.youtube.com/watch?v=uWC2QKv15mk
- CNCF ウェビナー: Kubernetes デプロイメントの自動化 https://www.youtube.com/watch?v=wEDRfAz6_Uw
- CI/CD ディープダイブ https://www.youtube.com/watch?time_continue=1888&v=pBe4t1CD8Fc
