Cloud Native の作法: 成熟度モデルを活用したCloud Nativeへの道筋

2023年7月13日、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、KABUTO ONE（東京）のオフライン会場にて実施され、一部のセッションはオンライン配信も行われました。

本記事では、オンラインでも配信されたセッションのうち、株式会社スリーシェイクのソフトウェアエンジニア、@nwiizoさんによるセッション「Cloud Native の作法―成熟度モデルを活用したCloud Nativeへの道筋―」の内容をお届けします。

このセッションでは、Cloud Native Computing Foundation（以下、CNCF）が発表した「Cloud Native成熟度モデル」を活用し、Cloud Nativeテクノロジーを全面的に採用するまでの道のりについてお話いただきました。

■プロフィール
nwiizo（ニュイゾー） /@nwiizo　
株式会社スリーシェイク ソフトウェアエンジニア
インフラエンジニアとしてホスティングサービスの開発、運用を経て、現在は株式会社スリーシェイクにてソフトウェアエンジニアとして勤務。Webシステムの歴史、運用、開発について興味があり、SREのような信頼性の観点からのプラクティスや運用技術をプロダクトに落とし込めるように日夜開発を行っている。

SRE総合支援サービスなどを展開するスリーシェイク

nwiizo：株式会社スリーシェイクの元内と申します。今回は「Cloud Nativeの作法」というタイトルで、最近発表された成熟度モデルを用いながら、Cloud Nativeにおいてどういった道筋をたどっていけば良いのかについて、お話をさせていただきます。

スリーシェイクは、SREやセキュリティ、データエンジニアリング、HRなどの領域で事業を行っている会社です。

自分は、Sreake事業部というSREの支援事業を行う組織に属しています。「Sreake SRE」では、SREチームの組成や、文化の定着、技術者の採用コンサルティングなどをトータルで支援しています。

技術選定の迷いに答える、Cloud Native成熟度モデル

nwiizo：それでは、さっそく本題です。 Cloud Nativeとは何かについて、よく聞かれるのが「Cloud NativeってKubernetesのこと？」といった声ですが、そうではありません。CNCFは、「Cloud Native技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらす」と定義しています。

これをまとめると、コンテナやサービスメッシュ、マイクロサービス、イミュータブルなインフラストラクチャ、宣言的APIなどを用いて、回復性があって管理力が高く、可観測性があって堅牢な自動化によって変化に強い、疎結合なシステムを実現することが、Cloud Nativeの定義になります。なので、あくまでKubernetesなどのCloud Native技術は、この疎結合のシステムを実現するために存在している、ということになります。

nwiizo：CNCFによるTrail MapやLandscapeでは、Cloud Nativeの領域に必要な、さまざまな技術が紹介されています。しかし、たくさんの選択肢がある一方で、「どの技術から手をつけたらいいのか？」、「どうやって取り組んでいけばいいのか？」といった、悩みや疑問を抱く声もよく聞かれています。

そんななか、2023年1月にCNCFは、そうした問いに答えるCloud Native成熟度モデルのドキュメントをWebで公開しました。これはCloud Nativeの実践について、5つの領域を5つのレベルで定義するもので、何を達成すれば次のステップに進めるのかを明確にしてくれています。

領域は、人（組織）、プロセス、規定（ポリシー）、ビジネス上の成果（ビジネスアウトカム）、テクノロジーの5つ。この成熟度モデルは、現状の評価と今後の方向性を明確にして、自分たちができていると思っていた部分についても、抜けや漏れを明らかにすることができます。

なお、Cloud Nativeの成熟度モデルは、Kubernetesを使用する環境を前提としていますが、使用していない環境であっても、多くの学びを提供してくれます。

Cloud Native成熟度モデルの5つの領域とレベル

nwiizo：ここからはCloud Native成熟度モデルの、5つの領域についてに触れていきたいと思います。まず1つ目の領域、「People」ですね。ここでは、組織やチームの取り組み、成長のためのプロセス、セキュリティなどの組織への取り組みについて触れられています。

2つ目の「Process」では、必要となるプロセスやワークフロー、CI/CDやIaD（Infrastructure as Data）などの取り組み、セキュリティのShift Leftを定義してくれています。

3つ目の「Policy」では、組織やチーム内外のポリシーや規制、セキュリティやガバナンスの特定や適応、ポリシーのビジネスへの反映などを行います。

4つ目の「Technology」は、CI/CDやGitOps、可観測性にちゃんと取り組めているか、セキュリティの分野がチームのサポートに役立っているかなどが挙げられます。

5つ目の「Business Outcomes」には、ビジネスリーダーやCEOを始めとするCxOなど、売り上げを上げる人たちと、どういった関わり合いができるかについて書いてあります。

nwiizo：そして、それぞれの領域は、5つの成熟度レベルに分けられます。 レベル1の「Build」は、基本的な理解を深めていく、本番前の段階ですね。 レベル2の「Operate」は、本番には移行したけれども、スケーリングなど、まだいろいろなものが不足している状態です。

レベル3は「Scale」。これは組織やチームの拡大や、環境に適応するための手順が定められた段階になります。 レベル4の「Improve」は、各環境に対してセキュリティ対策や各種ルール、管理体制を適用し、どんどん改善を行っていく段階です。

レベル5の「Optimize」は完全に自動化して、組織も自立化していて、過去の決定を再評価する段階。アプリケーションやインフラの監視を通じて、システムをより最適な状況に近づけることが目的になっています。

nwiizo：成熟度はそれぞれ領域ごとに異なり、例えばProcessはレベル3だが、Policyはレベル2、といった差異が出てきます。また、同じ領域内でも、一部はレベル4に達していると言えるけれども、他の部分はまだレベル3に達していない、ということが出てきます。自身やまわりのプロジェクトを見ていると、均一でないことがほとんどですね。

なお、公式のドキュメントでは、レベルごとに解説されているのですが、今回の発表では、領域ごとに解説していこうと思います。時間の都合上、内容をかなり割愛しながら進めていきますので、詳しく知りたい方はドキュメントを読んでいただき、もし指摘があればTwitter等でいただけると嬉しいです。今回は、こういうものがあるのだなと、知ってもらうきっかけになれば幸いです。

5つのレベルごとに見る「People」の6つの領域

nwiizo：「People」のレベル1から見ていきましょう。レベル1は、チームはCloud Nativeなフレームワークを学習して、基本的な理解を持つことに努めるフェーズ。「People」は、6つの項目に応じた内容で書かれています。

まず「組織変革」では、変革は限定的であり、初期段階ではPoCや単一アプリケーションに注力します。「チームの分散化」では、まだ本番に適用するわけではなく、例えばKubernetesでどんなことができるかなどを考え、本番環境への運用を目指す段階です。

「セキュリティ」は、やはりCNCFのドキュメントなので、セキュリティに重きが置かれていて、より堅牢であれば良いという内容になっています。「開発者のアジリティ」は、team of teamsを採用し、成熟度に合わせてツールを実装すると書かれています。

「開発者のスキルアップ」では、開発者のスキル向上とCloud Nativeの理解を深めることが挙げられています。「CNCFによる認証」では、資格情報に関して記載されていて、重要だが、レベル1では資格取得をしている人は少ないと記述がありました。

nwiizo：続いてレベル2は、スキルとトレーニングへの投資によりエキスパートを育て、Cloud Nativeの領域での専門知識を獲得していくフェーズ。リーダーがCloud Nativeのイニシアチブを取って、組織内で実施をリードしていく段階になります。

「組織変革」としては、Cloud Nativeを推進するためのアジャイルプロジェクトチームを設立し、迅速なフィードバックやテストループを実施していきます。

「チームと分散化」では、共通サービスと責任の明確化。そして、ツールを無限に使うわけにはいかないので、使うツールと使わないツールを決めたり、いわゆる過去の遺物を停止しましょうという内容も、ここに書かれていました。

「セキュリティ」では、クラスタのセキュリティ管理と責任を明確化し、セキュリティチームを参加させましょうと書かれています。「開発者のアジリティ」は、技術的課題の解決や分散ビルド、自動テストのコミットなど、デプロイを全部ではなくとも部分的に自動化しましょうというのが、レベル2です。

「開発者のスキルアップ」については、Kubernetesの基本操作の実行能力向上を目指します。また、「CNCFによる認証」のレベル2では、CKAやCKADの資格取得を検討してくださいと書かれています。

nwiizo：レベル3では、各チームの能力向上と、専門知識の明確化を行います。Cloud Native Center of Experienceを活用して、Cloud Native戦略の一部として持ち込むことが重要になります。

「組織変革」では、能力向上に伴って組織構造やチーム編成を整備する必要が出てきます。アジャイルやスクラムの導入、基盤側の開発なども含まれてくるフェーズです。

「チームと分散化」については、責任の明確化と理解。責任が伴ってくることで、速度の低下が起きる可能性や、人によって知っていたり知らなかったりというボトルネックが出てくる可能性があるので、より教育を大切にしましょうという記載があります。

「セキュリティ」では、リスク許容度に基づいたセキュリティトレーニングに焦点を当てています。

「開発者アジリティ」としては、継続的デリバリーの実装や、運用チームとの統合、限定的な機能の実行などがあります。

「開発者のスキルアップ」では、反復可能なトラブルシューティングサイクルを導入し、再現性のあるトラブルシューティングを行っていくことなどが挙げられます。

最後に、「CNCFによる認証」では、CKAとCKADの認定取得の検討が勧められています。

nwiizo：レベル4では、開発チームがセルフサービス能力を向上させることによって、より主体的に取り組み、リーダーシップを発揮することができます。これによってCloud Native導入や活用に関して、積極的な役割を担うことができます。

「組織変革」としては、Cloud Nativeのインフラストラクチャがデフォルトになり、最初からDevSecOpsのようにセキュリティを組み込んだ形で、サービスがデプロイできる状況に進んでいきます。

「チームと分散化」では、プラットフォーム確立と分散化が始まり、自己サービスポータルの開発や、開発者サービスの所有権の確保を行います。「セキュリティ」では、セキュリティチームの設計とデプロイメントへの関与、内外のポリシーの規則の理解などがあります。

「開発者のアジリティ」としては、フィードバック領域が広大になり、バリューストリームのマッピングや高速テスト、リスクの特定ができるようになります。「開発者のスキルアップ」は、Kubernetesの広範な利用者に対する知識共有、ニーズに合わせたKubernetesの拡張が挙げられます。

「CNCFによる認証」では、セキュリティに関する知見として、CKS資格取得の検討や、それに伴う知識やスキルが必要だとされています。

nwiizo：そしてレベル5は、組織の成熟度を高めるために、DevOpsとDevSecOpsの採用を進めることがより重要になります。また、新しいテクノロジーの導入や、サンドボックス環境でのトライアルを実行可能にすることも求められます。これによって、より効率的な開発とセキュリティの統合を実現し、組織の成果を最大化することを目的としています。

「組織変革」としては、組織全体がCloud Nativeの環境にコミットしている状態。

「チームの分散化」では、サービスのセルフプロビジョニングが始まり、サービスのオーナーシップがどんどん明確化していくフェーズになります。

「セキュリティ」では、コミュニティや既存の規制当局との協力で、セキュリティの強化を図ります。

「開発者のアビリティ」としては、メンバーが変動するスループット、人が入れ替わることへの対応や、技術データに基づく意思決定、FinOpsの導入も、このレベルで行います。以上で、「People」の領域は終わりです。

5つのレベルごとに見る「Process」の4つの項目

nwiizo：次は「Process」ですね。少し長くて重複する部分もあるので、ところどころ割愛しながらお話していきます。まずレベル1のProcessでは、機能や非機能要件のマッピング、手動フィードバックや修正、Gitワークフローの定義、システムライフサイクルの管理などが挙げられています。

まず「CI/CD」ですが、Cloud Nativeへのトランスフォーメーションの中心はCI/CDの採用で、これによってアプリケーションの構築テスト、デプロイが推進され、より良くなっていきます。すでにCI/CDを行っている場合は、それをCloud Nativeに統合して、既存のベストプラクティスを改善していきます。

「変更管理」では、デプロイメントを管理するための変更管理を実施します。レベル1では、変更プロセスはおそらく不完全で、変更は個人が頼むようなアドホックなリクエストに基づいて行われます。

「セキュリティ」は、セキュリティツールのプラクティスを早期に組み込むことで保たれます。セキュリティは成熟度モデルの全段階に関わっていて、レベル1から入っているのは、これ自体がShift Leftのアプローチだと認識していただければと思います。

「監査とログ」において、ロギングと監査は実装すべき重要なプロセスで、内部要件の遵守やコンプライアンス業務の支援のために行われます。レベル1では、手動でのスクレイピングが行われ、集約的なログのポイントやSIEMがまだ存在しない可能性もあります。

nwiizo：レベル2は、アプリケーションの本番移行に重点が置かれています。GitとCIの使用を習熟し、構造化されたビルドとデプロイプロセスを開始します。

「CI/CD」については、アプリケーションに向けて、CI/CDの特性を活かして、ビルドとデプロイプロセスを導入します。「変更管理」では、SCM（ソースコントロール管理）からデプロイまでのワークフロー理解を深めて、SCMでのコミット、マージ、タグ付け、デプロイトリガーを可能にします。

「セキュリティ」は、CIプロセスにセキュリティを組み込み、例えばコンテナをTrivyで自動的にスキャンするなど、スキャニングを行います。「監査とログ」では、ログの集約を定義するための時間を確保することが大事になります。

nwiizo：レベル3では、組織内での標準化を推進、反復性を重視してコラボレーションを強化し、リソースの使用状況を監視していきます。また、この段階では、自動化とIaC（Infrastructure as Code）の導入を、プラットフォーム使用者全体に広げることを目的としています。

CI/CDを中心としたCoE（Center of Excellenece）を構築したり、コード品質を向上させ、CIとテストの成功率を高めていきます。初期のアラートを導入して、ノイズのフィルタリングを行うのもこのフェーズになります。

nwiizo：レベル4では、組織でDevSecOpsをサポートするガバナンスモデルの導入を始めます。このモデルにはガードレールのようなものが設けられていて、アプリケーションサービスライブラリや自動スケーリングポリシーの整備も行われるべきだと書かれています。

「CI/CD」では、リソースとデリバリーのケイデンスを測定し、改善していきます。「変更管理」では、CDは実現しているが、本番への自動デプロイは実現していない、まだ認証が必要で完全自動化はされていない段階になります。

「セキュリティ」としては、セキュリティ修復の自動化の実装や、検知および修復アドバイスの自動化を進めます。「監査とログ」では、監査とアラートが主流となり、アプリケーションではそれらが確実に整備されている状況になります。

nwiizo：レベル5では、組織はCloud Nativeの設計能力を構築し、障害のあるリソースの自動管理が可能になります。また、この段階ではリソースの使用状況に応じて、コストの最適化や人的リソースの配置変更も行われます。

「CI/CD」では、組織全体でCI/CDのメリットが認識され、開発速度の向上や新機能の迅速なリリースが可能になります。「変更管理」では、本番環境への継続的なデプロイが可能で、問題が生じたリソースの自動再起動や管理が行えます。

「セキュリティ」では、SBOMなどによってコードと依存関係を精査し、明確なコードの出処や、安全なデプロイリリースのパイプラインを確保します。「監査とログ」としては、組織全体で定期的に監査を実施できる状況になっています。

5つのレベルごとに見る「Policy」の2つの項目

nwiizo：続いて「Policy」ですね。Policyは、全体的に言っていることが大きくは変わらず、少しずつ良くしていきましょう、という内容になっています。

初期段階のレベル1では、チームは限定的な文書化されたポリシーを作成して、クラウドで構築するサービスをサポートします。しかし、組織のポリシーやコンプライアンスの要件は、Cloud Nativeの環境に適応するように変換する必要があります。

つまり、今までこのユーザーがこんな権限でやっていたという既存のものを、Cloud Nativeの言葉に変更する必要がありますよ、という意味合いになっているのがレベル1ですね。

nwiizo：レベル2は、サービスが本番運用に入るフェーズなので、初期のポリシーを標準として合意し、その部分を文章化することによって、一貫性の確保、遵守の容易化、チームのコラボレーション強化を行うことを目的としています。

「ポリシーの作成」では、必要なメトリクスを定義して、データの収集を開始します。「コンプライアンス」としては、簡単なスクリプトを用いて、初期の監査を行っていれば十分だといえます。

nwiizo：レベル3では、コードとしてのポリシーを実装し、CIパイプラインに組み込むことで、一貫性の確保、自動化と効率化、リスクの低減、トレーサビリティの向上を実現します。これも同じようなことで、より自動化を進めていきましょう、といった内容ですね。

nwiizo：レベル4では、SLAが定義されたポリシーの回復について具体化することで、サービスの品質と信頼性の向上、顧客満足の向上が実現します。

「ポリシーの作成」では、ビジネスニーズに基づいたカスタムポリシーを定義し、例外を最小限に抑えます。サポートしているサービスが増えると、どうしても例外がどんどん出てくるので、それをなるべく小さくしましょう、ということですね。

「コンプライアンス」については、ポリシーツールを拡張して、トラフィックやサービスメッシュ、メッセージパス、Linuxなどを含む、あらゆるアプリケーションにポリシー定義を広げていくことが挙げられています。

nwiizo：レベル5では、機械学習などを用いて検出と対応を行います。ポリシーの改善と最適化、検出と対応の自動化、リアルタイム対応能力の向上、エラーレスポンスの最適化が、この段階で実現されます。レベル5の各項目はレベル4とほぼ一緒で、機械学習もやっていきましょう、といったことが書いてあります。

5つのレベルごとに見る「Technology」の6つの項目

nwiizo：では、続いて「Technology」です。ここは文量が多いので、駆け足でご紹介します。項目は6つあります。初期段階のレベル1では、新たにKubernetesを導入し、試験的に活用します。この段階の主な目的は、ベースラインテクノロジーの実装で、自動化の範囲はまだ限定的です。

テクノロジーとしてもフックとして作ることが多いので、CI/CDパイプラインやKubernetes、カスタマイズ等々のツールも、少しずつ学んでいきましょう、というフェーズになります。

nwiizo：レベル2からは、いよいよ本番への移行を開始します。初期の基盤構築から始めて一歩一歩、本番環境へのステップアップをしていきます。この段階では、監視と可観測性を組み込む必要があります。また、サービスとしての運用能力を確保することで、アプリケーションを本番環境で適切に運用する準備を行います。

nwiizo：レベル3では、スケーリングと標準化されたツールの導入が行われます。組織全体からも支持や期待が高まり、本番環境での評価、実装、実行に重点が置かれます。

ここで見ておきたいのは、「アプリケーションのリリースと操作」ですね。レベル3から、Helmチャートを使ったアプリケーションリリースが行われます。GitOpsへの取り組みも始まり、リリースと運用を管理するコントローラーが導入されます。

nwiizo：レベル4では、チームは完全に環境を制御できていて、その環境に対する自信を深めているフェーズになります。組織全体のCloud Nativeのコミットメントが得られて、効果的に成長を加速させていきます。

Kubernetesと各種APIの取り扱いが日常的なものになり、インフラストラクチャとIaCツールを使って、誰でも簡単にデプロイできる環境が整っている状況になります。また、GitOpsのオペレーターを利用してアプリケーションのデプロイメントを行い、フィードバックループが速やかに閉じられるようになっています。

nwiizo：レベル5は、完全に機能的・非機能的な領域の自動化に集中しています。基本的な運用すべき業務が、オペレーターによって代行されて、全体的な運用が自動化されています。

完全な自動化まではいかないにしても、多くが自動化されるような定義になります。工夫されている会社さんはさまざまいらっしゃいますが、ここまでやっているところは少ない印象です。

ビジネスとの関わり合いを考える「Business Outcomes」

nwiizo：続いて、「Business Outcomes」。ビジネス的にどう振る舞えばいいのかについてですね。レベル1は、前段でもお話したように、種まきのフェーズです。なので、Cloud Nativeの基本的な設計と実装を行い、初期の成功体験を得ることを目的とします。

KPIを設定し、Cloud Nativeによるビジネス上の利益を評価して、関係者に結果を伝達することが重要になります。KPIの例としては、コスト削減、開発時間の短縮、信頼性の向上などが挙げられます。

投資のフェーズなので、エンジニアリングリーダーやアプリケーションの開発者、CEOや取締役会との成果の共有を行い、理解と協力を獲得することが必要です。次の段階への取り組み評価と反対意見の管理のため、これらのステップは非常に重要で、ここを飛ばすと誰にも使われないシステムが生まれてしまう可能性があります。

nwiizo：レベル2は、移行フェーズと投資期間ですね。アプリケーション郡は、完全にCloud Nativeのツールと手法に移行しています。ビジネスはCloud Nativeのメリットを評価する能力を、このレベルで確立する必要があります。レベル1で確立したKPIを用いて、成功や失敗を測定し、ステークホルダーに共有します。

焦点は、本番環境への移行やテクノロジーの標準化、ポリシーの実装に当てられます。開発、セキュリティ、運用の各チームが業務を効率化するための、反復可能なパターンが生まれることも、レベル2の重要な点です。この段階では、投資収益率はまだ低い可能性があり、投資期間だといえます。

nwiizo：レベル3になって初めて、機能のもとが取れたり、チームとしてのまとまりが出てきたりすると語られています。チームの能力向上や規模拡大、モニタリングの実装によって、リソースの使用状況の動向が測れるようになります。

nwiizo：レベル4は、投資した後の振り返りのフェーズに入っており、全体的なセキュリティやポリシー、ガバナンスの改善が焦点になります。Cloud Nativeの知識をビジネス目標に適用したり、確立したプロトコルや手順、コンプライアンス標準を適用したりすることが挙げられます。Cloud Nativeと非Cloud Nativeのアプリを、組織内で比較できることも重要です。

nwiizo：レベル5は、徹底的な最適化フェーズです。前述したPeople、Process、Policy、Technologyの各領域におけるさまざまな変化を感じ取り、それに絶え間なく適用していく段階になります。

主なビジネスの成果は、達成された目標に対する継続的な最適化の進行を追跡する能力とされています。以上で、Cloud Native成熟度モデルの5つの領域すべてのご紹介が終わりました。

価値のないシステム、Platformの悲劇を生まないために

nwiizo：最後に、Platformの悲劇を防ぐためにはどうするか、というお話です。例えば、1人の凄腕エンジニアがプロセスもポリシーも整備してくれて、技術的な課題もすべて解決してくれたが、ビジネスとの同意が取れていなかったとします。人々が上手に使えず、ビジネス的な合意もないシステムに価値はあるでしょうか？

この場合、価値があるといっても芸術的な価値しかなく、答えはおそらくNOです。最初はユーザーも少ないし、システムも安定せず、価値を生み出せないのが当たり前です。価値が低い、もしくはわからないシステムは、選択の余地があれば使われません。そして、システムのユーザーがいなければ、価値がないので投資されないでしょう。

nwiizo：こうしたPlatformの悲劇を生まないためには、誰にとって価値が生まれるのかを定義する必要があります。例えば、ビジネスリーダーにとっては、Cloud Nativeによって効率的なリソースの利用ができたり、迅速な機能提供ができたりすることが価値になります。

開発チームにとっては、自動化されたプロセスや継続的なデリバリーによって、開発生産性が向上できるなどの価値が必要です。また、Platformの領域だとユーザーは軽視されがちですが、ユーザーにとっては、パフォーマンスや信頼性が向上することによる、体験の向上が価値につながります。

もう1つ大事なのは、価値を具体化すること。そのために、Business Outcomeのところで触れたように、KPIを設定をする必要があります。ただし、早すぎる段階で高いKPIを設定すると、成長を阻害する可能性があります。

価値の例としては、インフラストラクチャの最適化による開発コストの削減、自動化による作業効率の向上などが考えられます。また、セキュリティの強化やコンプライアンスの確保、顧客満足度の向上なども重要な価値になります。

価値を明確化し、ステークホルダーへ伝えることの重要性

nwiizo：結局、“どうやって”だけではなく、“誰に何を”が大事になってくる、というのが今回の最終的なまとめになります。大事なのは、ステークホルダーへの伝播とパートナーシップ。価値を明確化し、ステークホルダーへ適切に伝達することが重要です。

エンジニアリングリーダーやビジネスオーナーなど、さまざまな人との共通理解や合意を形成することが、Cloud Nativeの成熟度を次の段階へ進めてくれます。そして、継続的な評価と改善をもって、Platformをより良く改善していきましょう。

nwiizo：また、世の中にCloud Nativeなサービスはいろいろありますが、重要なものはいつかPlatformになります。システムをたくさんのユーザーが利用している場合には、誰かが必ずシステムの価値を見出してくれるでしょう。いずれはAPIを追加して、ユーザーの一部が他の“システム”になったら、それはPlatformを動作させているのであり、状況は変化していきます。

プロダクトがPlatformとして動作するなら、ユーザーが体験する信頼性は、あなたが行う選択だけで決まるわけではなくなります。信頼性はパートナーシップになります。あなたのシステムが多数のユーザーへのゲートウェイになれば、公式であれ非公式であれ、結果として多くの価値を生み出します。なので、最初からでなくて良いのですが、どこかでシステム自体をPlatformとして見据えることが必要です。

本日の発表では、Cloud NativeはKubernetesだけではないということ、Cloud Nativeの成熟度モデルには5つの領域とレベルがあることをお話しました。そして、Cloud NativeにおけるPlatform的な考えにも触れさせていただきました。以上で発表を終わりたいと思います。ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。