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

Findy主催のイベント「なぜ話題？Platform Engineering最前線 〜いま注目を浴びている理由とは〜」
https://findy.connpass.com/event/298961/
でお話しした資料です

Transcript

1. 技術の洪水に立ち向かう: 開発者の心を軽くするプラット フォームエンジニアリングの話
2. Kazuto Kusama @jacopen Senior Solutions Engineer @HashiCorp Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Tech Strategy Advisor @PITTAN
3. 今日のセッションについて • どちらかといえば、フロントエンドやバックエンドなどの 開発者に向けた発表です • あとでQ&Aの時間もあります。 率直な感想や普段の仕事の悩みなど聞かせてください！
4. About me • HashiCorpという会社で、TerraformやVaultと いったクラウドの自動化やセキュリティに関わる プロダクトのソリューションエンジニア • 通信事業者でPaaSの開発⇒ Pivotal / VMwareでPaaSプロダクトのプロフェッ ショナルサービス⇒ 現職 • CloudNative Daysをはじめとした、クラウドネイ ティブ技術に関するコミュニティ運営や情報発信 なので、基本的にはプラットフォーム側の人間です
5. でもたまにアプリを書くことも CloudNative Days 独自イベントプラットフォーム Dreamkast 汗中成分分析サービスによる インナーケアアシスト PITTAN
6. アプリを作っていて思うこと この開発したアプリをAWSに デプロイしないといけないけど･･･ クラウドくっそめんどくさい！ こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア
7. • クラウドやコンテナの知識は持ち合わせている • でも、アプリを書いているときは、頭の中は開発モード • 開発モードからクラウドエンジニアモードに頭を切り替えるのは くっそめんどくさい • クラウドエンジニアモードから開発モードに戻すのも くっそめんどくさい • めんどくさすぎて嫌になって現実逃避で1時間くらい スイカゲームやっちゃう アプリを作っているときは
8. くっそめんどくさい！
9. くっそめんどくさい！
10. • デプロイするためのDockerfile書き、imageづくり • Manifest書き • CI/CDパイプライン作成 • 認証基盤との連携 ◦ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ • ロギング、モニタリングの設定 • セキュリティスキャン • etc… アプリをデプロイしたいだけなのにやるべきことが多い！ みなさんも、くっそめんどくさい 経験ありませんか？
11. くっそめんどくさい！ の表現を専門用語にすると 認知負荷
12. https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷の増大が問題に クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに
13. くっそめんどくさい！は 気のせいではなく あちこちで発生している差し迫った課題
14. ちなみに認知負荷をもうすこし細かく言うと 教育心理学の方面で生まれた概念 • 課題内在性負荷 ◦ 情報自体の難度の高さが与える負荷 • 課題外在性負荷 ◦ 外的要因によって引き起こされる負荷 • 学習関連負荷 ◦ 学習に役立つ方法で人が情報を処理するときに生じる負荷
15. おすすめ記事 最近書かれたこちらの記事が最高に 分かりやすかったです 認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解する ための心理学研究・知見の紹介 https://zenn.dev/kangetsu_121/articl es/6b31565dda6053
16. 認知負荷の増大による生産性の低下が 無視出来なくなりつつある
17. じゃあ、どうすればいいのか
18. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい
19. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 開発者側からみたPlatform Engineeringの理解は、この程度でいいと思います
20. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい どうお願いするのか。その任せ方、関わり方 教えを請う？ 手伝って貰う？ それとも･･･
21. Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。
22. 4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチー ム。ビジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱う チーム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける 支援をするチーム ★Platform team インフラやツール、共通サービスなどのプラッ トフォームを提供するチーム
23. 3つのインタラクションモード ファシリテーション 一方のチームが他のチームの障害を取り除くた めに支援をしたり、支援されたりする。同時に 複数のチームと連携することもある コラボレーション 2つのチームが密接に協力して作業する。同時に コラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利 用する関係性。責任分界点が明確。疎結合。
24. その道のプロ(= Platform Team)との関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
25. その道のプロとの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発 最終的にはここを目指す この過程も大事
26. Platform EngineeringとTeam Topologies • 価値のあるソフトウェアを素早く届けられるチームの在り方について 視点を提供してくれるのがTeam Topologies • Team Topologiesに沿って、開発者のくっそめんどくさいポイントを良くし てくれるのがPlatform Team • あらゆる技術に精通することは難しい&ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく。 • 最終的にはスケールするX-as-a-Serviceのインタラクションを目指すが、そ の過程でファシリテーションやコラボレーションを行うこともある
27. Platform Teamが担うこと • 開発者の認知負荷軽減を一番の目的として取り組む • 開発の助けになるような情報を整理する • あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく • スムーズに取り組めるようオンボーディングの仕組みをととのえる • 必要に応じて勉強会やワークショップの開催を行う • 開発者からの質問や問い合わせに対して対応する • 開発者がセルフサービスで利用できる、自動化されたプラットフォーム を作っていく
28. Platform Teamが担うこと • 開発者の認知負荷軽減を一番の目的として取り組む • 開発の助けになるような情報を整理する • あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく • スムーズに取り組めるようオンボーディングの仕組みをととのえる • 必要に応じて勉強会やワークショップの開催を行う • 開発者からの質問や問い合わせに対して対応する • 開発者がセルフサービスで利用できる、自動化されたプラットフォーム を作っていく 世間のPlatform Engineering評はこればっかり出てくる
29. Platform Teamが担うこと • 開発者の認知負荷軽減を一番の目的として取り組む • 開発の助けになるような情報を整理する • あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく • スムーズに取り組めるようオンボーディングの仕組みをととのえる • 必要に応じて勉強会やワークショップの開催を行う • 開発者からの質問や問い合わせに対して対応する • 開発者がセルフサービスで利用できる、自動化されたプラットフォーム を作っていく 真に重要なのはこっち
30. 想像してみてください
31. もしその道のプロがこんなんだったら･･･ 今のデプロイパイプラインどうなってます？ え、CIツール でUnit Test回してるだけ？ やだなー、今はDevOpsの時代ですよ。 常識的に考えてCDまでやるべきでしょ。手作業入るのマジ イケてないっす。仕方ないなぁ、教えてあげますよ
32. もしその道のプロがこんなんだったら･･･ 生産性が課題なんですか？ じゃあコンテナですね。え、、 まだコンテナ使ってないんですか？ そうかぁ、でも今時 Kubernetesでアプリ動かすのなんて常識ですよ。 ほら、ここにKubernetes環境ありますから。Buildkitでイ メージデプロイして社内のHarborにpushしといてください ねデプロイはArgoCD上がってますんでGitOpsしてくださ いDBはOperator入れてあるんでそれ使ってなんとかしてく ださいサービスメッシュとしてIstio使えるんで
33. うるせぇ
34. 使われないプラットフォーム • 極端な表現をしているけれど、これまでの (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいなやつは、こういう思想な運用が多かった ◦ これが元で、共通プラットフォーム的なものに嫌悪感を抱く人もいる • でも、これじゃぁ使われない
35. 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang
36. 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang
37. 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang
38. 価値とは 『誰にとっての価値か』が大事 プラットフォームにとって、価値があるかないか判断をするのは 『プラットフォームの利用者』 つまり 『開発者』 開発者に価値を提供できなければ、そのプラットフォームは失敗している
39. 上手くいくプラットフォーム作りは、本当に難しい • 4割の共通プラットフォームは、生まれながらに死んでいる • 4割の共通プラットフォームは、上手く運用出来ずに死んでいく • 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)
40. 反省 自分もこういうプラットフォーム作りをしていた時期があった
41. 誰に 何を どうやって
42. 誰に 何を どうやって 失敗するプラットフォームは ここばかり気にする
43. どうやって 時代はマイクロサービスでしょ VMは古い。今はコンテナ 全社統一のセキュリティ コ ンプライアンス基準を リソースの利用率を向上さ せてコスト削減 コンテナ Kubernetes サービス メッシュ 分散トレー シング オブザーバ ビリティ
44. どうやって 時代はマイクロサービスでしょ VMは古い。今はコンテナ 全社統一のセキュリティ コ ンプライアンス基準を リソースの利用率を向上さ せてコスト削減 コンテナ Kubernetes サービス メッシュ 分散トレー シング オブザーバ ビリティ Developer 別にコンテナにしなくても困っ てないし、マイクロサービスに するフェーズじゃないし･･･ セキュリティも、どうせあとで チェックシート記入求められる んでしょ
45. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること これを継続的に回せること
46. Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
47. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
48. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー プロダクトマネジメントの 手法がそのまま使える。 チームに専任のプロダクトマ ネージャーを置き、プロダク トとしてのプラットフォーム の方向性を決めていく
49. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、MVP(Minimum Viable Product)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
50. 今までとこれから 開発者 プラットフォームチーム Platform 押しつけ 開発者 技術の洪水 Platform Portal Tools X-as-a-Service Collaboration Facilitation 立ち向かう 生産性を高める⤴
51. Platform Teamと一緒に 生産性を高めていきませんか？