AEON’s blueprint for technological maturity and market competitiveness/aeon-for-technological-maturity-and-makert-competitiveness

by AEON

Slide 1

Slide 1 text

AEON’s blueprint for technological maturity and market competitiveness Hikaru Saito, AEON Smart Technology Co., Ltd. HashiConf 2024

Slide 2

Slide 2 text

Hikaru Saito Lead SRE and Platform Team

Slide 3

Slide 3 text

‧Originally established in 1758 ‧300+ subsidiary companies ‧600,000+ employees ‧Over 17,000+ stores in 14 countries and online markets AEON is … 2.セクションタイトル

Slide 4

Slide 4 text

Multifaceted, Retail-Focused Businesses

Slide 5

Slide 5 text

”Give the central pillar wheels” -AEON’s Philosophy- Adapt to changes in the environment and transform the company itself.

Slide 6

Slide 6 text

Retail Environment is rapidly changing… Customer behavior, Lifestyle Innovation by Technology Customer Expectations, Value OMO

Slide 7

Slide 7 text

AEON’s Digital Transformation Challenge • seamless shopping experience • customer-centric ecosystem • data integration • Revamping existing operations

Slide 8

Slide 8 text

How to get there? • Customer Centric • Agility • Security and Governance • Data-Driven

Slide 9

Slide 9 text

Role of AEON Smart Technology • Lead Digital Transformation of the group • Promote insourcing development • Agile • Create a New development culture

Slide 10

Slide 10 text

Journey to obtain higher Platform Engineering maturity

Slide 11

Slide 11 text

history of cloud adoption • AEON have used public cloud for 8+ years • Mainly Azure As we have grown… • The complexity has increased • The cognitive load has increased • Inconsistent architecture

Slide 12

Slide 12 text

The purpose of Platform Engineering Empower the Application Developer Team to concentrate on their core activities Finally, maximize the value for customers

Slide 13

Slide 13 text

Step 0: Before starting… We didn’t start from the installation of IDP The fantasy of platform engineering is “one-click deployment” Platform Engineering: The Next Step in Operations

Slide 14

Slide 14 text

Overview Step 1: Build Team and Reliability Step 2: Wiki and Inventory Step 3: Standardization & Higher Reusability Step 4: Self-Service & IDP

Slide 15

Slide 15 text

Step 1: Build Team and Reliability Step 1: Build Team and Reliability Step 2: Wiki and Inventory Step 3: Standardization & Higher Reusability Step 4: Self-Service & IDP

Slide 16

Slide 16 text

Step 1: Build Team and Reliability • Built SRE Enabler and Platform Team as One Team at first • Identify the “high toil” and resolve it • Build reliability with the development team

Slide 17

Slide 17 text

Step 1: Build Team and Reliability Start from “Collaboration” Discover Establish Collaboration X-as-a-service Matthew Skelton, Manuel Pais (2019) 『Team Topologies: Organizing Business and Technology Teams for Fast Flow』

Slide 18

Slide 18 text

Step 1: Build Team and Reliability Example of toils… • Create Cloud Account • Determining Architecture • Deployment of Application • Deployment of Platform Stack

Slide 19

Slide 19 text

Step 1: Build Team and Reliability Summary of this step Why? Outcome • Everything from team building and reliability • Reliability built • Human Resources for deployment • Deployment frequency • Reduction of incident triggered deployment

Slide 20

Slide 20 text

Step 2: Wiki and Inventory Step 1: Build Team and Reliability Step 2: Wiki and Inventory Step 3: Standardization & Higher Reusability Step 4: Self-Service & IDP

Slide 21

Slide 21 text

Step 2: Wiki and Inventory Provide a centralized inventory of.. • Existing tools, platforms • Best practices These will reduce redundancy of onboarding and education

Slide 22

Slide 22 text

Step 2: Wiki and Inventory Education will equip developers with the knowledge to manage infrastructure and tools • We don’t only use Wiki • We hold Internal Workshops • Platform Team has role of enabler.

Slide 23

Slide 23 text

Step 2: Wiki and Inventory document, Wiki Repository

Slide 24

Slide 24 text

Step 2: Wiki and Inventory Summary of this step Why? Outcome • Reduce redundancy of onboarding and education • Sharing knowledge • Number of days it takes for a new employee to do first PR • Tool usage • Reduction of Support Tickets

Slide 25

Slide 25 text

Step 3: Standardization & High Reusability Step 1: Build Team and Reliability Step 2: Wiki and Inventory Step 3: Standardization & Higher Reusability Step 4: Self-Service & IDP

Slide 26

Slide 26 text

Step 3: Standardization & High Reusability To maximize the leverage of developer productivity • Standardize workload infrastructure • Enhance reusability by terraform modules • Provide templates Database AKS Azure Functions App Service Redis • Managed by modules and variables • Standardize the parameter • Developer can reconfigure following their requirement

Slide 27

Slide 27 text

Step 3: Standardization & High Reusability Platform Reliability Security Governance Observability CI/CD It is efficient for points that • Developers don’t want to consider about them • Developers want to ensure quality of them Scalability

Slide 28

Slide 28 text

Step 3: Standardization & High Reusability Summary of this step Why? Outcome • To maximize the leverage of developer productivity • Lead time to deploy the platform • Reduction of human resources spent on design and configuration

Slide 29

Slide 29 text

Step 4: Self-Service & IDP(future work) Step 1: Build Team and Reliability Step 2: Wiki and Inventory Step 3: Standardization & Higher Reusability Step 4: Self-Service & IDP

Slide 30

Slide 30 text

‧Interface Improvements ‧IaC Code? CUI? GUI? ‧Requirements depends on developer’s skill or preference ‧GUI is not always best solution ‧focus on increasing its value for the customer(=developer) ‧If we install IDP, we need UI/UX skills Step 4: Self-Service & IDP(future work)

Slide 31

Slide 31 text

“Software developers probably already have tools and processes for managing the simplest and most commonly used paths (which aren’t necessarily the same). ” Platform Engineering: The Next Step in Operations Step 4: Self-Service & IDP(future work)

Slide 32

Slide 32 text

Team Design

Slide 33

Slide 33 text

About Team Design ‧We should review the team design depending on the phase and situation. ‧Consider splitting the team if the team grows. ‧Keep two-pizza size

Slide 34

Slide 34 text

Team Design #1 SRE Team Developer Teams • It all starts with the smallest size and most simple structure • In this phase, SRE Team is responsible for platform engineering as well 👍 Simple, Close communication 👎 Scalability, grown cognitive load in SRE Team Developer Teams Developer Teams

Slide 35

Slide 35 text

Team Design #2 SRE Team Developer Teams • As SRE Team grows, split into Platform Team and SRE Team to keep two-pizza size and divide responsibilities Developer Teams Developer Teams Platform Team

Slide 36

Slide 36 text

Team Design #2 Team Responsibility SRE Team ‧Implement SRE practices with the developer teams through embedding or enabling. ‧Responsible for Reliability ‧This team is customer of Platform as well. Platform Team ‧Responsible for Reliability ‧focus on providing Wiki, inventory, templates, and useful tools.

Slide 37

Slide 37 text

Team Design #3 (we are here) SRE Team Developer Teams • To further expand Platform Engineering within the group, establish a CCoE. • CCoE is responsible for the strategy. Developer Teams Developer Teams Platform Team CCoE

Slide 38

Slide 38 text

Team Design #4 (future work) Platform Team • To install IDP, Platform Team needs variety of skills. • If necessary, split platform team by skills Templates Team Platform Team IDP Team SRE Team (for platform) Idea to consider Enabler Team

Slide 39

Slide 39 text

Outcomes

Slide 40

Slide 40 text

Outcomes( in the last 2 years) Number of Teams Number of Products Number of Download Apps 6x 5x 10m Number of critical Incidents 1/4

Slide 41

Slide 41 text

How we maximize the cloud maturity by using HashiCorp Products

Slide 42

Slide 42 text

Overview related with HashiCorp Products

Slide 43

Slide 43 text

Why we use HashiCorp Cloud Platform? ‧Reduction of Operational Burden ‧Scalability ‧Fast Setup

Slide 44

Slide 44 text

HCP Terraform Why we use Terraform? (why we don’t use Bicep?) ‧De facto Standard of IaC languages ‧Only using a single cloud will not cover everything. ( like PagerDuty, New Relic..) ‧Advantage of “state file”

Slide 45

Slide 45 text

HCP Vault • Periodical rotation • Minimum privileges • Audit • Encryption Best practice of secret management HCP Vault provides • Centralized management • Automatic rotation • Dynamic Secret • Encryption

Slide 46

Slide 46 text

Let’s enjoy the Platform Engineering journey with HashiCorp Products!!

Slide 47

Slide 47 text

”Give the central pillar wheels” -AEON’s Philosophy- Adapt to changes in the environment and transform the company itself.

Slide 48

Slide 48 text

Thank you!