后端即服务 - 公司的良好实践

多年来，公司一直对“后端即服务”(BaaS) 的概念不屑一顾。将[数据库3]和身份验证委托给第三方（例如 Google Firebase 或 AWS Amplify）的想法似乎来自初创公司或大学项目。

现在情况已经改变了。如今，财富 500 强公司使用 BaaS 在数周而不是数月内推出数字产品。问题不再是“是否”使用它，而是“如何”在公司治理和安全方面使用它。

在本指南中，我们将探索在企业环境中采用 BaaS 的最佳实践，而不会造成影子 IT 噩梦。

在企业环境中什么是 BaaS？

BaaS 是重复基础设施的外包。您无需让您的团队设置 Linux 服务器、安装 PostgreSQL、配置 Redis 和编写登录 API，而是通过 SDK 使用所有这些。

对于公司来说，BaaS 意味着专注于核心业务。如果您是一家银行，您的重点是金融交易，而不是设置电子邮件服务器。

最佳治理实践

1. 环境分离

初创公司通常在 Firebase 上有一个项目。公司不能。

• 创建独立项目：011、22。
• 使用基础设施即代码（Terraform 或 CLI 脚本）来复制配置。切勿通过手动单击控制台来配置生产环境。

2.访问控制（IAM）

谁可以删除[数据库4？

• 将 BaaS 与公司的身份提供商（Active Directory / Okta）集成。
• 仅向开发人员授予“读取”权限，仅向 CI/CD 系统授予“写入”权限。任何人都不应该在生产中拥有不受限制的“管理员”访问权限。

3. 备份和灾难恢复

“Firebase 会自我备份。”是的，也不是。 保证数据不会因硬件故障而消失。但如果开发人员运行了错误的脚本并删除了所有内容，Firebase 不会阻止它。

• 配置每日自动将数据导出到冷存储桶 (S3/GCS)。每季度测试一次恢复。

4. 供应商锁定（紧急出口）

企业最大的恐惧：“如果谷歌将价格提高 1000% 怎么办？”

• 不要将业务逻辑深入耦合到专有的云函数中。编写干净的代码（六角架构），其中 BaaS 只是基础设施细节。
• 如果数据主权至关重要，则首选开源解决方案（如 Supabase）。

公司什么时候不使用 BaaS？

• 复杂的遗留系统：尝试将 COBOL 大型机直接连接到 Firebase 会很痛苦。在两者之间使用 API 网关层。
• 严格监管：如果数据不能离开国家或公司的物理数据中心，则公共 BaaS 是不可能的（寻找自托管版本）。

结论

后端即服务是企业创新的秘密武器。它允许内部“小队”以启动速度运行。通过正确的治理实践，您可以两全其美：开发敏捷性和企业安全性。

另请阅读

• [后端即服务 - 初学者的良好实践5
• [后端即服务6
• [应用后端：小团队不能犯错误的良好实践77
• [可扩展的软件架构 - 扩展的最佳实践8
• [可扩展的软件架构-初创公司的最佳实践9
• [可扩展的软件架构-小型团队的最佳实践10