S P E A K E R Shiro Seike @seike460 Team-First Serverless Platform Engineering Approach to PHP Applications with Laravel and Bref 

©Fusic Co., Ltd. 2 Shiro Seike @seike460 Professional Roles AWS Community Builder (Serverless) 2025 Japan AWS Top Engineers (Services) Community Leadership Organizer: JAWS-UG Fukuoka Fukuoka.php、Fukuoka.go、Serverless Meetup Fukuoka Cloudflare Meetup Fukuoka、JP_Stripes Fukuoka JBUG Fukuoka、 JDDUG Fukuoka (DataDog) About Me Introduction Fusic Co., Ltd. (Japan Fukuoka) Principal Engineer / Evangelist 

©Fusic Co., Ltd. 3 I‘m leading JAWS Days 2026 as Executive Committee Chair — see you there! 2026/03/07 

©Fusic Co., Ltd. 4 CONTENTS Agenda 1. Reflecting on Serverless Development 2. The Value and Reality of Continuous Serverless Adoption 3. Making Serverless Fit Your Team 4. Our Platform Engineering Challenge to Bridge Teams and Serverless 5. Summary 

©Fusic Co., Ltd. 5 Reflecting on Serverless Development 1 

©Fusic Co., Ltd. 6 What is Serverless? The definition of 'Serverless' is According to the Cloud Native Computing Foundation As stated in CNCF Serverless Whitepaper v1.0 The 'concept' of building and running applications without server management For PHP teams, this means freeing Laravel developers from server provisioning while keeping their workflow intact. https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview 

©Fusic Co., Ltd. 7 There Are Numerous Benefits to Adopting Serverless Concepts There are many benefits to introducing Serverless Architecture, enabling concepts that were difficult to implement with physical servers While large-scale examples are often discussed, small-scale development is where serverless concepts often shine I have been actively adopting Serverless Architecture 

©Fusic Co., Ltd. 8 Striving to Be Serverless I don't believe serverless is something that can be defined as 'only this is serverless' Today, I'll share the value we've delivered through our continuous efforts to adopt serverless concepts, and how we focused on developers to make serverless 'fit our teams' This is our story of that journey 

©Fusic Co., Ltd. 9 The Reality of Continuous Serverless Adoption 2 

©Fusic Co., Ltd. 10 Our Technology Stack We primarily conducted contract development centered on PHP, Ruby, and AWS We also develop our own products in PHP, making it an integral part of our stack However, PHP lacks an official AWS Lambda runtime, creating a mismatch Despite this, I believed in serverless value and continued its adoption 

©Fusic Co., Ltd. 11 Adding Serverless API as Value Project Objective Decouple partner data ingestion from an EC2-hosted marketing site Keep the public experience fast while absorbing bursty partner traffic Architecture Snapshot Amazon API Gateway -> AWS Lambda -> Amazon S3 for durable intake Existing EC2 cron pulls from S3 on its own cadence Impact Delivered Handled 200x data growth without manual scaling or downtime Eliminated load spikes on the website and simplified partner onboarding 

©Fusic Co., Ltd. 12 Adding Serverless API as Value Ownership Gap Website had a shared maintenance team, but the serverless API depended on me alone Technology stack drift discouraged cross-team contributions Why Rewrites Failed Rebuilt the Lambda integration in Go for maintainability, yet onboarding stayed slow Tooling and deployment differences outweighed language familiarity Lesson Architecture success without shared ownership is not real adoption 

©Fusic Co., Ltd. 13 Building Language-Agnostic Serverless Sites ML Execution Platform Serverless orchestration for machine learning batch jobs Spin up powerful compute only when the analytics team needs it Value to Stakeholders Near-zero idle cost compared to always-on EC2 capacity Data scientists launched experiments without waiting for infrastructure Limitation Built outside the PHP stack, so reuse by Laravel teams was limited 

©Fusic Co., Ltd. 14 Building Language-Agnostic Serverless Sites Experiment: AWS Amplify + AppSync Full-stack serverless GraphQL front end with configuration-driven development Internal workshops helped teams prototype rapidly What Worked Frictionless connection to managed authentication, storage, and APIs Great for greenfield experiments and innovation teams What Stalled Laravel-centric teams felt the workflow diverged from their MVC habits Adoption paused until other serverless wins built trust 

©Fusic Co., Ltd. 15 Runtime Mismatch Runtime Reality Serverless value was clear, but PHP teams hesitated to operate Lambda workloads Ruby teams advanced faster because AWS provided an official runtime Cognitive Load Factors Learning custom runtimes, packaging, and IAM per project Different deployment pipelines versus existing Laravel tooling Resulting Challenge Projects launched with minimal maintainers, creating operational risk 

©Fusic Co., Ltd. 16 Is Applying Serverless Wrong? Of course not It delivers value to the systems we provide 

©Fusic Co., Ltd. 17 Reassessing Our Goals The goal is not 'deploy serverless and be done' Think about 'serverless that teams can operate' 

©Fusic Co., Ltd. 18 Making Serverless Fit Your Team 3 

©Fusic Co., Ltd. 19 Exploring PHP on AWS Lambda We started exploring PHP adoption around 2018 In materials for PHP Conference 2019, the year after custom runtimes were announced, I researched 'how to use AWS Lambda with PHP' 

©Fusic Co., Ltd. 20 Laravel + Bref on AWS Lambda Why Laravel Matters Anchored in our company culture with robust AWS integrations via configuration Teams already rely on queues, events, and caching abstractions Bref Superpower Wraps AWS Lambda custom runtimes so PHP code deploys with familiar workflows Hides bootstrap complexity while supporting HTTP, console, and queue workers Impact on Developers Laravel + Bref keeps artisan commands, testing strategy, and directory layout intact Teams gain serverless benefits without abandoning their PHP toolkit 

©Fusic Co., Ltd. 21 Achieving Production PHP on AWS Lambda Production Launch Shared our first fully serverless Laravel workload at AWS Dev Day 2022 Pipeline ingests multi-gigabyte CSV files delivered daily S3 Select Advantage Filtered data inside Amazon S3 so Lambda processed only relevant rows Stabilized runtime and memory even as throughput surged Measured Outcomes Processing time stayed under five minutes with predictable cost per run Freed developers from scaling ops while supporting rapid business growth 

©Fusic Co., Ltd. 22 We later succeeded in other teams as well Built by junior members using AWS Lambda x PHP Having Laravel knowledge, they built it as usual I was able to have other members build it Once the foundation is built, team adoption and operations are possible 

©Fusic Co., Ltd. 23 However 

©Fusic Co., Ltd. 24 The Lambda Monolith The Amazon Web Services blog article 'Operating Lambda: Anti-Patterns in Event-Driven Architectures – Part 3' mentions the following: -The Lambda Monolith -Package size -Difficult to apply least privilege -Difficult to upgrade -Difficult to maintain -The following do not apply: -Difficult code reuse: Laravel excels at this -Difficult testing: Laravel excels at this Reference: https://aws.amazon.com/blogs/compute/operating-lambda-anti-patterns-in-event-driven-architectures-part-3/ Operating Lambda: Anti-Patterns in Event-Driven Architectures – Part 3 

©Fusic Co., Ltd. 25 The Lambda monolith Reference : https://docs.aws.amazon.com/lambda/latest/operatorguide/monolith.html 「The Lambda monolith」 

©Fusic Co., Ltd. 26 Teams Can Benefit from Serverless Value Pragmatic Fit Maybe not the archetypal Lambda design, but it was the right choice for our Laravel teams Prioritized shared ownership and delivery speed over theoretical purity Team Culture Alignment Developers stayed within tooling they already trusted Confidence grew because platform patterns matched their habits Key Insight Serverless success is measured by team adoption, not architectural orthodoxy 

©Fusic Co., Ltd. 27 Understanding Characteristics and Addressing Concerns Benefit Kept Risk Observed Mitigation Applied Productivity from Laravel monolith Large deployment package size Lean dependencies, shared layers, automated bundle checks Unified codebase for web + admin Least-privilege IAM granularity Split admin endpoints with distinct IAM roles Reusable testing strategy Cold-start sensitivity Provisioned concurrency for critical paths, lazy load heavy providers 

©Fusic Co., Ltd. 28 A Configuration That Fits Teams Delivering Serverless Value I understood why it wasn't spreading Spreading this configuration across teams 

©Fusic Co., Ltd. 29 Our Platform Engineering Challenge to Bridge Teams and Serverless 4 

©Fusic Co., Ltd. 30 What is Platform Engineering? Building and maintaining development infrastructure, standardizing tools and processes Aimed at improving developer experience and reducing operational burden 

©Fusic Co., Ltd. 31 CNCF Platforms White Paper Like serverless, CNCF has published a white paper on this 

©Fusic Co., Ltd. 32 Platform Engineering On Serverless Reference:https://speakerdeck.com/_kensh/platform-engineering-on-serverless @_kensh 

©Fusic Co., Ltd. 33 Team Topologies Quote: Matthew Skelton, Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow “Make the platform not 'get in the way' of development teams. Reduce the prerequisites that development teams need to handle when shipping features.” → Reducing cognitive load - Stream-Aligned Teams - Teams focused on specific products or features -Platform Teams -Teams providing common services and tools 

©Fusic Co., Ltd. 34 Conway's Law and Inverse Conway's Law Conway's Law Systems designed by organizations reflect their communication structures Inverse Conway's Law Design organizational structure to achieve the desired system architecture While ideal to restructure organizations for cloud-native architecture, realistically, organizational restructuring beyond my authority is difficult and time-consuming Based on Conway's Law, aligned with the organization's tech stack, we consider Platform Engineering providing serverless system architecture 

©Fusic Co., Ltd. 35 Typical Serverless Architecture on AWS Natural serverless architecture configuration Forcing this configuration increases cognitive load and doesn't promote serverless adoption 

©Fusic Co., Ltd. 36 Configuration Combining Our Strengths Reconsidering configurations we excel at A low-cognitive-load configuration reflecting organizational structure and team communication 

©Fusic Co., Ltd. 37 Applying the Essence of Platform Engineering To a configuration reflecting organizational structure and communication, we adapt the serverless architecture side We adopted TiDB Serverless to merge our accumulated knowledge with our tech stack MySQL-compatible with an interface enabling natural development using SQL contributing to cost benefits 

©Fusic Co., Ltd. 38 Stream-Aligned Team Development with Natural Configuration Developer Experience Paved Road Docker Compose bundles Laravel, MySQL, and LocalStack for local parity Teams run familiar artisan commands, Pest tests, and npm scripts Seamless Handoff to Cloud Bref packaging mirrors local structure, so deploys feel natural Consistent environment variables and secrets management across stages Outcome Developers stay in their flow while platform engineering handles the heavy lifting 

©Fusic Co., Ltd. 39 Our Platform Engineering Journey Application developers choose platforms → We build platforms aligned with the company's tech stack for natural adoption I had been leading serverless development but progress was made without my direct involvement One of the goals of Platform Engineering achieving cognitive load reduction 

©Fusic Co., Ltd. 40 Platform Engineering On Serverless Operational Guardrails Structured logs land in CloudWatch with shared taxonomy Sentry traces link deployments to runtime behavior for faster triage Slack alerts include runbook links to prevent alert fatigue Visibility & Cost Control Dashboards track latency, cold starts, and cost per request in one view Promotion gates ensure every environment stays healthy before production 

©Fusic Co., Ltd. 41 Challenges in Interaction Modes -Collaboration -Working closely with other teams -X as a Service -Using or providing something with minimal collaboration -Facilitation -Supporting or being supported by other teams to remove obstacles Ideally, all interactions would be provided as X as a Service, but currently I'm personally collaborating and facilitating (risk of management explosion) The ultimate goal is for the platform to function even in projects without me Quote: Matthew Skelton, Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow 

©Fusic Co., Ltd. 42 Making Serverless Assimilate with Teams Assimilation Principles Embed serverless patterns into sprint rituals and onboarding checklists Keep platform APIs opinionated so best practices become defaults Developer-Focused Outcomes Reduce cognitive load every quarter through tooling and documentation updates Measure success by how confidently teams ship without platform hand-holding 

©Fusic Co., Ltd. 43 Team Adoption with Continuity in Mind Phase 1 – Adopt Start with Laravel + Bref templates and guided pilots to build confidence Phase 2 – Normalize Automate testing, deployment, and observability so teams rely on the platform by default Phase 3 – Scale Expand self-service patterns across products while revisiting culture, runbooks, and ownership Serverless that Fits Your Team, Built for Continuity 

OSEKKAI × TECHNOLOGY ココロと技術で、ぴったりも、びっくりも。 Thank You ご清聴いただきありがとうございました