APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

【PlatformCon 2023】Platform Engineeringの最終ゴールのイメージ

PlatformCon 2023セッションブログ。今回は、これがPlatform Engineeringの最終ゴールなのかな、と感じたデモがあったセッションを2つご紹介します。

Platform as Code: Simplifying developer platform designs with refernce architectures.

最初はこちら。Platform Engineeringで標準化をする意義とそれをセルフサービスで提供するイメージです。 ここではシステム全体を標準化しそれをリファレンスアーキテクチャとしているようです。

platformcon.com

【概要】 低い開発者体験は組織の技術スタックとそこにいる人々に以下のようなマイナスのインパクトを与えます。

  • 低いプロダクティビティとイノベーションレベル
  • 開発者の認知負荷増大
  • Opsへの高い圧力や自動化の低レベル化
  • 複雑度の増大

エンジニアリングアプローチの標準化は開発体験やプロダクティビティを改善します。

  • エンジニアの振る舞いとして先進の業界プラクティスを適用して推進
  • セルフサービスの実現
  • 認知負荷の低減とシャドーオペレーションアンチパターンの削減
  • チーム間の摩擦やタスク引き渡しの削減
  • 技術スタックやツールチェーンの標準化

標準化が様々な点でチームや技術に寄与するというのは前の投稿でも登場しました。 techblog.ap-com.co.jp

ひとつのやり方として、まるまる1つのシステムのBlueprintを作り、それをセルフサービスでデプロイできるようにするという方法です。これにはBackstageやHumanitecなどさまざまなツールを組み合わせることで実現できます。 システム1つが実行できる状態でそのCloudインフラからアプリケーションバイナリまでデプロイされ、ソースコードまで提供されるため、開発者の認知負荷は低減され標準化も容易に実現できるようになります。

ここまで実現するために必要なものは技術だけではありません。 それを支える「基盤」、マインドセット、プロセス、そして技術者が使いたいと思うプラットフォーム技術といったものの組み合わせではじめて実現できるのです。

Platform engineering: From culture to practice

2つ目は Platform Engineeringの成熟度について整理したものです。 まず最初にPlatform Engineeringは次の2つを解決してくれるとしています。

  • 大きな組織においてDevOps原則のプラクティスを適用する方法
  • Team Topologiesを適用する手助け

(そうとう要求事項が高いですね)

platformcon.com

では成熟度別にPlatform Engineering teamの作り方を見ていきましょう

成熟度: 子供時代

BackstageのようなEngineering Portal(単純な開発者ポータル)から導入しましょう。

成熟度: 思春期

  • フロントエンド開発にStorybookなどを活用しましょう
  • バックエンドにはMicroservice、そしてオプションとしてMicrofrontendを採用します。
  • アプリケーションテンプレートを用意します。
  • CI/CDを導入し、DBの決定やテストツールの導入、モニタリングツールの導入を行います。

成熟度: 成熟期

  • 共通化やコンテナソリューションを提供します。
  • 汎用的な可観測ツールを提供します。
  • 更新のしやすさを実現します
  • 共通のセキュリティ/品質確認を実施します

Platform Teamを組成する場合に非常に重要なことは「エバンジェリストになること」です。

成熟度をみるとなんとなく分かる部分もありますが、Microserviceなどを考えるとちょっとハードル高めだなという印象もあります。普段自分がやりたいと言っている内容そのものでもあるので他のメンバーから「いつも言っていることと同じじゃない?」って突っ込まれそうです。

両者を見て感じたこと

「こんな感じでやればいいよ」というデモを紹介していますが、両者ともに実現するレベル高いなという印象です。 ある意味Platform Engineeringの最終形(または最初のゴール)はこんな世界だ、というのを見せられたような感覚です。

リファレンスアーキテクチャ、セルフサービス、アプリケーションテンプレートの作成、共通的なソリューションやセキュリティ/品質施策の提供など、まさに自分自身が「こういうのをやっていけばいいんだよ」と考えていたものではありますが、あらためて見てみると要求事項が高かったなと感じる次第です。

とはいえ、すでに実現している世界を見ると「実際にできそうな気がする」ので私自身も実現に向けて頑張っていこうと思います。

おまけ

今回紹介したセッションでは両方とも「Backstage」の活用が入っていました。私も含めある程度「ポジショントーク」な側面はあると思いますが、これだけ言及されているのは浸透していることの裏返しでもあると思います。 だんだん知らないでは済まされないな、と感じてきませんか? 感じた方はぜひ Platform Engineering Meetupなどでお声がけください。6月30日名古屋で開催される第3回に現地参加します(登壇予定です)。ぜひいろいろお話をさせてください。よろしくお願いします。

platformengineering.connpass.com