我以前的文章“ 无服务器计算将如何在2018年改变世界”已经看到了不可思议的流量，并在许多主要平台上引发了众多评论。 我震惊地发现它是1月1日在Medium上最受欢迎的文章之一 ！ 您可以在此处查看帖子：
尽管它在社区中受到了广泛好评，但它的确突出了人们仍在使用流行服务（如AWS的Lambda，Azure的Functions和Google的Function）所面临的许多痛点，这些服务显然已于去年11月发布！ （感谢斯蒂芬·泰勒指出这一点！）
在本文中，我想强调一些无服务器计算通常仍需要克服的关键挑战，以使其真正在软件开发领域中崭露头角。
延迟问题-冷与热
无服务器产品通常没有在待机状态下运行您的功能的副本，这意味着当有人按下该功能时，它会很冷。 这意味着您的代码需要先启动，然后再运行，而不是在命中之前已经运行代码的热命中。
无服务器提供商可能会开始提供潜在的付费服务，使您可以保持一定数量的功能热身。 这将有助于确保以较低的延迟响应来满足对您的服务的绝大多数请求。
您可能还会发现自己创建了定时lambda，随后调用了其他lambda以使它们变热。 但是，这样做的问题是，您在诸如CloudWatch之类的日志中将填充成千上万个虚拟请求，并且您必须以某种方式将其过滤掉，这会增加复杂性。
这不仅会增加您的日志记录系统的使用范围，而且还会影响成本，如果平均每个容器在被永久杀死之前可持续使用15分钟，那么您每天就会发现自己（24 * 4） API调用只是为了保持一个容器的生命一个 lambda函数。 随着您添加越来越多的服务，这很快就会扩大规模，一旦您摆脱了免费套餐，您可能会发现成本呈指数增长。
负荷预测
解决此问题的另一种潜在解决方案是使用一些精美的AI并利用负载预测系统，该系统将在认为您的服务即将承受巨大负载时进行分析。
如果它能够准确地预测这些峰值，那么它可以为多种不同的服务工作，并且可以帮助解决受到冷遇的问题。 至少它可以帮助减少您最终最终收到的冷伤次数。
但是，这样做的问题是它不会便宜。 您可能最终会为因过于乐观的算法而预热的闲置容器支付额外的费用，或者如果您的算法过于保守，您仍然会收到“总延迟”。 （感谢雅克！）
物业管理
随着无服务器架构的复杂性增加，管理无数不同端点和各种环境的任务也将随之增加。 这也是基于微服务的架构所面临的一个非常现实的问题，这也是采用Kubernetes之类的工具来通过代码协调对所有内容进行管理的原因。
由于https://github.com/apex/apex之类的项目可帮助您构建，部署和管理AWS Lambda函数，因此它们开始蓬勃发展。 这些将在2018年继续发展，并继续使使用Lambda的开发人员的生活变得更简单。
但是，随着时间的流逝，提供商本身需要向前迈出一大步，以从根本上改善此流程，以使采用率迅速上升。
本地可测试性
到目前为止，我最大的抱怨之一就是在本地测试lambda函数非常困难。 如果查看AWS的官方文档，您会发现他们建议您通过手动调用进行测试。
随着我们转向更高效的开发流，无法自动测试您正在构建的东西会很痛苦。 如果您必须维护数千个不同的Lambda函数，那么这将变得越来越复杂，并且需要一种解决方案，该解决方案将使您能够以最少的手动输入来自动测试这些功能。
尝试实现本地测试平台时的主要问题是几乎不可能尝试模拟这些功能将在其上运行的基础平台。
我担心这种唯一改善的方法是，无服务器提供程序实现一个体面的本机解决方案，该解决方案允许开发人员非常快速地迭代其代码库。
您花在管理任务上的时间越多，例如推动+手动触发lambda函数，则花费在为公司创造价值上的时间就越少。
当想到理想的解决方案时，我喜欢想象像我们如何测试Angular项目之类的东西。 您当前正在运行angular-cli命令ng test ，它将监视Angular项目中的更改，并在检测到任何更改时执行任何单元测试。
CI / CD管道投产
经常在很多评论中提到这一点，我觉得这有点不公平，因为AWS等无服务器提供商开始发布CodePipeline和CodeDeploy等工具。 这些工具可以与您的标准git repos结合使用，并且每次提交提交后，便可以将所有更改部署到dev / test / production中。
这是迈向更流畅的CI / CD体验的第一步，并且仍然需要做大量工作才能使开发人员和开发人员的亲身体验都更好。
结论
希望您发现本文很有见识！ 如果您有任何评论，请随时将其留在下面的评论部分或向我发送推文： Elliot Forbes 。 我也想加入LinkedIn 。
在2018年，我还将在我的YouTube频道上发布大量新视频内容： https ： //www.youtube.com/tutorialedg e。 订阅并查看我的视频为我提供支持！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
