以团队为先：使用 Laravel 与 Bref 开展无服务器工程

录像

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

采用平台工程方法进行无服务器开发

• CNCF 定义：无需管理服务器即可构建和运行应用程序。
• 优势：
• [ 1 ] 减少运维开销。
• [ 2 ] 降低成本。
• [ 3 ] 提供更高效的开发体验。
• [ 4 ] 免去服务器预置工作。

采用无服务器技术的目标与规则

• [ 1 ] 目标：
• 解决客户的实际问题。
• [ 2 ] 规则：
• 创造真正的价值。
• 符合 PHP 团队的工作方式。
• 整个团队都能维护，而不是只能由一个人维护。

案例研究与经验教训

• [ 1 ] 用于合作伙伴数据的简单 API：
• 使用 Amazon API Gateway 和 AWS Lambda 将数据保存到 Amazon S3。
• 流量增长了 200 倍，且未出现性能问题，取得了成功。
• 隐藏的问题：只有一个人能够维护。
• 经验：问题不在于编程语言（Python），而在于它与团队文化冲突，并且团队不熟悉相关工具。
• [ 2 ] 机器学习无服务器平台：
• 节省了成本，也深受数据科学家喜爱。
• 问题：普通开发团队无法使用它。
• 经验：需要为开发者主体提供解决方案，而不能只面向专家。
• [ 3 ] AWS Amplify：
• 有关 AWS Amplify 实验的详细内容未完整收录，但推测这也是一次尝试，目的是为更广泛的团队寻找可持续的无服务器解决方案。

核心要点

• [ 1 ] 共同负责：
• 真正的成功需要共同负责，并尊重团队文化。
• [ 2 ] 适合团队：
• 解决方案必须符合团队的工作方式，并且整个团队都能维护。

总结

• 要有效采用无服务器技术，需要理解并尊重团队文化、确保可维护性，并为所有利益相关方创造真正的价值。

新原型面临的挑战

• [ 1 ] 最初反应：
• 使用无服务器技术的新原型偏离了实验室团队使用熟悉工具所形成的“肌肉记忆”，因此遭到抵触。
• [ 2 ] 经验教训：
• 在引入重大变革之前，对熟悉工具的信任以及使用这些工具时的从容感至关重要。

不同团队的体验对比

• [ 1 ] Ruby 团队：
• 成功采用了无服务器技术。
• [ 2 ] PHP 团队：
• 因认知负荷较高而举步维艰。
• [ 3 ] 认识：
• 成败差异源于认知负荷以及团队对工具的熟悉程度。

转向平台工程的新策略

• 转向平台工程，让整个团队都能使用和维护无服务器技术。

重新评估目标

• 旧目标：仅仅交付无服务器项目。
• 新目标：交付整个团队都能运维的无服务器项目。
• 成功指标：团队信心，而不是函数数量。

让无服务器技术适用于 PHP 团队

• 需要熟悉的工具：
• PHP 开发者需要自己用得顺手的工具。
• 自定义运行时：
• 早在 2018 年就开始为 Lambda 上的 PHP 使用自定义运行时。

解决方案：Laravel 与 Bref

• [ 1 ] Laravel：
• 开发者已经信任并熟悉 Laravel。
• [ 2 ] Bref：
• 负责处理在 Lambda 上运行 PHP 的复杂问题。
• [ 3 ] 组合解决方案：
• 在维护现有工作负载的同时进行测试并获得无服务器技术的优势。

第一个生产应用程序

• [ 1 ] 应用程序：
• 处理大型 CSV 文件。
• [ 2 ] 技术栈：
• 使用 Amazon S3 Select 在 Lambda 中筛选数据，确保性能可预测。
• [ 3 ] 结果：
• 处理速度快，并且不再需要管理服务器。

团队采用情况与成功经验

• [ 1 ] 初级开发者：
• 能够按照文档开发和部署无服务器应用程序。
• [ 2 ] 角色转变：
• 你的角色从瓶颈转变为教练。
• [ 3 ] 可重复性：
• 这种方法可以重复应用，不再依赖单一专家。

总结

• 要成功采用无服务器技术，需要理解团队协作方式、利用熟悉的工具，并营造一种让整个团队都有信心运维无服务器应用程序的环境。

无服务器技术带来的新挑战

• 无服务器技术特有的问题：
• 冷启动、超时和内存限制。
• 在一个 Lambda 中运行完整的 Laravel 应用程序（Lambda Lift）会带来程序包体积较大、权限复杂等挑战。

实用解决方案

• [ 1 ] 缓解措施：
• 使用 Lambda Layers，并为敏感函数设置单独的 IAM 角色。
• 针对定时任务采用生产环境并发配置，并使用事件驱动方法来应对冷启动。
• [ 2 ] 验证：
• 与备受尊敬的工程师交流并得到他们的验证后，确认了在 Lambda 上运行单体应用的可行性。

经验教训

• [ 1 ] 微服务与单体架构：
• 并非总是需要完美的微服务架构。
• 对这些团队而言，Lambda Lift 是一个务实的选择，既能让团队共同负责，也能快速发布功能。
• [ 2 ] 团队信心：
• 比具体采用哪种架构更重要。

扩展解决方案

• 可复用模板与标准命令：
• 创建可复用模板和标准命令，确保新团队无需从零开始。
• 减少平台团队的支持负担。

平台工程

• [ 1 ] 定义：
• 构建共享服务，帮助开发团队以更低的认知负荷更快地交付功能。
• [ 2 ] 指导原则：
• 遵循平台相关 CNCF 白皮书等行业最佳实践。
• [ 3 ] Team Topologies 模型：
• 目标是让未来的团队专注于功能开发，同时由平台团队为常见问题提供标准解决方案，以降低他们的认知负荷。

平台设计

• [ 1 ] 适配现有团队：
• 平台设计应适应现有的团队结构和文化。
• [ 2 ] 降低认知负荷：
• 避免采用会让团队望而生畏的复杂无服务器架构。
• 使用负载均衡器将流量路由到适当的计算目标（例如 PHP 团队熟悉的 Lambda）。
• [ 3 ] 数据库选择：
• 选择与 MySQL 兼容的服务 TiDB，让开发者只需做少量更改即可继续使用熟悉的 SQL 命令。

本地开发体验

• 工具：
• 使用 Docker 和 LocalStack，让开发者可以在笔记本电脑上使用相同的 PHP 命令运行整个应用程序。
• 大幅降低了采用门槛。

转型成果

• [ 1 ] 角色转变：
• 你的角色从瓶颈转变为赋能者。
• [ 2 ] 规模化成功：
• 将这种模式推广到多个团队。
• 新团队接入无服务器项目的速度显著加快。

总结

• 平台工程方法专注于降低认知负荷、利用熟悉的工具，并提供可复用模板和标准解决方案，从而改变了团队采用无服务器技术并将其规模化的能力。

平台的关键特征

• [ 1 ] 自助服务系统
• 命令和自动化 CI/CD 流水线。
• 无需提交支持工单，让开发者能够专注于自己的工作。
• [ 2 ] 防护机制
• 结构化日志记录、带告警功能的 Sentry 等工具。
• 包含 Lambda 函数，并提供问题解决指南。

平台的演进

• 初始阶段：密切协作。
• 当前阶段：转向“X 即服务”模式，将平台打造为自助服务产品。
• 目标：让自助服务自然融入团队文化。

持续推进的工作

• 流程集成：
• 将无服务器模式纳入迭代规划、代码审查和回顾会议。
• 确保整个团队都有信心使用该系统。

三步路线图

• [ 1 ] 适应：
• 从模板和指导入手。
• [ 2 ] 标准化：
• 将测试和部署自动化，直至其成为标准做法。
• [ 3 ] 扩展：
• 将这种模式扩展至更多产品，并持续改进。
• [ 4 ] 成果：
• 这个简单的循环可提高团队生产力，帮助团队为未来做好准备。