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

by Kazuto Kusama

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association

Slide 3

Slide 3 text

PaaS勉強会最終回👋

Slide 4

Slide 4 text

PaaS勉強会一区切りつけます ● Slack workspaceは6月末で閉鎖します ● Connpassは残します ○ 過去の登壇者のスライドもあるため ● YouTubeチャンネルも残します区切りは付けつつも、「かつてそういうイベントがあった」という記録は残したい

Slide 5

Slide 5 text

なぜ区切りをつけるの？ ● PaaSを取り巻く環境が大きく変わった ○ 今日のセッションを通じてこのあたりを語ります ● 全てを残して放置という選択肢もあった ○ 世の中のコミュニティの99%はこのような自然消滅 ○ コロナ禍で活動が戻りつつあるが、そのまま消滅してしまうコミュニティも多い ● こういう時代だからこそ、きっちり終わらせたかった ○ Platformを取り巻く変化は、総じてポジティブ ○ 明示的に区切りをつけることで、新しい流れに引き継ぎたい ○ 自分が関与したはじめての技術コミュニティなので、見送るところまでやりたい

Slide 6

Slide 6 text

2007年 PaaSのはじまり

Slide 7

Slide 7 text

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/

Slide 8

Slide 8 text

2009年 DevOps

Slide 9

Slide 9 text

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年) いまここ

Slide 10

Slide 10 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 アプリを簡単にデプロイしたい。運用も任せたい。 DevOpsはアジャイル開発の思想をOpsレイヤーにも取り込んでいくことになる。アジャイルに開発して素早くリリースしたい ⇨　簡単にアプリをデプロイ・運用できるプラットフォームが必要 ⇨　Application Platformの必要性が高まるいまここ

Slide 11

Slide 11 text

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に買収されるいまここ

Slide 12

Slide 12 text

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に感銘をうけてこの業界に入ってきたいまここ

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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の表現は使っている様子。いまここ

Slide 15

Slide 15 text

2011年 Open PaaSの登場

Slide 16

Slide 16 text

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を中心に据えたアーキテクチャだった。この後十数年に渡って進化していき、今のアーキテクチャは全く別物になっている、いまここ

Slide 17

Slide 17 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Cloud Foundryの登場 Cloud Foundryを使ったアプリのデプロイいまここソースコードがあるディレクトリで cf push とするだけ

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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自体の運用もしないといけない運用

Slide 21

Slide 21 text

2012年国内での商用PaaS

Slide 22

Slide 22 text

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) いまここ

Slide 23

Slide 23 text

2013年 Dockerの登場

Slide 24

Slide 24 text

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になるほど。いまここ

Slide 25

Slide 25 text

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はエポックメイキングだったいまここ

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

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が目指していた方向性が垣間見えて良いいまここ

Slide 29

Slide 29 text

課題

Slide 30

Slide 30 text

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を毎回やるみたいな感じいまここ

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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はどうする?

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

2014年転機の年

Slide 36

Slide 36 text

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 という使い勝手のいいドメインが取れたいまここ

Slide 37

Slide 37 text

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をクラスタリングするもの」くらいの認識だったが、次第に主従が逆転するほどにいまここ

Slide 38

Slide 38 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 OpenShiftの大転換 ● OpenShift v3からKubernetesベースに生まれ変わる ● それまでは目立たない存在だったが、一気に話題の中心に ● 第22回でOpenShiftスペシャルを開催いまここ

Slide 39

Slide 39 text

なぜk8sがPaaSに影響したか

Slide 40

Slide 40 text

一般的なPaaSのしくみ push push あとはPaaSがいい感じにしてくれる開発者エンドユーザー PaaSのいいところは、抽象化により開発者がインフラ周りを意識しなくても良い感じにやってくれることです。このブラックボックスの中身はどうなっているのでしょうか

Slide 41

Slide 41 text

一般的なPaaSのしくみ API Server Builder push push polling request だいたいどのPaaSもアーキテクチャは似ています。開発者がコードをPaaSにPushするパターンと、PaaSがリポジトリをPollingするパターンがありますが、いずれにせよBuilderというアーティファクトを作る仕組みが動きます

Slide 42

Slide 42 text

一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の・言語・FW ・サーバーかを検出・パッケージマネージャの実行・ビルド・イメージ作成 Artifact Registry Builderはデプロイされたアプリケーションを解析し、それぞれ適した仕組みでビルドを行います。そして、成果物をレジストリに補完します

Slide 43

Slide 43 text

一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の・言語・FW ・サーバーかを検出・パッケージマネージャの実行・ビルド・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner ビルド後、オーケストレーターがPaaS内のコンピューティングノードに対してアプリの配置を行います。その際に使われるのは、先ほどのアーティファクトです。

Slide 44

Slide 44 text

一般的なPaaSのしくみ API Server Builder push push polling request Detect Build Release 何の・言語・FW ・サーバーかを検出・パッケージマネージャの実行・ビルド・イメージ作成 Artifact Registry Orchestrator Runner Runner Runner Router エンドユーザーエンドユーザーからのアクセスはRouterコンポーネントがリクエストごとに適したアプリにルーティングを行います。この仕組みにより、複数アプリが同居するマルチテナントが実現できます

Slide 45

Slide 45 text

一般的な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のできあがり。

Slide 46

Slide 46 text

一般的な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にすれば、独自実装しなくても済んじゃうわけです

Slide 47

Slide 47 text

一般的な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で実現できちゃいますね。

Slide 48

Slide 48 text

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と呼称するプロダクトが減り始めたいまここ

Slide 49

Slide 49 text

Serverlessの流れ

Slide 50

Slide 50 text

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/

Slide 51

Slide 51 text

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を使うメリットは無くなる ● クラウドへの流れを決定づけたプロダクトいまここ

Slide 52

Slide 52 text

Microservicesの流れ

Slide 53

Slide 53 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 マイクロサービスの時代 ● 2014年、Thoughtworksのマーチン・ファウラーとジェームス・ルイスによって、マイクロサービスアーキテクチャが提唱された ● サービスを細かく分割し、それぞれがコミュニケーションする形で動く ● 組織も、ソフトウェアもスケール可能にする思想 ● ソフトウェアの規模が大きくなるにつれ、そうしないと回らないケースが出てきたいまここ

Slide 54

Slide 54 text

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 Conﬁguration（設定よりも規約）という思想は PaaSのようなOpinionated(制約の強い)な仕組みと相性が良い決められたレールにアプリケーションもプラットフォームも載ることで、アジャイル開発とDevOpsをうまく回していこうという発想いまここ

Slide 55

Slide 55 text

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 いまここ

Slide 56

Slide 56 text

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 いまここ

Slide 57

Slide 57 text

2015年- 多様化

Slide 58

Slide 58 text

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/

Slide 59

Slide 59 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げましたいまここ

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げましたいまここ

Slide 62

Slide 62 text

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 いろんなものを取り上げましたいまここ

Slide 63

Slide 63 text

2018年 Platform for Platforms

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Platformを作るためのPlatformとしてのk8s 2016年から2017年ごろにかけて、Kubernetesを拡張するための実装が始めた。はじめはThird Party Resourcesとして実装され、その後Custom Resource Deﬁnitionsに作り替えられた。これにより外部からリソースの定義を持ち込み、標準のリソースと同じように宣言的に管理できるようになった。これまで各PaaSが独自に作り込んでいた抽象化を、Kuberenetsの上で表現しやすくなった。この機能の実装を積極的に進めていたRed Hatは、これを活用して OpenShiftの機能をどんどん強化していった

Slide 66

Slide 66 text

Service Broker vs Custom Resource 先ほど説明したService Brokerも、カスタムリソースを使えば同じことを実現できる cf create-service MySQL Service Broker プロビジョニングリクエスト接続情報 Service Broker API kubectl apply Custom Controller プロビジョニング Custom Resource Deﬁnition

Slide 67

Slide 67 text

Knative 2018年の7月にKnativeが登場。 KubernetesでServerlessかつEvent Drivenのアプリケーションを実現するための仕組みとして登場した。 CRDがガッツリと利用されており、 Building BlockとしてのKuberenetsの強さが存分に活かされた仕組みになっていた

Slide 68

Slide 68 text

認知負荷との戦い

Slide 69

Slide 69 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用

Slide 70

Slide 70 text

2021年 Platform Engineering

Slide 71

Slide 71 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 72

Slide 72 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 73

Slide 73 text

開発者の認知負荷を軽減し生産性を向上させる共通基盤 Golden Path Internal Developer Portal Internal Developer Platform

Slide 74

Slide 74 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 75

Slide 75 text

『正しい』とは何か ● 絶対的な正解はない。 ● 開発者の認知負荷を軽減し生産性を向上させる共通基盤 ○ これを実現するための技術、規模、チームは会社によって全く異なる ○ 同じ組織であっても、状況の変化や時間経過で正解は変わりうる ● 正解が変わり続けることを前提に考えることが重要

Slide 76

Slide 76 text

こういうのは『正しい』？ ● 開発者の認知負荷増大が課題となっている ● 開発者は運用側との調整に時間が取られ、本来の業務に注力できていない ● そこで、セルフサービスでワークロードをデプロイできる Kubernetes環境を提供する ● また、CI/CD環境を提供し、各オペレーションの自動化を実現する ● これをプラットフォームとして提供し、ビジネスのアジリティ向上に貢献する

Slide 77

Slide 77 text

『正しい』とは何か認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよオンプレはvSphereで、クラウドはServerlessで、特に課題感は無いんだけど？

Slide 78

Slide 78 text

『正しい』とは何か認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよオンプレはvSphereで、クラウドはServerlessで、特に課題感は無いんだけど？いやこれがこれからのデファクトスタンダードなんだよつかえよ

Slide 79

Slide 79 text

Slide 80

Slide 80 text

誰に何をどうやって失敗するプラットフォームはここばかり気にする

Slide 81

Slide 81 text

誰に何をどうやってプラットフォームの利用者 ○○という価値を技術ツールチェーンワークフローここにちゃんとフォーカスすることこれを継続的に回せること

Slide 82

Slide 82 text

Platform as a Product ● 開発者を『顧客』として考え、顧客にプラットフォームという『プロダクト』を提供していくというアプローチ ● 世の中に提供されているさまざまなプロダクトと同じ管理手法を、プラットフォームにも取り込んでいく顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチーム

Slide 83

Slide 83 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチームどういう価値を提供できれば使って貰えるか顧客が何に困っているかどうやってサポートしていくかどうやって教育していくかどうやって安定したチームを作るかプラットフォームによる効果がどのくらい出ているか何をいつまでに提供するか世の中のトレンドはどうなっているか

Slide 84

Slide 84 text

13年間、ありがとうございました👋