AWS Lambda 如何让我成为更好的云开发者？

原文：https://medium.com/hackernoon/how-aws-lambda-made-me-a-better-cloud-developer-b5898e2b31fd

AWS Lambda 对于 devops 和 REST APIs 来说都是一件大事。这是一个简单的承诺；不要一直运行一台机器在需要时进行计算，而是启动一台机器(快！)并在计算完成后释放它。运行状况检查、监控、扩展甚至安全(在某些情况下)问题都已成为过去，您有更多的资源来专注于您的价值主张。

在花了一些时间使用 Lambda 之后，我意识到它的随需应变的本质强制了良好的云开发规则，并使开发人员避免了一些常见的陷阱。

一切都是不稳定的

人们喜欢黑客，尤其是当东西着火的时候。当您的服务器开始停机时，“我将连接到服务器并更改/安装/停止 ____”将是您听到的第一个反应。您可以用一个配置、一个监控工具甚至一个小型本地数据库来填补这个空白。你应该说不。任何更改都不会被带到新的实例中，现有的和未来的实例将互不相同，最糟糕的是，如果您的设置包括自动缩放组，AWS 可能会选择关闭您最早的实例，当需要缩减时，它最有可能有额外的东西。

如果你想让某个东西在你的服务器上运行，它应该是你的 AWS AMI 的一部分，你所有的活动实例都应该用同一个 AMI 启动。您的实例永远不应该处理持久性，除非它们是专门设计来做这件事的，即使是小的静态东西。我还喜欢禁止基于密钥的 SSH 访问我管理的 ElasticBeanstalk 环境。

使用 Lambda，您无法访问系统的其他部分。你不能在本地保存东西，你不知道你的代码在哪里运行，所以你不能访问底层机器。你必须在范围内工作，并持久化 Lambda 之外的任何东西。

单一责任

当您有一台一直运行的机器并且没有大量请求时，在同一台机器上部署更多的东西是很诱人的。我说的不是改进相同的功能，而是在同一台机器上部署其他功能，甚至是不相关的系统。结果；单片应用程序和/或同一台机器上的多个应用程序，一个耦合和调试地狱。

有了 Lambda，你的代码与其他一切都是分离的，它只存在于执行的时候。

优化至关重要

Lambda 按执行次数、保留内存和执行持续时间定价。你需要确保你的 Lambda 代码在尽可能短的时间内运行，并且是轻量级内存。在 Lambda 中，几乎没有什么是过早的优化。

在新建后端的早期，需求可能不高，您可能会跳过优化客户端对后端的调用数量。除了产生扩展问题，未优化的移动客户端还会给用户带来隐藏的电池和网络成本。为了保持较低的 Lambda 调用次数，您可能希望从缓存开始。

永远不要假设任何事情

你可能不会在不久的将来寻求全球统治地位。您的服务器可能不是分布式的，并且您可能没有使用多个可用性区域。也许您关注的是地理位置，或者网络性能在您的小团队中并不重要。但是有一天这些将会成为你最关心的事情。您的代码应该完全独立于执行环境，并且可以部署到任何地方。

不要做任何假设，用 Lambda，你不能。