Discover Your Tailored Platform Strategy with Real-World Practice

This slide was for my presentation at the KubeDay Japan 2024.
- https://events.linuxfoundation.org/kubeday-japan/

■ Session description:
Recent IT paradigms like DevOps, CD, and IaC have shortened release cycles but also burdened developers with mastering many tools. Platform Engineering addresses this by providing Internal Developer Platforms (IDP) that automate non-essential tasks.

To achieve IDP success, It's crucial to find right scale and functionality of IDP for your organization to optimize ROI, and required to take into account human aspects such as documentation, user support, and advocacy. So achieving IDP success can often be elusive.

To address this, the Platform Engineering Maturity Model by CNCF guides to define the goals and the path to success. First, this session will briefly overview the Maturity Model and how it can facilitate IDP realization. He will then present a practical example from LY Corporation's Kubernetes-based PaaS, illustrating how the IDP journey is implemented as a down-to-earth initiative, including human aspects, offering insights into successful IDP strategies for your organization.

Transcript

1. Discover Your Tailored Platform Strategy with Real-World Practice Hiroshi Hayakawa, LY Corporation
2. About Me • Working for LY Corporation • An internet company that offers various services, including communication, internet portals, media, and commerce …etc, primarily in Japan. • Contributing to CNCF TAG App Delivery • Author of books on Kubernetes • DIY keyboard enthusiast Hiroshi Hayakawa | @hhiroshell
3. Agenda • Introduction • Platform Engineering Maturity Model • How to Define your Journey of Platform Engineering Initiatives • Case Study
4. Agenda • Introduction • Platform Engineering Maturity Model • How to Define your Journey of Platform Engineering Initiatives • Case Study
5. What is Platform Engineering? • Recent IT paradigms have shortened release cycles but also burdened developers with mastering many tools (cf. extraneous cognitive load) Cloud Infrastructure & IaC Microservices Continuous Integration & Delivery DevOps
6. What is Platform Engineering? • An initiative to provide foundations called IDP(Internal Developer Platform) • IDP allows internal developers to focus on creating essential values for their business versatile but burdening tools and infrastructures IDP Platform Team Developers use provide use
7. Platform Engineering Papers by CNCF • Platforms White Paper • Platform Engineering Maturity Model • Glossary
8. Japanese Versions are Available! • Translations into various languages are progressing within the Platform Engineering WG within the CNCF TAG App Delivery.
9. Agenda • Introduction • Platform Engineering Maturity Model • How to Define your Journey of Platform Engineering Initiatives • Case Study
10. Platform Engineering Maturity Model • A guide for all platform stakeholders in an organization • Provides a framework to discuss: • which level your platform initiatives are on • what challenges the initiative might face • which practices should be implemented
11. The Model Investment Adoption Interfaces Operations Measurement Level 1 Provisional Level 2 Operational Level 3 Scalable Level 4 Optimizing Voluntary or temporary Erratic Custom processes By request Ad hoc Dedicated team Extrinsic push Standard tooling Centrally tracked Consistent collection As product Intrinsic pull Centrally enabled Insights Enabled ecosystem Participatory Integrated services Managed services Quantitative and qualitative Self-service solutions
12. The Model Investment Adoption Interfaces Operations Measurement Level 1 Provisional Level 2 Operational Level 3 Scalable Level 4 Optimizing Aspects Levels
13. Aspects Investment Adoption Interfaces Operations Measurement How are staff and funds allocated to platform capabilities?
14. Aspects Investment Adoption Interfaces Operations Measurement How are staff and funds allocated to platform capabilities? Why and how do users discover and use internal platforms and platform capabilities?
15. Aspects Investment Adoption Interfaces Operations Measurement How are staff and funds allocated to platform capabilities? Why and how do users discover and use internal platforms and platform capabilities? How do users interact with and consume platform capabilities?
16. Aspects Investment Adoption Interfaces Operations Measurement How are staff and funds allocated to platform capabilities? Why and how do users discover and use internal platforms and platform capabilities? How do users interact with and consume platform capabilities? How are platforms and their capabilities planned, prioritized, developed and maintained?
17. Aspects Investment Adoption Interfaces Operations Measurement How are staff and funds allocated to platform capabilities? Why and how do users discover and use internal platforms and platform capabilities? How do users interact with and consume platform capabilities? How are platforms and their capabilities planned, prioritized, developed and maintained? What is the process for gathering and incorporating feedback and learning?
18. Levels Level 1 Provisional Level 2 Operational Level 3 Scalable Level 4 Optimizing • Greater impact on the organization • Requires more funding and people’s time
19. Definitions of Levels Investment Adoption Interfaces Operations Measurement Level 1 Provisional Level 2 Operational Level 3 Scalable Level 4 Optimizing Voluntary or temporary Erratic Custom processes By request Ad hoc Dedicated team Extrinsic push Standard tooling Centrally tracked Consistent collection As product Intrinsic pull Centrally enabled Insights Enabled ecosystem Participatory Integrated services Managed services Quantitative and qualitative Self-service solutions
20. Definitions of Levels Investment Adoption Interfaces Operations Measurement Level 1 Provisional Level 2 Operational Level 3 Scalable Level 4 Optimizing Voluntary or temporary Erratic Custom processes By request Ad hoc Dedicated team Extrinsic push Standard tooling Centrally tracked Consistent collection As product Intrinsic pull Centrally enabled Insights Enabled ecosystem Participatory Integrated services Managed services Quantitative and qualitative Self-service solutions
21. Definitions of Levels Self-service solutions
22. Definitions of Levels Characteristics • Typical characteristics of platforms in each level of the aspects • Many organizations will see characteristics of more than one level being applicable Example Scenarios • Example scenarios in which the platform or people involved in it might face Level Title & Descriptions Self-service solutions
23. What’s the Point of the Maturity Model? • Is aiming for a higher score the higher score? • To discover the one definitive way to advance your platform’s initiative? • Provide a helpful way to understand • Where you currently are on your platform journey • What challenges the initiative might face • Which practices should be implemented
24. Agenda • Introduction • Platform Engineering Maturity Model • How to Define your Journey of Platform Engineering Initiatives • Case Study
25. What’s the “Journey” of Platform Engineering? • A definition of the path to realizing a platform that generates the targeted business value. Specific Efforts Goal Start
26. Setting Checkpoints • Set checkpoints and determine the desired maturity level and key characteristics of platforms at each one Goal Start
27. Find out what you should actually do • Identify specific efforts to be taken based on the gaps between checkpoints • Level definitions of the maturity model will help in defining it Goal Start • Additional human resource investments • Implement self-service onboarding wizard • …etc
28. More About Checkpoints… • Setting appropriate intermediate checkpoints helps guide your journey • Helps set actions as incremental steps • Makes it easier to manage and report the progress of the platform initiatives • The starting point should be as small as possible but effective • Don’t forget to consider the organization’s context to define the state of checkpoints Goal Small but effective start point Intermediate checkpoint
29. Agenda • Introduction • Platform Engineering Maturity Model • How to Define your Journey of Platform Engineering Initiatives • Case Study
30. The Platform Featured in This Case Study • A foundation for deploying, running, and operating web applications with minimal effort, powered by Kubernetes $ paasctl create app hello-world --image=example-registry/sample/helloworld-go:latest --port=8080 $ paasctl get app hello-world NAME ENDPOINT READY REASON AGE hello-world https://hello-world.sandbox.app.dev.yahoo.co.jp True 6m4s $ curl https://hello-world.sandbox.app.dev.yahoo.co.jp Hello World!
31. The Platform Featured in This Case Study • Integrated with the internal developer portal and other platform capabilities, including AuthN/Z, secret manager, and observability • Supports multi-tenancy and super scalability enough to handle about 500 tenants, and 150,000 app instances (Kubernetes pods) • Currently handles: • 400 tenants • 13,000 apps • 80,000 pods • 750,000 req/s
32. Platform with Kubernetes • Kubernetes plays a crucial role as the foundation for realizing platforms • Core functionalities to reliably run various workloads: • Self-healing, rolling updates, scalability, etc • Well-organized extensibility: • Custom controllers, admission webhooks, etc • Consistent user experience centered around the API Server • Even with feature extensions, the basic user experience remains unchanged.
33. Note • The development of our platform began several years before the maturity model was published • So, this case study is a reconstruction of our journey, assuming that the Maturity Model existed at the time
34. Our Checkpoints • Limited Availability (LA): • The platform meets limited use cases and is available exclusively to nominated users • Generally Available (GA): • The platform is widely available within the organization and prepared for an increase in users • Goal: • The level of the platform that the organization requires, derived from business goals LA GA Goal
35. Maturity Level of Checkpoints - LA • The platform meets limited use cases and is available exclusively to nominated users Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 Goal LA GA • Meets only limited use cases • Available exclusively to nominated users • Onboarding process is based on dedicated support provided by the platform team • Integration with other capabilities involves manual work • Sufficient platform team members to support only a limited number of users
36. Maturity Level of Checkpoints - GA • The platform is widely available within the organization and prepared for an increase in users Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 Goal LA GA • Widely available within the organization • Early adopters can adopt the platform by their own will and choice • It supports a wide range of use cases • Enough scalability to handle an increase in users • Provides self-service onboarding experience, but it contains manual operation by platform team • Provides well organized documentation set and user support forums
37. Maturity Level of Checkpoints - Goal • The level of the platform that the organization requires, derived from business goals Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 Goal LA GA • Users adopt the platform by their own will and choice • Users pay through a cost allocation system, and it’s integrated into the business value stream. • Self-service day 1 to day 2 experience with centralized developer portal • Integrated with other platform capabilities, for example, AuthN/Z, secret management and o11y • Provides consistent UX with other capabilities
38. Define Actions - LA to GA • Breakdown the gaps between checkpoints into to actual actions Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 Goal LA GA Investment Obtain stakeholder agreement for investing in additional personnel to support growing users Adoption Changes the architecture of metrics pipelines for scalability Interface Implement a self-service onboarding wizard on the portal so users can finish their tasks Add, revise, and re-organize documentation reflecting the feedback from users in LA
39. Define Actions - GA to Goal • Breakdown the gaps between checkpoints into actual actions Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 LA GA Adoption Build a feature to aggregate and analyze usage data Integrate the usage data with the cost allocation system and make it visible within the user’s value stream. Interface Implement self-service experiences for both day1 and day2 operations Expand support for corner use cases based on the priority Goal
40. Beyond the journey’s end… • We need to address overlooked aspects to enhance the overall maturity Investment Adoption Interfaces Operations Measurement L1 L2 L3 L4 LA GA Goal • The lack of a strategic approach to feature development and an effective feedback loop • Operations: > L3 • Measurement: > L2 • It could hinder the further growth of the platform
41. Key Lessons & Take Aways • Set appropriate checkpoints and ensure steady progress by taking small, incremental steps • Prioritize the aspects and the characteristics to incorporate based on the value you want to achieve and the constraints of the organization • Don’t completely overlook the less prioritized aspects. Consider all aspects in parallel • The lack of investment, a feature strategy, and effective feedback loops could hinder the improvement of the platform
42. Let’s get involved! • CNCF TAG App Delivery • Home page: • https://community.cncf.io/tag-app-delivery/ • https://tag-app-delivery.cncf.io/ • Slack channel: #tag-app-delivery in CNCF Slack • Mailing list: https://lists.cncf.io/g/cncf-tag-app-delivery/topics • Platform WG • Home page (under the TAG’s HP): https://tag-app-delivery.cncf.io/wgs/platforms/ • Slack channel: #wg-platforms in CNCF Slack
43. Any Questions?