云计算未来趋势：无服务器架构
无服务器计算正改变着软件系统构建和运营的方式。尽管它是 IT 行业中一个相对较新的领域，但它可能会大大改变软件行业业务价值的交付方式。它可以使用可用和可扩展的云端负载来以较低的成本运行项目，这对许多产品类型和业务用例来说是一种理想的方式。本文部分参考于《Linux就该这么学》。希望对于大家的理解有帮助。
操作方法
- 01
本文要点 许多组织仍在努力接纳 DevOps。无服务器架构并不只是简单接纳了 DevOps 文化，DevOps 已经成为该架构基因中的一部分。无服务器架构首要考虑的就是项目的可维护性，并将其融入到开发流程中。将来许多 IT 专家会被具备广泛技能的云工程师所取代。无服务器架构会改变 IT 组织的内部文化，还会影响公司对云计算的使用方式。
- 02
无服务器架构近在眼前 无服务器计算正改变着软件系统构建和运营的方式。尽管它是 IT 行业中一个相对较新的领域，但它可能会大大改变软件行业业务价值的交付方式。它可以使用可用和可扩展的云端负载来以较低的成本运行项目，这对许多产品类型和业务用例来说是一种理想的方式。
- 03
但无服务器架构不仅仅只改变了软件交付的方式，它还会改变软件开发组织本身，相信这点对 IT 行业产生的影响将更加深远。在本文中，我们将探讨无服务器架构如何改变那些用其发布软件的组织的文化，以及它是如何影响整个行业的未来的。
- 04
DevOps 目前的状态 在过去几年没有太脱离业界环境的人，一定听说过 DevOps。DevOps 运动将敏捷软件开发融入并扩展到 IT 运营领域，旨在通过促进开发和运营团队之间的强力协作并采用新颖的运营实践来提供更高的业务敏捷性，尤其是在基础设施配置、改进发布管理和运营工具方面。
- 05
事实上，DevOps 正在成为 IT 行业的新标准，并且已经被业界广泛采纳，常见于云计算和容器技术。同时，许多组织正尽力去理解 DevOps 的全貌，这主要受限于他们专业知识上的缺乏和各种组织结构上的挑战。尽管面对这些挑战，DevOps 正在成为一个主流运动，它正改变着 IT 组织发布软件的方式，这就像敏捷运动在过去十多年中所产生的影响。 但是，无服务器架构是如何适应 DevOps 文化的？它将如何影响常规的 DevOps 实践呢？
为什么要选择无服务器架构？
- 01
为了了解无服务器架构是怎样影响那些使用它的组织的，让我们首先来看看用它进行构建和运行软件系统所具备的关键特性。
- 02
功能即服务（FaaS）提供了一个托管的运行时，用于执行任何已经上传到服务上的代码。这可能看起来就像将可运行的项目部署到计算机实例或服务器上，并在操作系统上执行它，但实际上这并不相同。FaaS 在保证功能在满足当前需求规模下可用的同时，只以执行次数和运行时间收取费用。同时它会抽象出实际的运行时（如 Java 虚拟机或 NodeJS）和操作系统本身的配置。在其背后，运行时进程、操作系统和计算实例还是在运行着的（不要被“无服务器”这个名字蒙骗了），但开发人员不再需要担心这些因素了。
- 03
这正是无服务器架构的优点，整个计算堆栈，包括运行功能代码的操作系统进程，完全由云提供商管理。与传统的基础架构即服务（IaaS）模型相比，这种方式大大简化了运算基础架构的管理，并结合了按使用进行收费的计费模式，提供了非常灵活且经济的运算选型。
从一开始就考虑维护性
- 01
使用了无服务器架构，就不可能在不考虑代码执行方式以及其他所需资源的情况下开始编写代码，至少这样做毫无意义。毕竟，为了了解代码如何与 API 网关、数据存储或消息中间件交互，首先必须部署代码，还要配置所有相关资源。虽然，可以使用模拟，而不通过真实的部署来执行代码，但这只提供了有限程度的验证，况且，这样不会运行该功能所需的整个基础架构堆栈。 无服务器架构需要配置好云资源这点可以说有利也有弊。那些习惯于使用自己机器，在本地开发模式下运行应用程序和系统的用户，很可能会因为较长的反馈周期而损失部分生产力。基础设施配置和代码部署确实需要更多的时间，但并不会像 IaaS 一样多，后者还要算上按需启动计算实例的时间。 从一开始就强制关注基础设施堆栈的主要好处是，能早在编写代码的时候，就考虑基础架构设置和配置机制。这与现在仍常见的传统方法不同，常常开发人员编写代码，并借助于持续集成工具进行打包，然后将其转交给运营团队进行部署，在这个过程中会假设不用考虑网络基础设施的问题。
- 02
DevOps 运动促进了开发和运营团队之间的合作，而在无服务器架构中，他们就根本不可能被分开。 在无服务器架构中，即使部署一个简单的功能，也需要对一些运营和财务方面的关键问题作出决定。两个最基本的配置选项就是可用内存和超时时间（即功能调用的预估时间）。这两个设置都会影响调用所需的花费，因为它是按照内存消耗和执行时间来收费的。此外，分配的内存通常与功能运行的计算实例相关联，更多的内存就意味着更多的处理能力。
- 03
由于需要这么多次对功能的配置调优，根据可用的预算及期望和观察到的性能特性对设置进行快速地调整就极为重要了。这些特性可以通过云提供商收集并公开的指标进行确定，AWS CloudWatch 就是一个监控服务的例子。实际上，在构建无服务器架构时拥有丰富的 FaaS 和其他服务的指标对于是否可以运营这个架构至关重要。由于在配置资源后立即可以得到这些指标，所以在开发阶段就可以，也应该考虑架构的许多运营问题，如性能优化、容量规划、监控和记录。
- 04
安全性是软件交付方面另一个很好的例子，通常它是被放在项目后期来解决的，或被委派给专门的安全团队来处理，在部署到生产环境之前由他们对所有软件组件进行评估和签发。在无服务器架构中，在常规开发活动部署的一开始，就必须考虑安全性。至少每个功能必须有与之相关联的安全策略。由于一个功能可以被同账户下的任何其他资源所访问到，所以花费一些时间来确定并配置正确的基于任务的功能安全策略很有必要。理想情况下，按照最小权限的原则，一个功能应该被赋予它所需的最小权限集。例如，需要查询数据库表的功能只能具有查询相关表的权限。
- 05
显然，无服务器架构应该使可维护性（包括安全性）成为正常开发周期的一部分，而不是将这些要素推迟到运营团队参与后再进行，不然就会失去解决问题的最佳时机。 当谈到无服务器架构时，DevOps 的思想并不是用来被逐步接受的（通常这样会代来巨大的痛苦），而是需要刻在其底层的基因上。
每个人都是云工程师
- 01
无服务器架构模糊了软件交付过程中常涉及的各类技术角色之间的界限。传统的架构师、开发人员、测试人员、数据库管理员、运营和安全工程师将共同合作来发布系统并维护生产环境，在无服务器架构的世界中，这些角色都会被合并为云工程师。
- 02
正如许多传统开发过程已被移除或被大大简化一样，如今已经不再需要在项目中引入诸多专家。相反，具有广泛技能且熟悉云提供商平台的工程师就可以完成这些工作，甚至更多，同时也可以做得更快。许多开发和运营过程可以被合并到同一个周期内，并且可以完全消除昂贵的交接或从外部借用资源的成本。
- 03
但这并不意味着团队中不再拥有专门从事特定领域的人员，毕竟每个人会自然而然地更偏重于软件交付的某些方面，但理想情况下，团队中的每个成员都应该能够参与到发布一个功能的所有流程中，包括在生产环境中进行运营。这是激励所有工程师能在一开始就构建一个可维护的高质量软件的最佳方法。
- 04
实际上，与那些谈论着要拉近开发和运营距离的团队不同，使用无服务器的团队天生就有着 DevOps 的文化，即软件在开始构建阶段就准备着运行在生产环境中。