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
'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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
seike460
irof
shimoju
cocoeyes02
nealle
hollycummins
kasacchiful
neginasu
javiergs
akidon0000
da1chi
ryo_manba
bluesmoon
bkeepers
chrislema
lynnandtonic
brad_frost
mongodb
csswizardry
kneath
addyosmani
eitanlees
garrettdimon
