Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

GitHub Universe2023 Driving organizational sustainability with platform engineering

こんちわ。オルターブースの小島です。 今年もサンフランシスコまでGitHub Universe2023に参加するために来ました。 今回は弊社メンバー総勢5名での参加です。 すでに参加速報記事が弊社メンバーより公開されていますので、ぜひご参照くださいませ。

aadojo.alterbooth.com さて、GitHub Universeの個別セッション1つ目は「Driving organizational sustainability with platform engineering」に参加してきました。

Platform Engineeringとは

GitHubが定義するPlatform Engineeringとは、クラウドSREやMSPを包括した技術志向です。

Platform Engineering drives organizational sustainability by practicing sociotechnical principles that provide a community driven support system for application developers using our standardized shared platform architecture.

これをわかりやすくいうと、標準化されたプラットフォーム・アーキテクチャーを用いて、開発者に対してサポートコミュニティを提供することで組織の持続可能性を推進する、ということです。

Principles, Community, Architecture

Platform Engineeringは原則があり、その原則をもとにコミュニティが形成され、最後にアーキテクチャーが設計されます。 まずはその原則の話です。

Principles

Principlesには5つの構成要素があります。

  1. Culture
  2. Automation
  3. Lean
  4. Measurement
  5. Sharing

特に1〜3はDevOpsやSREにおいて中核となる考え方です。 されにこれらを持続させるには文化が必要になります。

Learning is the only sustainable advantage.

日本ではリスキリングとかいうワードがありますが、本質的には学ぶことが唯一の持続可能な利点である、と指摘しています。 一時的な学びではカルチャーは作れない、ということですかね。 またDevOpsとPlatform Engineeringがもたらすカルチャーの違いについても説明していました。

DevOpsカルチャー

Devopsは継続的な改善の文化を推進し、意図的に知識とフィードバックを共有することで知識のサイロ化を抑制します。

Platform Engineeringカルチャー

Platform Engineeringは、ソフトウェアの構築と知識共有のためのコミュニティベースのアプローチを通じて、継続的な改善の文化を推進しています。

Community

コミュニティは自発的なものと戦略的なものがありますが、ここでは戦略的なコミュニティシステムが説明されています。

Communal Support Strategies こちらも4つの原則があります。

  1. Make building sustainable software easy
  2. Scalable, flexible adoption techniques
  3. Support engineers in building their skills
  4. Drive a sustainable culture

上記は 「持続可能なソフトウェアの構築を容易にし、スケーラブルで柔軟な導入方法で、エンジニアのスキルアップを支援する、持続可能な企業文化の推進」ということです。

何やら難しい話ですが、要は知識のサイロを防ぐナレッジベースが必要だ、という意味かなと思います。 ここらへんはCCoE(Cloud Center of Excellence)あたりと関連するかもしれませんね。

Architecture

最後にアーキテクチャーですが、原則としては2つあると言っています。

  1. Use Design Drive Architecture
  2. Responsive to evolving architecture needs

すべてデザイン駆動でアーキテクチャーを組み、そのアーキテクチャーは進化する、という意味かと思います。 しかし、このような状態で自由に設計し、アーキテクチャーを構築していくと大抵はカオスになるという。 確かに”一貫性”は失われてしまうかもしれませんね。 一貫性って標準化されたなにかを実装すればいいのだけど、標準化されていない最新のツールや技術ではあっという間に枯れてしまい、それらが技術的負債に陥ることもありますよね。

なので、デザインレシピ、ドメインを明確に分けたプラットフォームのレシピ、インフラの実行環境の3つに一貫性をもたせることが大切であると言っています。 プラットフォームレシピはTwelve Factorなんかでよく紹介されていますよね。 インフラの実行環境についても以下の様にフェーズを分けて作ると言っていました。

  1. Base template & Images
  2. Opt-in Image Artifacts
  3. Container Orchestration Integrations
  4. Incident Management Support

ここらへんの話はクラウドネイティブな運用、SREなんかが対象になるかなと思います。

GitHubによるPlatform Engineeringの必要性

ここまでかなりエモい話が続いていましたが、なぜこれらとGitHubが関係するのか。 それはGitHubが提供する様々なサービスで一貫性を作れ、ということです。 特に最も裾野が広いArchitectureでは、Platoform Engineeringの原則からどんどん外れていき、Chaos Domainに陥るわけです。

実は隠れファンが多いGitHub ProjectやIssue Templateなどはこういった一貫性の一つだし、Actionsを使うことでデザインドメインを分けることができるし、リポジトリを適切に公開することでCultureが作れます。 そして開発者は皆このリポジトリに対してコミットし、レビューし、運用していくので、持続可能な組織が出来上がるわけです。

ということで、GitHub Universeではこのようなちょっと哲学的なセッションもあってとても興味深いですね。

まだまだGitHub Universeは続くの速報ブログお楽しみに!!


サービス一覧

www.alterbooth.com

cloudpointer.tech

www.alterbooth.com