PaaSの歴史と、 アプリケーションプラットフォームのこれから

2024年6月に開催した、最後のPaaS勉強会でお話しした資料です。
PaaSが世の中に登場してから今までの流れを、PaaS勉強会の経緯を絡めながら解説しました。

Transcript

1. PaaSの歴史と、 アプリケーションプラットフォームの これから
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association
3. PaaS勉強会 最終回👋
4. PaaS勉強会 一区切りつけます • Slack workspaceは6月末で閉鎖します • Connpassは残します ◦ 過去の登壇者のスライドもあるため • YouTubeチャンネルも残します 区切りは付けつつも、 「かつてそういうイベントがあった」という記録は残したい
5. なぜ区切りをつけるの？ • PaaSを取り巻く環境が大きく変わった ◦ 今日のセッションを通じてこのあたりを語ります • 全てを残して放置という選択肢もあった ◦ 世の中のコミュニティの99%はこのような自然消滅 ◦ コロナ禍で活動が戻りつつあるが、そのまま消滅してしまうコミュニティも多い • こういう時代だからこそ、きっちり終わらせたかった ◦ Platformを取り巻く変化は、総じてポジティブ ◦ 明示的に区切りをつけることで、新しい流れに引き継ぎたい ◦ 自分が関与したはじめての技術コミュニティなので、見送るところまでやりたい
6. 2007年 PaaSのはじまり
7. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 PaaSの登場 2007年、SalesforceがPaaSという名前を 使い始める このときは、自社のCRMをSaaSではな く、コードで拡張できるより進化したもの であるとして、”Platform”という表現を使 い始めた いまここ https://news.mynavi.jp/techplus/article/20070718-a024/
8. 2009年 DevOps
9. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 DevOps 2007年から2008年ごろ、組織における開発と運 用の分断が機能不全を引き起こしているという懸 念が議論されはじめた。 2009年にDevOpsの概念が提唱される。 期を同じくしてクラウドサービスが登場しはじ め、DevとOpsが協力して取り組むという考え方 が現実味を帯び始める (EC2が2006年、ELBやCloudWatchが2009年) いまここ
10. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 アプリを簡単にデプロイしたい。運用も任せたい。 DevOpsはアジャイル開発の思想をOpsレイヤーにも取り込んでいくことになる。 アジャイルに開発して素早くリリースしたい ⇨　簡単にアプリをデプロイ・運用できるプラットフォームが必要 ⇨　Application Platformの必要性が高まる いまここ
11. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Herokuの登場 同じく2007年に、Heroku創業。 2009年にRubyアプリケーションを動かせるプラットフォームを一般公開。 Rackを使うフレームワーク(Ruby on RailsやSinatra)を動かすことができた 2010年にSalesforceに買収される いまここ
12. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Windows Azure Windows Azureが2008年に発表され、2010年に正式リリースされる リリース時はPaaSしかなかった。.NETアプリケーションをデプロイ・運用できる クラウドサービスみたいな感じ。 ちなみにjacopenはWindows Azureに感銘をうけてこの業界に入ってきた いまここ
13. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 NISTによるクラウドコンピューティングの定義 2011年、NIST(米国国立標準技術研究所) によってクラウドコンピューティングの 定義が公開される。 今でもよく使われるIaaS, PaaS, SaaSの 定義がここで固まる いまここ https://www.ipa.go.jp/security/reports/oversea/nist /ug65p90000019cp4-att/000025366.pdf
14. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ガートナーによるPaaSの分類 NISTの定義だと、ソフトウェア(SaaS)、 インフラ(IaaS)でもないものは全部PaaS とも読み取れ、曖昧な部分も否めなかっ た。 当時、ガートナーはiPaaS(Integration PaaS)、aPaaS(Application PaaS)と分け て説明していた。今でもiPaaSの表現は 使っている様子。 いまここ
15. 2011年 Open PaaSの登場
16. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Cloud Foundryの登場 2011年4月、VMwareからOSSのPaaSとしてCloud Foundryが登場。Rubyや Java、Node.jsのアプリをコマンドひとつでデプロイできるようになった。 初期のバージョンはDerek Collison氏(NATSの生みの親)のリードによって開発さ れており、NATSを中心に据えたアーキテクチャだった。 この後十数年に渡って進化していき、今のアーキテクチャは全く別物になってい る、 いまここ
17. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Cloud Foundryの登場 Cloud Foundryを使ったアプリのデプロイ いまここ ソースコードがあるディレクトリで cf push とするだけ
18. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Cloud Foundry輪読会の発足 • 2011年10月、日本で第1回 Cloud Foundry 輪読会が開催される。 ◦ これがPaaS勉強会の前身。 • 自社での活用を考えていた各社のエンジニア が中心となって運営 ◦ NTTコミュニケーションズ ◦ 楽天 ◦ 富士通など • ATNDを使ってイベントを公開していたの で、どんなセッションがあったのか分からな くなってしまった･･･ いまここ https://www.publickey1.jp/blog/11/paascloud_foundry.html
19. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 OpenShiftの登場 • Red HatからもOpenShiftが登場した。 ◦ OSSとして公開されるまではそこから1年近く 要したが。 • k8sベースの今とは全く異なる仕組み。 • Cloud Foundry輪読会でOpenShiftの話をした ◦ 2012年の第7回 ◦ 日本で初かもしれない いまここ https://techtarget.itmedia.co.jp/tt/news/1206/18/news02.html
20. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Open PaaS vs プロプラエタリPaaS このようなOpen PaaSは、クラウドないしはオンプレにVMを立ててデプロイす る形になる。 いまここ プロプライエタリPaaS Open PaaS デプロイ • デプロイした後は おまかせ • ブラックボックス デプロイ • 自前の環境で動かせる • クラウドでもオンプレでも • その気になればカスタマイズも できる • PaaS自体の運用もしないとい けない 運用
21. 2012年 国内での商用PaaS
22. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 国内の商用PaaS https://techtarget.itmedia.co.jp/tt/news/1206/18/news02.html 2012年ごろには、国内ベンダーからもさまざまな PaaSが登場した。 • C4SA(ニフティ) • MOGOK(IIJ) • eXcale(TIS) • Cloudn PaaS(NTT Com) いまここ
23. 2013年 Dockerの登場
24. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Dockerがやってきたぞ！ • dotCloud社がDockerをOSSで公開 ◦ 2011年からPaaSを提供していた会社 • その便利さで一気に注目を浴びる ◦ コマンド一発で立ち上げられる簡便さ ◦ Docker imageによる可搬性 ◦ コンテナならではの高速な起動 • 同年10月にはdotCloudの名前を捨てて社名ま でDockerになるほど。 いまここ
25. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ※ PaaSでコンテナを使うこと自体は普通だった • Dockerがコンテナ技術を生み出したのではないことに留意 • Docker以前からマルチテナント型PaaSでは、ユーザーごとのアプリケーショ ンを隔離するためにコンテナ技術が活用されていた。 ◦ HerokuはLXCを利用 ◦ Cloud FoundryはWardenという独自のコンテナ • Docker imageのような汎用的なイメージ規格はなく、純粋にCgroupsと Namespacesで環境を隔離するために使っていた • ただの軽量仮想化環境ではなく、イメージの共有、ビルドのコード化などの 思想を持ち込んだDockerはエポックメイキングだった いまここ
26. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 登場するさまざまなOpen PaaS いまここ Dockerを実行基盤としたさまざまなPaaSが登場。いずれもAlternative Heroku的 な思想で設計されていた https://www.slideshare.net/jacopen/docker-paas-op enshift-deis-flynn
28. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Cloud Foundry Haiku ”Here is my source code Run it on the cloud for me I do not care how” 「このソースコードをクラウドで動かしてくれ、どうやるかは任せる」 Developerの夢を詠んだもの、らしい。 当時PivotalにいたOnsi Fakhouri氏によるもの。Cloud Foundryが目指していた 方向性が垣間見えて良い いまここ
29. 課題
30. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 PaaSのデプロイと運用どうすんねん問題 • Open PaaS特有の問題 • PaaS自体もソフトウェアの集合体 なので、それらコンポーネントを 数十台のVMにデプロイする必要が ある。 • chefやpuppet、capistranoでなん とかしているケースが多かった • 今でいうとKubernetes the hard wayを毎回やるみたいな感じ いまここ
31. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 BOSHというアプローチ • Cloud Foundry陣営がとった アプローチがBOSH • PaaSを「リリースエンジニアリング」 する仕組み • GoogleのBorgの思想が根底 ◦ 同じ思想を持つKubernetesを イメージすると分かりやすい • イメージとマニフェストをBOSHに渡 すと、コンテナではなくVMを立ち上げ てくれる いまここ https://speakerdeck.com/ozzozz/bosh-101-winter-2018
32. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 データベースどうすんねん問題 • 1コマンドでWebアプリがデプロイ出来 るのはいいが、じゃあデータベースは どうする？ • SoEとSoRではライフサイクルやスト レージへの要求が異なるので、同じプ ラットフォームで動かすには注意を要 する • 今でこそk8sで「動かすことはできる」 が、当時はそもそも動かすこともでき なかった • 2024年現在でも完全に解消したとは言 えない問題 いまここ Railsアプリは 簡単に動かせる Railsが使うDBは どうする?
33. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 妥協案 • プロビジョニングはいったん置いとい て、アプリケーションに対してDBへの 接続情報を渡すインターフェースが模 索された • PaaS上でアプリとDBを論理的にバイン ディングすると、DBの接続情報が環境 変数を通じて渡されるように。 • DBの種類によらず、きまった環境変数 を読めばアプリはDBに接続ができる。 • CFだけでなく、だいたいのPaaSが類似 の機能を備えていた いまここ 環境変数の注入 • DB Host • DB Database • DB User • DB Pass cf bind-service
34. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Service Brokerのアプローチ • DBなどのプロビジョニングや、アプリ ケーションへのバインディングなどを行 うために標準化を目指したアプローチが Service Broker • APIが定義され、さまざまなサービスを プロビジョニングできるようになった。 • 実体をどうプロビジョニングするかは Brokerの実装に委ねられる。 ◦ マネージドRDBを作りにいく実装 ◦ BOSHでVMから立ち上げる実装 ◦ 既存のDBインスタンスにデータベースを 作成するマルチテナント型など いまここ cf create-service MySQL Service Broker プロビジョニング リクエスト 接続情報 Service Broker API
35. 2014年 転機の年
36. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CF輪読会はPaaS勉強会へ • 2014年の第19回からPaaS勉強会に 改名 ◦ CF以外にも、さまざまなPaaSが出てき て盛り上がってきた ◦ paas.jp という使い勝手のいいドメイン が取れた いまここ
37. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 全てをひっくり返したk8s • 2014年6月にKubernetesが登場。すべて のOpen PaaSにとって、これが転機に • 9月の第20回でKubernetesの解説をした (日本で最初のk8s勉強会) • 当初は「Dockerをクラスタリングするも の」くらいの認識だったが、次第に主従が 逆転するほどに いまここ
38. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 OpenShiftの大転換 • OpenShift v3からKubernetesベース に生まれ変わる • それまでは目立たない存在だったが、 一気に話題の中心に • 第22回でOpenShiftスペシャルを開催 いまここ
39. なぜk8sがPaaSに影響したか
40. 一般的なPaaSのしくみ push push あとはPaaSがいい感じにしてくれる 開発者 エンド ユーザー PaaSのいいところは、抽象化により開発者がインフラ周 りを意識しなくても良い感じにやってくれることです。 このブラックボックスの中身はどうなっているのでしょ うか
41. 一般的なPaaSのしくみ API Server Builder push push polling request だいたいどのPaaSもアーキテクチャは似ています。 開発者がコードをPaaSにPushするパターンと、PaaSがリ ポジトリをPollingするパターンがありますが、いずれに せよBuilderというアーティファクトを作る仕組みが動き ます
42. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Builderはデプロイされたアプリケーションを解析し、そ れぞれ適した仕組みでビルドを行います。そして、成果 物をレジストリに補完します
43. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner ビルド後、オーケストレーターがPaaS内のコンピュー ティングノードに対してアプリの配置を行います。その 際に使われるのは、先ほどのアーティファクトです。
44. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner Router エンド ユーザー エンドユーザーからのアクセスはRouterコンポーネント がリクエストごとに適したアプリにルーティングを行い ます。この仕組みにより、複数アプリが同居するマルチ テナントが実現できます
45. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner Router Log aggregator AuthN/AuthZ Service Broker エンド ユーザー あとはログ収集や認証/認可、サービスバインディングの 仕組みなどを揃えれば、PaaSのできあがり。
46. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner Router Log aggregator AuthN/AuthZ Service Broker エンド ユーザー この仕組み、BuilderやレジストリをDockerに、オーケス トレーターやRouterをKubernetesにすれば、独自実装し なくても済んじゃうわけです
47. 一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の ・言語 ・FW ・サーバー かを検出 ・パッケージ マネージャの実行 ・ビルド ・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner Router Log aggregator AuthN/AuthZ Service Broker エンド ユーザー その他付随機能もk8sのPodとして立ち上げるようにすれ ば、全ての仕組みをk8sで実現できちゃいますね。
48. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 K8s + α = PaaS • k8sはPaaSではないが、PaaSが必要とする要素の多くをカバーできた • 安定したk8sさえあればその上に諸々インストールしてしまえばPaaSが実現 する • PaaS自体のセットアップもyamlやHelm chart入れるだけでいいので楽 ⇨ 多くのOpen PaaSがk8sを前提とするように変わっていった ⇨ この頃から、PaaSと呼称するプロダクトが減り始めた いまここ
49. Serverlessの流れ
50. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Lambdaの登場 • 2014年にAWS Lambdaが登場した • PaaSではなく、言うなればFaaS(Function as a Service) • PaaS勉強会で取り上げたことはないが、Open PaaSの流れに大きく影響した (と、個人的には思っている) いまここ https://aws.amazon.com/jp/serverless/patterns/serverless-pattern/
51. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 パブリッククラウドにしかない価値 • Lambdaですごいと思うのは、AWSの価値を最大限に生かせること • ただのIaaSやオンプレでも、Function単位でワークロードを実行するのは可 能。Scale to Zeroも可能 • でも、API GatewayやDynamoDB、S3、SQSなどを組み合わせた 「サーバーレスアーキテクチャ」は、どうやってもマネできない • S3のようなすごいテクノロジーや、IAMのような確固たる地盤があって初め て実現する世界 • 一度この世界にハマれば、Open PaaSを使うメリットは無くなる • クラウドへの流れを決定づけたプロダクト いまここ
52. Microservicesの流れ
53. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 マイクロサービスの時代 • 2014年、Thoughtworksのマーチン・ファウラーとジェームス・ルイスに よって、マイクロサービスアーキテクチャが提唱された • サービスを細かく分割し、それぞれがコミュニケーションする形で動く • 組織も、ソフトウェアもスケール可能にする思想 • ソフトウェアの規模が大きくなるにつれ、そうしないと回らないケースが出 てきた いまここ
54. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 マイクロサービスの時代 一方、それまでのPaaSはRuby on Railsに強く影響されていた • HerokuはRubyのPaaSだった • Cloud Foundryも最初からRoRをサポート • RoRのConvention over Configuration（設定よりも規約）という思想は PaaSのようなOpinionated(制約の強い)な仕組みと相性が良い 決められたレールにアプリケーションもプラットフォームも載ることで、アジャイ ル開発とDevOpsをうまく回していこうという発想 いまここ
55. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 マイクロサービスの時代 • PaaSとマイクロサービスの相性が悪いとまでは言わないが、色々足りていな かった ◦ サービス間の関係性の表現 ◦ ネットワーク的な制限 ◦ 最適なライフサイクルの違い Frontend BFF Backend A Backend B KVS DB Backend C Auth いまここ
56. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 マイクロサービスの時代 • 複雑なマイクロサービスアーキテクチャをPaaSで個別にPushするより、 レジストリに入っているコンテナイメージを使って、同じManifestでApply 先を変えれば複数環境で同じ物を再現できる Frontend BFF Backend A Backend B KVS DB Backend C Auth Frontend BFF Backend A Backend B KVS DB Backend C Auth Frontend BFF Backend A Backend B KVS DB Backend C Auth いまここ
57. 2015年- 多様化
58. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 IoTがやってきた いまここ このころ、IoTが注目されはじめた PaaS勉強会のメンバーの中にIBMの方がいて、 ビジュアルプログラミングツールのNode-RED の登壇をしたいと打診があったのでNode-RED 回を開催。 その後、IBM BlueMixのユーザー会 BMXUGと 共催でNode-RED LT祭を開催。 登壇者の方々は、Node-RED User Group Japanとして現在も活動されています https://nodered.jp/
59. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げました いまここ
60. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げました いまここ ものすごくエンタープライズな PaaS、OneOpsの話 https://speakerdeck.com/jacopen/mofalsesugokuentapuraizunapaas-oneopsfalsehua
61. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げました いまここ
62. 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げました いまここ
63. 2018年 Platform for Platforms
65. Platformを作るためのPlatformとしてのk8s 2016年から2017年ごろにかけて、Kubernetesを拡張するための実装が始めた。 はじめはThird Party Resourcesとして実装され、その後Custom Resource Definitionsに作り替えられた。 これにより外部からリソースの定義を持ち込み、標準のリソースと同じように宣言 的に管理できるようになった。 これまで各PaaSが独自に作り込んでいた抽象化を、Kuberenetsの上で表現しやす くなった。この機能の実装を積極的に進めていたRed Hatは、これを活用して OpenShiftの機能をどんどん強化していった
66. Service Broker vs Custom Resource 先ほど説明したService Brokerも、カスタムリソースを使えば同じことを実現できる cf create-service MySQL Service Broker プロビジョニング リクエスト 接続情報 Service Broker API kubectl apply Custom Controller プロビジョニング Custom Resource Definition
67. Knative 2018年の7月にKnativeが登場。 KubernetesでServerlessかつEvent Drivenのアプリケーションを実現する ための仕組みとして登場した。 CRDがガッツリと利用されており、 Building BlockとしてのKuberenetsの 強さが存分に活かされた仕組みになって いた
68. 認知負荷との戦い
69. 認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用
70. 2021年 Platform Engineering
71. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
72. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
73. 開発者の認知負荷を軽減し生産性を向上させる共通基盤 Golden Path Internal Developer Portal Internal Developer Platform
74. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
75. 『正しい』とは何か • 絶対的な正解はない。 • 開発者の認知負荷を軽減し生産性を向上させる共通基盤 ◦ これを実現するための技術、規模、チームは 会社によって全く異なる ◦ 同じ組織であっても、状況の変化や時間経過で 正解は変わりうる • 正解が変わり続けることを前提に考えることが重要
76. こういうのは『正しい』？ • 開発者の認知負荷増大が課題となっている • 開発者は運用側との調整に時間が取られ、本来の業務に 注力できていない • そこで、セルフサービスでワークロードをデプロイできる Kubernetes環境を提供する • また、CI/CD環境を提供し、各オペレーションの 自動化を実現する • これをプラットフォームとして提供し、 ビジネスのアジリティ向上に貢献する
77. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？
78. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？ いやこれがこれからの デファクトスタンダードなんだよ つかえよ
79. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？ いやこれがこれからの デファクトスタンダードなんだよ つかえよ 使われるわけがない
80. 誰に 何を どうやって 失敗するプラットフォームは ここばかり気にする
81. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること これを継続的に回せること
82. Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
83. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
84. 13年間、ありがとうございました👋