技術の洪水に立ち向かう: 開発者の心を軽くするプラットフォームエンジニアリングの話

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Senior Solutions Engineer @HashiCorp Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Tech Strategy Advisor @PITTAN

Slide 3

Slide 3 text

今日のセッションについて ● どちらかといえば、フロントエンドやバックエンドなどの開発者に向けた発表です ● あとでQ&Aの時間もあります。率直な感想や普段の仕事の悩みなど聞かせてください！

Slide 4

Slide 4 text

About me ● HashiCorpという会社で、TerraformやVaultといったクラウドの自動化やセキュリティに関わるプロダクトのソリューションエンジニア ● 通信事業者でPaaSの開発⇒ Pivotal / VMwareでPaaSプロダクトのプロフェッショナルサービス⇒ 現職 ● CloudNative Daysをはじめとした、クラウドネイティブ技術に関するコミュニティ運営や情報発信なので、基本的にはプラットフォーム側の人間です

Slide 5

Slide 5 text

でもたまにアプリを書くことも CloudNative Days 独自イベントプラットフォーム Dreamkast 汗中成分分析サービスによるインナーケアアシスト PITTAN

Slide 6

Slide 6 text

アプリを作っていて思うことこの開発したアプリをAWSにデプロイしないといけないけど･･･クラウドくっそめんどくさい！こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア

Slide 7

Slide 7 text

● クラウドやコンテナの知識は持ち合わせている ● でも、アプリを書いているときは、頭の中は開発モード ● 開発モードからクラウドエンジニアモードに頭を切り替えるのはくっそめんどくさい ● クラウドエンジニアモードから開発モードに戻すのもくっそめんどくさい ● めんどくさすぎて嫌になって現実逃避で1時間くらいスイカゲームやっちゃうアプリを作っているときは

Slide 8

Slide 8 text

くっそめんどくさい！

Slide 9

Slide 9 text

くっそめんどくさい！

Slide 10

Slide 10 text

● デプロイするためのDockerﬁle書き、imageづくり ● Manifest書き ● CI/CDパイプライン作成 ● 認証基盤との連携 ○ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ ● ロギング、モニタリングの設定 ● セキュリティスキャン ● etc… アプリをデプロイしたいだけなのにやるべきことが多い！みなさんも、くっそめんどくさい経験ありませんか？

Slide 11

Slide 11 text

くっそめんどくさい！の表現を専門用語にすると認知負荷

Slide 12

Slide 12 text

https://www.infoq.com/articles/platform-engineering-primer/ より引用認知負荷の増大が問題にクラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、エンジニアの責任範囲の拡大により認知負荷が大変なことに

Slide 13

Slide 13 text

くっそめんどくさい！は気のせいではなくあちこちで発生している差し迫った課題

Slide 14

Slide 14 text

ちなみに認知負荷をもうすこし細かく言うと教育心理学の方面で生まれた概念 ● 課題内在性負荷 ○ 情報自体の難度の高さが与える負荷 ● 課題外在性負荷 ○ 外的要因によって引き起こされる負荷 ● 学習関連負荷 ○ 学習に役立つ方法で人が情報を処理するときに生じる負荷

Slide 15

Slide 15 text

おすすめ記事最近書かれたこちらの記事が最高に分かりやすかったです認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介 https://zenn.dev/kangetsu_121/articl es/6b31565dda6053

Slide 16

Slide 16 text

認知負荷の増大による生産性の低下が無視出来なくなりつつある

Slide 17

Slide 17 text

じゃあ、どうすればいいのか

Slide 18

Slide 18 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたい

Slide 19

Slide 19 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいその道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 開発者側からみたPlatform Engineeringの理解は、この程度でいいと思います

Slide 20

Slide 20 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいどうお願いするのか。その任せ方、関わり方教えを請う？手伝って貰う？それとも･･･

Slide 21

Slide 21 text

Team Topologies 価値のあるソフトウェアを素早く届けられるようにするための組織設計。 4タイプのチーム定義と、3つのインタラクションモードが定義されている。

Slide 22

Slide 22 text

4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチーム。ビジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱うチーム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける支援をするチーム ★Platform team インフラやツール、共通サービスなどのプラットフォームを提供するチーム

Slide 23

Slide 23 text

3つのインタラクションモードファシリテーション一方のチームが他のチームの障害を取り除くために支援をしたり、支援されたりする。同時に複数のチームと連携することもあるコラボレーション 2つのチームが密接に協力して作業する。同時にコラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利用する関係性。責任分界点が明確。疎結合。

Slide 24

Slide 24 text

その道のプロ(= Platform Team)との関わり方開発チームその道のプロ開発チームその道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を開いたり、Slackで情報提供その道のプロが開発チームにジョインし Manifest書くのを担う開発チームその道のプロ XaaS その道のプロが用意したプラットフォームのレールの上で開発

Slide 25

Slide 25 text

その道のプロとの関わり方開発チームその道のプロ開発チームその道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を開いたり、Slackで情報提供その道のプロが開発チームにジョインし Manifest書くのを担う開発チームその道のプロ XaaS その道のプロが用意したプラットフォームのレールの上で開発最終的にはここを目指すこの過程も大事

Slide 26

Slide 26 text

Platform EngineeringとTeam Topologies ● 価値のあるソフトウェアを素早く届けられるチームの在り方について視点を提供してくれるのがTeam Topologies ● Team Topologiesに沿って、開発者のくっそめんどくさいポイントを良くしてくれるのがPlatform Team ● あらゆる技術に精通することは難しい&ガバナンスを効かせていく必要もあるので、Platform Teamは技術の『標準』を定めていく。 ● 最終的にはスケールするX-as-a-Serviceのインタラクションを目指すが、その過程でファシリテーションやコラボレーションを行うこともある

Slide 27

Slide 27 text

Platform Teamが担うこと ● 開発者の認知負荷軽減を一番の目的として取り組む ● 開発の助けになるような情報を整理する ● あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあるので、Platform Teamは技術の『標準』を定めていく ● スムーズに取り組めるようオンボーディングの仕組みをととのえる ● 必要に応じて勉強会やワークショップの開催を行う ● 開発者からの質問や問い合わせに対して対応する ● 開発者がセルフサービスで利用できる、自動化されたプラットフォームを作っていく

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

想像してみてください

Slide 31

Slide 31 text

もしその道のプロがこんなんだったら･･･今のデプロイパイプラインどうなってます？え、CIツールでUnit Test回してるだけ？やだなー、今はDevOpsの時代ですよ。常識的に考えてCDまでやるべきでしょ。手作業入るのマジイケてないっす。仕方ないなぁ、教えてあげますよ

Slide 32

Slide 32 text

もしその道のプロがこんなんだったら･･･生産性が課題なんですか？じゃあコンテナですね。え、、まだコンテナ使ってないんですか？そうかぁ、でも今時 Kubernetesでアプリ動かすのなんて常識ですよ。ほら、ここにKubernetes環境ありますから。Buildkitでイメージデプロイして社内のHarborにpushしといてくださいねデプロイはArgoCD上がってますんでGitOpsしてくださいDBはOperator入れてあるんでそれ使ってなんとかしてくださいサービスメッシュとしてIstio使えるんで

Slide 33

Slide 33 text

うるせぇ

Slide 34

Slide 34 text

使われないプラットフォーム ● 極端な表現をしているけれど、これまでの (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいなやつは、こういう思想な運用が多かった ○ これが元で、共通プラットフォーム的なものに嫌悪感を抱く人もいる ● でも、これじゃぁ使われない

Slide 35

Slide 35 text

役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

価値とは『誰にとっての価値か』が大事プラットフォームにとって、価値があるかないか判断をするのは『プラットフォームの利用者』つまり『開発者』開発者に価値を提供できなければ、そのプラットフォームは失敗している

Slide 39

Slide 39 text

上手くいくプラットフォーム作りは、本当に難しい ● 4割の共通プラットフォームは、生まれながらに死んでいる ● 4割の共通プラットフォームは、上手く運用出来ずに死んでいく ● 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)

Slide 40

Slide 40 text

反省自分もこういうプラットフォーム作りをしていた時期があった

Slide 41

Slide 41 text

誰に何をどうやって

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

どうやって時代はマイクロサービスでしょ VMは古い。今はコンテナ全社統一のセキュリティコンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナ Kubernetes サービスメッシュ分散トレーシングオブザーバビリティ

Slide 44

Slide 44 text

どうやって時代はマイクロサービスでしょ VMは古い。今はコンテナ全社統一のセキュリティコンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナ Kubernetes サービスメッシュ分散トレーシングオブザーバビリティ Developer 別にコンテナにしなくても困ってないし、マイクロサービスにするフェーズじゃないし･･･セキュリティも、どうせあとでチェックシート記入求められるんでしょ

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャープロダクトマネジメントの手法がそのまま使える。チームに専任のプロダクトマネージャーを置き、プロダクトとしてのプラットフォームの方向性を決めていく

Slide 49

Slide 49 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャー ● プラットフォームが最も達成したい指標は何か ○ North Star Metricsの策定 ● 顧客は何にペインを感じているのか ○ ユーザーヒアリング ● 最も重要なものから実現し、MVP(Minimum Viable Product)を作る ○ 実装する機能の優先順位付け ● 社内にその存在を知ってもらう ○ ブランディング、社内マーケティング

Slide 50

Slide 50 text

今までとこれから開発者プラットフォームチーム Platform 押しつけ開発者技術の洪水 Platform Portal Tools X-as-a-Service Collaboration Facilitation 立ち向かう生産性を高める⤴

Slide 51

Slide 51 text

Platform Teamと一緒に生産性を高めていきませんか？