当开发者想要开发无服务器和云原生应用时，一个常见的问题是： 这方面的开发体验到底怎么样呢 ？这个问题很很重要，因为良好的开发体验和快捷的反馈通道会让开发者更开心、更有生产力，从而能够快速交付特性。
由于我们在建立 Plain 时有意缩小规模，所以我们必须有出色的开发体验。我们需要确保公司聘请的少数几位工程师能够在保持高质量的同时快速交付产品特性，产生最大的影响力。
2021 年我们有了时间去思考这个问题的解决方案，因为 Plain 是从头开始建立的。在我们选择常用的技术栈时，一方面要考虑到公司每天都会做变更，另一方面我们希望基础平台能够支持未来 5-10 年的业务成长与成就。这意味着平台应该能以较低的成本大规模运行我们的服务，而不需要专门划分出一个部门来管理自主研发的基础设施。
作出这些决策背后的理由肯定需要单独写文章来谈了，不过我们最终决定完全投入 无服务器 和云原生、 全栈 TypeScript ，并 使用 AWS 作为我们的云供应商 ，因为它足够成熟也非常流行。我们认为，使用 AWS 的专有服务是一种可以接受的供应商锁定权衡，因为相比更换云供应商的自由度来说，从这一决策中获得的价值是更高的。我确实看到过一些公司花了大量精力去尝试做跨云（cloud-agnostic，云不可知），但实际上并没有从中得到任何现实收益。
无服务器开发的独特之处
无服务器应用程序的开发和测试工作有一些独特的要素。与传统开发相比的一大区别在于，你最终会使用大量云服务，并会尽量把责任卸载给无服务器解决方案。
就 AWS Lambda 而言，这意味着你最后往往会使用 API Gateway、DynamoDB、SQS、SNS、S3、EventBridge、ElastiCache 等来构建你的应用。使用这么多服务需要开发、测试和部署大量配置、权限和基础设施。如果你只关心你的 lambda 代码的测试工作，那么就会略过很大一部分特性。如果你不验证你的基础设施，可能会遇到以下情况：
你要回答的一个最重要的问题是： 你想要什么时候发现这些错误 ？
我们的选择是越早越好： 在编写和运行测试时 。这意味着，“你应该 mock 云的依赖项还是拥抱云“这个争论其实并不是一个问题。如果让我们的 Lambda 使用 AWS mock 或一些 localhost 仿真，在部署时还是很难做到无条件正常运行。Gareth McCumskey 的“为什么无服务器的本地部署是一种反模式”这篇博文为“模拟还是上云“的争论给出了很好的答案，我强烈推荐大家阅读。
云端开发带来的最大影响是需要互联网接入来编写代码。虽然这对某些公司或人们来说可能是一个不可接受的权衡，但对我们这家远程优先的公司来说，我们本来就需要互联网接入来与同事沟通，因此很少会出现无法接入网络的情况。
本着我们希望进行云端开发，而们开始评估各种工具和技术，以找出适合我们的方法。
