Platform Engineering on Kubernetes The past, present and future Feb ‘25 - Tokyo Japan Kubernetesで実践する Platform Engineering Platform Engineeringの過去、現在、そして未来 2025年2月 - 日本/ 東京

@Salaboy Mauricio Salatino https://salaboy.com

Kubernetesで実践する Platform Engineering Platform Engineering on Kubernetes (Book) ● 2020年2月に開始 ○ Started in Feb 2020 ● 2023年10月にManningより出版 ○ Published Oct 2023 by Manning ● 実践的なアプローチ ○ Practical approach ● プラットフォームのバックエンド、メカニズム、 APIに焦 点を当てる ○ Focused on platforms backends, core mechanisms and APIs

Platform Engineering on Kubernetes もともとは2021年9月に異なるタイトルで発表しました The early access program was announced in September 2021 under a different title The “Why” なぜ必要か The “What” 何を実現するか

Book Chapters • Intro • CI/CD • GitOps • Building a Platform (provisioning a development environment) • Platform Capabilities • Release Strategies • Enabling Developers with feature flags and APIs • Measuring platform initiatives with DORA

Book Repository: step-by-step tutorials https://github.com/salaboy/platforms-on-k8s 󰏦 🥳

過去 (二〇一八年－二〇二二年 ) 2018 - 2022

なぜ組織は Kubernetesを採用するのか？ Why do organizations adopt Kubernetes? 1. コンテナオーケストレーションによるコスト削減 Container orchestration savings 2. マイクロサービスアーキテクチャにおける DevOps効率の向上 Increased DevOps efficiency for microservices architecture 3. マルチクラウド環境でのワークロードデプロイ Deploying workloads in multicloud environments 4. ベンダーロックインのリスクを抑えた高い移植性 More portability with less chance of vendor lock-in 5. デプロイメントとスケーラビリティの自動化 Automation of deployment and scalability 6. クラウド環境におけるアプリケーションの安定性と可用性 App stability and availability in a cloud environment 7. Kubernetesのオープンソースとしてのメリット Open-source benefits of Kubernetes Source: IBM “Top 7 benefits of Kubernetes”

しかし...状況は急速に複雑化しています But.. it gets really complicated really fast 1. アプリケーションを効率的にデリバリーするには、Kubernetesの標準機能だけでは不十分 To efficiently deliver applications, Kubernetes built-in mechanisms are not enough 2. DevOps、開発者、運用チームを含む組織全体にKubernetesを教育するのはコストがかかる It is expensive to train a whole organization to learn Kubernetes including DevOps, developers and operation teams 3. チームごとに要件が異なり、それぞれのニーズに合わせてKubernetesを拡張する必要がある Different teams have different requirements, you need to extend Kubernetes to fit their needs 4. Kubernetesの独自拡張を管理することで技術的負債が生まれる Managing custom Kubernetes extension creates technical debt これらの複雑さを全て管理する必要があります We need to manage all these complexities プラットフォームが必要です We need a platform

Typical Kubernetes adoption journey Kubernetes Maturity Model (very DevOpsy - 2021)

My Personal Journey • After working for Red Hat and VMware, I joined Diagrid Nov 2022—a company created around the https://dapr.io project • Dapr was created by Microsoft and donated to the CNCF in 2019, Graduated 2024 • Dapr enables application and platform teams by abstracting complex infrastructure using APIs

現在 (二〇二三-二〇二五) 2023 - 2025

Kubernetes & cloud native adoption maturity model (technical) 1. 評価 - Evaluate 2. 導入 - Adopt 3. 自動化- Automate / 拡張 - Extend / 最適化 - Optimize 4. プラットフォームの提供 - Platform capabilities Kubernetes & Cloud Native 導入成熟度モデル (技術面)

#1 Evaluate (aka PoCs) 1. Kubernetes basics -> Deployments, YAML, Tools 2. Observability (logs, metrics, traces) 3. Security (mTLS, secrets, service meshes) 4. Scalability In this stage: - Small teams playing around with Kubernetes and learning the basics - No company buy-in yet - Big learning curve, but there are tons of resources and companies that will help you today

#1 Evaluate (aka PoCs) → Tools

#2 Adopt (running production workloads) 1. 継続的インテグレーションとコンテナ化の課題 Continuous integration and containerization challenges 2. デプロイメントとGitOps Deployment and GitOps 3. クラウドリソースのプロビジョニングと管理（IaC） Cloud resources provisioning and management (IaC)

#2 Adopt (running production workloads) → Tools CNCF GRADUATED

#3 Automate/Extend/Optimize your delivery pipelines 1. 新しいドメイン固有の拡張機能の作成（カスタムコントローラーとオペレーター） Create new domain specific extensions (custom controllers and operators) 2. 特定の問題に対するサードパーティソリューションの導入（クラウドネイティブ・エ コシステムから） Bring third party solutions to specific problems (from the cloud native ecosystem) 3. OpenshiftなどのKubernetesディストリビューション／プラットフォームの評価 Evaluate Kubernetes distributions / platforms such as Openshift 4. マルチクラスターの課題と管理の検討開始 Start looking into multi-cluster challenges and management

#3 Automate/Extend/Optimize → Tools

#4 Design your platform capabilities 1. チームが利用するための連携機能を構築する 専任のプラットフォームチーム を持つ Have a dedicated Platform team building glue for teams to consume • 複数のチームのためにツールを維持管理する必要があるため、ツールの選択に強い方 針を持つ Very opinionated in choosing tools, because they will need to maintain them for multiple teams 2. プラットフォームチームは#1、#2、#3のトピックの自動化から始め、これらの決定の複雑さを隠 蔽する Platform teams start by automating topics in #1, #2 and #3, hiding the complexity of these decisions 3. 低レベルの詳細の隠蔽 Hiding low-level details 4. 開発者体験（devexp）の統合 Consolidation of experiences (devexp) 5. アクセスの一元化 Centralized access

#4 Design your platform capabilities → Tools Argo Rollouts Knative

Where are you in the adoption Journey? • Classify a customer based on which stage / phase they are as an organization • Classify platform team based on which stage the particular team is • They care about different aspects depending on the phase • #1 Evaluate: • how does this project/product help me to adopt Kubernetes faster? • #2 Adopt • How does this project/product fits with the choices that I’ve made already (deployment mechanisms, service providers) • #3 Customize / Extend / Consume • What set of functionalities this product/project adds to my existing stack, who are the target users? How much complexity this adds to my overall solution • #4 Platform Initiatives • What are the current platform team priorities? How does this project/product maps with those priorities? • If they are a development team, priorities and phases completely different

Consolidation

Consolidation: BACK Stack (https:/ /backstack.dev/) ● Public and opinionated combinations ● Backstage + Argo CD + Crossplane + Kyverno ● Showing how Kyverno fits into the ecosystem Easy developer adoption with

Consolidation: CNOE (https://cnoe.io/) ● More complex and Pluggable ● Driven by AWS - EKS ● Based on what their customers are using Easy developer adoption with

Platform Engineering Maturity Model (link) (organizational) How mature are the Platform Engineering practices for a given organization?

Platform Engineering Maturity Model 2023 (organizational) How mature are your Platform Engineering practices? (link) Aspect Provisional Operational Scalable Optimizing Investment How are staff and funds allocated to platform capabilities? Voluntary or temporary Dedicated team As product Enabled ecosystem Adoption Why and how do users discover and use internal platforms and platform capabilities? Erratic Extrinsic push Intrinsic pull Participatory Interfaces How do users interact with and consume platform capabilities? Custom processes Standard tooling Self-service solutions Integrated services Operations How are platforms and their capabilities planned, prioritized, developed and maintained? By request Centrally tracked Centrally enabled Managed services Measurement What is the process for gathering and incorporating feedback and learning? Ad hoc Consistent collection Insights Quantitative and qualitative

Centralized access & Developer Experience Dapr↔Backstage integration coming soon!

Developer Experience: Podman ecosystem • Red Hat’s alternative to Docker (OCI) • End-to-end from developers to Kubernetes • Integrated with developer tooling • Podman is donated to CNCF Nov 2024

Developers and Cloud Native (https://tag-app-delivery.cncf.io/wgs/app-development/) 一緒に活動しませんか？

未来 (二〇二五-二〇三〇) 2025 - 2030

CNCF Platform Engineering Programs (https://training.linuxfoundation.org/platform-engineering-programs/) 最新のお知らせをお見 逃しなく！ 👀👀

Lot of work to do around App Dev 1. When Platform Teams meet developers • Blog • KCD UK - with Abby Bangser • Giving developers a KIND Cluster doesn’t solve real problems • Meet developers where they are (don’t make developers learn new things) 2. Ops & DevOps & Platform teams need to learn about the tools that developers are using • Developers inherit frankenstein experiences (using different CLIs, User Interfaces and tools that had been designed with different personas in mind)

Developer Experience & developer communities - The more mature the platform initiatives are the closer we get to developers - A push around developer experience already started, but we need to be more concrete about what it means - As platform engineers - We need to get more involved with developer tooling - We need to get closer to developer communities - The state of developer experiences in 2025 whitepaper by the App Dev WG

KubeCon Hong Kong + Japan 👀 • Big opportunity for collaboration with other industries • Engaging new communities and validating use cases • A new Application Developer track was introduced

KubeCon EU London 2025 App Dev Track

マルチクラスターの課題の進化 The evolution of multi-cluster challenges • Kueue https://kueue.sigs.k8s.io/ • 分散型およびマルチクラスターのジョブスケジューリング • Distributed and multi cluster Job scheduling • これは今後解決していく課題の一例です • This highlight the kind of challenges that we will be solving next • KCP (https://www.kcp.io/) is always there in the background (unified interface to talk to multiple clusters) • Kubernetes Workspaces proposal by Apple “Kubernetes Workspaces: Enhancing Multi-Tenancy with Intelligent Apiserver Proxying” - J. Munnelly, A. Tosatto, Apple

AI対応プラットフォーム AI-Enabled Platforms • KubernetesでのAIワークロードの実行は課題が多いものの、進展しています Running AI workloads on Kubernetes is challenging, but things are moving forward • AI / LLM Gateways / APIs (Dapr Conversation API, Envoy AI Gateway) • AI Agents and frameworks • より多くの統合の課題が予想され、それはコストのかかる種類のものです Expect more integration problems, the expensive kind

次のステップ (Salaboy’s wish list) What’s next • 設計図やテンプレートの充実化を図り、統合の次のフェーズへ • More blueprints, the next phase of consolidation • 開発者とプラットフォームエンジニアの協業をより円滑に • We manage to bring developers closer to platform engineers • 効率的なコミュニケーションツールと仕組みづくり • Efficient communication channels and tools • Cloud Nativeのエコシステムを活用し、 AIによるモダナイゼーションを実現する • We enable AI modernization using the cloud native ecosystem

ご静聴ありがとうございました ! @salaboy / @daprdev / @diagridio dapr.io diagrid.io diagrid.io

No content

#1 Evaluation: How does Dapr fits in this stage? - Topics that resonate at this point are Observability and Security - How can Dapr help teams at this stage to go faster without sounding too complex? (adding a new tool to their stack is always the entry point) - Smooth adoption journey for Kubernetes without adding new problems - Dapr Value Proposition: - Dapr helps to to make your applications observable, resilient and secure cross cloud (future proofing)

#2 Adopt: How does Dapr fits in this stage? - Topics that resonate here are - Components, Configurations & Resiliency Policies abstract away infrastructure so applications can rely on a unified API to access cloud infrastructure for their applications - Which Kubernetes resources does Dapr provides and what problem do they solve? - They are probably doing modernization of infra - Operations at scale (SREs) Conductor makes a lot of sense.. Running Dapr at Scale - (IMPORTANT) they don’t care about Developers at this stage.. So we should focus on Resources here. - Dapr Value prop: - “Abstract Infrastructure from Application” (enabling cross cloud applications)

How does Dapr fits in this stage? - Topics that resonate here are - Project Maturity - Case Studies with other companies adopting this project, showing that the project is production ready - There is a company providing support and product to run Dapr at scale (Conductor) - Dapr Value Prop: - Enable workloads to have less friction across environments (Access control ) - Zero trust workloads

How does Dapr fits in this stage? - Topics that resonate here are - Ecosystem player, how do we integrate with other solutions - Integrates with with Cloud Providers - Can we tap into the automation process they are have already in place? How which mechanisms do we provide? - How do we augment existing golden paths? - What’s the value proposition: - For existing apps (brownfield apps) - For new Apps (greenfield) - For new initiatives like extending existing apps with AI - Dapr Value Prop: - Enable developer teams go faster (design patterns, best practices, solutions to distributed application challenges) - Enable operations to quickly troubleshoot apps + infra