Eliana Lam for AWS Community On Air

Posted on Nov 17

Team-First Serverless Engineering with Laravel & Bref

#aws #beginners #cloud #productivity

Speaker: Shiro Seike @ AWS Community Day Hong Kong 2025

Summary by Amazon Nova

https://www.youtube.com/watch?v=41JNqwdVmfk

Serverless Development in Platform Engineering Approach

CNCF Definition: Building and running applications without managing servers.
Benefits:
[ 1 ] Reduced operational overhead.
[ 2 ] Lower costs.
[ 3 ] Faster development experience.
[ 4 ] Relief from server provisioning.

Goals and Rules for Adoption

[ 1 ] Goals:
Solve real customer problems.
[ 2 ] Rules:
Create real value.
Fit how PHP teams work.
Be maintainable by the whole team, not just one person.

Case Studies and Lessons Learned

[ 1 ] Simple API for Partner Data:
Used API Gateway and Lambda to save data to S3.
Success in terms of traffic growth (200 times) without performance issues.
Hidden Problem: Only one person could maintain it.
Lesson: The issue was not the language (Python) but a clash with team culture and unfamiliar tools.
[ 2 ] Serverless Platform for Machine Learning:
Saved money and was loved by data scientists.
Problem: The general development team couldn’t use it.
Lesson: Needed a solution for the main group of developers, not just specialists.
[ 3 ] AWS Amplify:
Details on the AWS Amplify experiment were cut off, but presumably it was another attempt to find a sustainable serverless solution for the broader team.

Key Takeaways

[ 1 ] Shared Ownership:
True success requires shared ownership and respect for the team's culture.
[ 2 ] Fit for Team:
Solutions must fit the way the team works and be maintainable by the entire team.

Conclusion

The journey towards effective serverless adoption involves understanding and respecting team culture, ensuring maintainability, and creating real value for all stakeholders.

Challenges with New Prototypes

[ 1 ] Initial Reaction:
New prototypes using serverless were met with resistance from lab teams due to deviation from their established "muscle memory" with familiar tools.
[ 2 ] Lesson Learned:
Trust and comfort with familiar tools are crucial before introducing major changes.

Contrasting Team Experiences

[ 1 ] Ruby Team:
Successfully adopted serverless.
[ 2 ] PHP Teams:
Struggled due to high cognitive load.
[ 3 ] Realization:
The difference in success was attributed to the cognitive load and familiarity with tools.

New Strategy for Shifting to Platform Engineering

Move towards platform engineering to make serverless accessible and maintainable for the entire team.

Reevaluation of Goals

Old Goal: Merely shipping serverless projects.
New Goal: Shipping serverless projects that the entire team can operate.
Success Metric: Team confidence rather than the number of functions.

Making Serverless Work for PHP Teams

Need for Familiar Tools:
PHP developers needed tools they were comfortable with.
Custom Runtimes:
Began using custom runtimes for PHP on Lambda as early as 2018.

Solution: Laravel and Bref

[ 1 ] Laravel:
Developers already trusted and were familiar with Laravel.
[ 2 ] Bref:
Handled the complexities of running PHP on Lambda.
[ 3 ] Combined Solution:
Allowed maintaining existing workloads while testing and gaining serverless benefits.

First Production Application

[ 1 ] Application:
Processing large CSV files.
[ 2 ] Tech Stack:
Used Amazon S3 Select to filter data in Lambda, ensuring predictable performance.
[ 3 ] Results:
Fast processing times and eliminated server management.

Team Adoption and Success

[ 1 ] Junior Developers:
Could develop and deploy serverless apps by following documentation.
[ 2 ] Role Change:
Your role shifted from being a bottleneck to a coach.
[ 3 ] Repeatability:
The approach became repeatable and no longer dependent on a single expert.

Conclusion

The journey to successful serverless adoption required understanding team dynamics, leveraging familiar tools, and fostering an environment where the entire team could confidently operate serverless applications.

New Challenges with Serverless

Serverless-Specific Issues:
Cold starts, timeouts, and memory limits.
Running a whole Laravel app in one Lambda (Lambda Lift) introduced challenges like large package sizes and complex permissions.

Practical Solutions

[ 1 ] Mitigations:
Used Lambda Layers and separate IAM roles for sensitive functions.
Adopted production concurrency for timers and an event-driven approach to manage cold starts.
[ 2 ] Validation:
Discussions and validation from respected engineers confirmed the practicality of running monoliths on Lambda.

Lessons Learned

[ 1 ] Microservices vs. Monolith:
A perfect microservices architecture isn’t always necessary.
For the teams, Lambda Lift was a practical choice that allowed shared ownership and quick feature releases.
[ 2 ] Team Confidence:
More important than specific architectures.

Scaling the Solution

Reusable Templates and Standard Commands:
Created reusable templates and standard commands to ensure new teams didn’t have to start from scratch.
Reduced support load on the platform team.

Platform Engineering

[ 1 ] Definition:
Building shared services to help development teams ship features faster with less cognitive load.
[ 2 ] Guiding Principles:
Followed industry best practices like the CNCF white paper on platforms.
[ 3 ] Team Topologies Model:
The goal was to let future teams focus on features while the platform team reduced their cognitive load by providing standard solutions for common problems.

Designing the Platform

[ 1 ] Fitting Existing Teams:
Designed the platform to fit the existing team structure and culture.
[ 2 ] Reducing Cognitive Load:
Avoided complex serverless architectures that would create fear.
Used load balancers to route traffic to the right computing target (e.g., familiar Lambda for PHP teams).
[ 3 ] Database Choice:
Selected TiDB, a MySQL-compatible service, to allow developers to use familiar SQL commands with minimal changes.

Local Development Experience

Tools:
Used Docker and LocalStack to allow developers to run the entire application on their laptops using the same PHP commands.
Dramatically lowered the friction of adoption.

Transformational Results

[ 1 ] Role Change:
Your role shifted from a bottleneck to an enabler.
[ 2 ] Scaling Success:
Scaled the pattern across teams.
Onboarding new teams to serverless projects became dramatically faster.

Conclusion

The platform engineering approach transformed the team's ability to adopt and scale serverless technologies by focusing on reducing cognitive load, leveraging familiar tools, and providing reusable templates and standard solutions.

Platform Key characteristics

[ 1 ] Self-Service System
Commands and automated CI/CD pipelines.
Removes support tickets and allows developers to focus on their work.
[ 2 ] Guard Rails
Tools like structured logging and Sentry with alerts.
Includes Lambda functions with guidance on how to solve problems.

Evolution of the Platform

Initial Stage: Heavy collaboration.
Current Stage: Moving towards a "X as a Service" model where the platform is a self-service product.
Goal: Make self-service a natural part of the culture.

Ongoing Efforts

Process Integration:
Include serverless patterns in sprint planning, code reviews, and retrospectives.
Ensure the whole team feels confident with the system.

Roadmap in Three Steps