无服务器框架针对DevOps带入新层面

　　欢迎各位阅读本篇文章，无服务器架构很多方面让人欣喜，如果不是感觉这种技术为我们做出了很多美妙承诺，我根本不愿意花时间介绍，但各种优势和收益都是需要付出代价的。本篇文章讲述了无服务器框架针对DevOps带入新层面，大家一定要认真阅读哦~

　　无服务器架构近在眼前无服务器计算正改变着软件系统构建和运营的方式。尽管它是IT行业中一个相对较新的领域，但它可能会大大改变软件行业业务价值的交付方式。它可以使用可用和可扩展的云端负载来以较低的成本运行项目，这对许多产品类型和业务用例来说是一种理想的方式。

　　但无服务器架构不仅仅只改变了软件交付的方式，它还会改变软件开发组织本身，相信这点对IT行业产生的影响将更加深远。在本文中，我们将探讨无服务器架构如何改变那些用其发布软件的组织的文化，以及它是如何影响整个行业的未来的。

　　DevOps目前的状态：

　　在过去几年没有太脱离业界环境的人，一定听说过DevOps。DevOps运动将敏捷软件开发融入并扩展到IT运营领域，旨在通过促进开发和运营团队之间的强力协作并采用新颖的运营实践来提供更高的业务敏捷性，尤其是在基础设施配置、改进发布管理和运营工具方面。

　　事实上，DevOps正在成为IT行业的新标准，并且已经被业界广泛采纳，常见于云计算和容器技术。同时，许多组织正尽力去理解DevOps的全貌，这主要受限于他们专业知识上的缺乏和各种组织结构上的挑战。尽管面对这些挑战，DevOps正在成为一个主流运动，它正改变着IT组织发布软件的方式，这就像敏捷运动在过去十多年中所产生的影响。

　　但是，无服务器架构是如何适应DevOps文化的?它将如何影响常规的DevOps实践呢?

　　为什么要选择无服务器架构?

　　为了了解无服务器架构是怎样影响那些使用它的组织的，让我们首先来看看用它进行构建和运行软件系统所具备的关键特性。

　　功能即服务(FaaS)提供了一个托管的运行时，用于执行任何已经上传到服务上的代码。这可能看起来就像将可运行的项目部署到计算机实例或服务器上，并在操作系统上执行它，但实际上这并不相同。FaaS在保证功能在满足当前需求规模下可用的同时，只以执行次数和运行时间收取费用。同时它会抽象出实际的运行时(如java虚拟机或NodeJS)和操作系统本身的配置。在其背后，运行时进程、操作系统和计算实例还是在运行着的(不要被“无服务器”这个名字蒙骗了)，但开发人员不再需要担心这些因素了。

　　这正是无服务器架构的优点，整个计算堆栈，包括运行功能代码的操作系统进程，完全由云提供商管理。与传统的基础架构即服务(IaaS)模型相比，这种方式大大简化了运算基础架构的管理，并结合了按使用进行收费的计费模式，提供了非常灵活且经济的运算选型。

　　快速开发：

　　除了FaaS计算(如AWS Lambda、Azure Functions以及Google Functions)之外，公共云提供商还提供了一系列其他服务用于组合并创建无服务器架构。从可伸缩的持久化存储和消息中间件，到API网关和内容分发网络，如今想要构建一个完整的系统完全不需要直接摆弄服务器。

　　每个云提供商的服务都可以通过其提供的软件开发工具包(SDK)进行全方位的配置，可以用其快速地发布产品来提供业务价值，前提是你要熟悉可用的服务及其配置选项。每个功能往往只负责处理简单的事件或请求，因此通常它们不需要大量代码，小而集中的业务逻辑就足够了。例如，一个功能可能只负责根据数据库表中的触发器，将变化信息推送到用户的电子邮件或相应的消息队列上，让其他子系统可以使用这个通知来更新外部系统。

　　然后，许多这样的功能用于实现业务逻辑及连接服务，从而提供了持久化、消息、集成、内容分发、机器学习等基本功能。这些服务解决了许多复杂的项目问题，并可以用其来创建复杂的解决方案而不会碰到太多困难，进而可以快速进行原型设计并开发。

　　从一开始就考虑维护性：

　　使用了无服务器架构，就不可能在不考虑代码执行方式以及其他所需资源的情况下开始编写代码，至少这样做毫无意义。毕竟，为了了解代码如何与API网关、数据存储或消息中间件交互，首先必须部署代码，还要配置所有相关资源。虽然，可以使用模拟，而不通过真实的部署来执行代码，但这只提供了有限程度的验证，况且，这样不会运行该功能所需的整个基础架构堆栈。

　　无服务器架构需要配置好云资源这点可以说有利也有弊。那些习惯于使用自己机器，在本地开发模式下运行应用程序和系统的用户，很可能会因为较长的反馈周期而损失部分生产力。基础设施配置和代码部署确实需要更多的时间，但并不会像 IaaS一样多，后者还要算上按需启动计算实例的时间。

　　从一开始就强制关注基础设施堆栈的主要好处是，能早在编写代码的时候，就考虑基础架构设置和配置机制。这与现在仍常见的传统方法不同，常常开发人员编写代码，并借助于持续集成工具进行打包，然后将其转交给运营团队进行部署，在这个过程中会假设不用考虑网络基础设施的问题。DevOps运动促进了开发和运营团队之间的合作，而在无服务器架构中，他们就根本不可能被分开。

　　在无服务器架构中，即使部署一个简单的功能，也需要对一些运营和财务方面的关键问题作出决定。两个最基本的配置选项就是可用内存和超时时间(即功能调用的预估时间)。这两个设置都会影响调用所需的花费，因为它是按照内存消耗和执行时间来收费的。此外，分配的内存通常与功能运行的计算实例相关联，更多的内存就意味着更多的处理能力。

　　由于需要这么多次对功能的配置调优，根据可用的预算及期望和观察到的性能特性对设置进行快速地调整就极为重要了。这些特性可以通过云提供商收集并公开的指标进行确定，AWS CloudWatch就是一个监控服务的例子。实际上，在构建无服务器架构时拥有丰富的FaaS和其他服务的指标对于是否可以运营这个架构至关重要。由于在配置资源后立即可以得到这些指标，所以在开发阶段就可以，也应该考虑架构的许多运营问题，如性能优化、容量规划、监控和记录。

　　安全性是软件交付方面另一个很好的例子，通常它是被放在项目后期来解决的，或被委派给专门的安全团队来处理，在部署到生产环境之前由他们对所有软件组件进行评估和签发。在无服务器架构中，在常规开发活动部署的一开始，就必须考虑安全性。至少每个功能必须有与之相关联的安全策略。由于一个功能可以被同账户下的任何其他资源所访问到，所以花费一些时间来确定并配置正确的基于任务的功能安全策略很有必要。理想情况下，按照最小权限的原则，一个功能应该被赋予它所需的最小权限集。例如，需要查询数据库表的功能只能具有查询相关表的权限。

　　显然，无服务器架构应该使可维护性(包括安全性)成为正常开发周期的一部分，而不是将这些要素推迟到运营团队参与后再进行，不然就会失去解决问题的最佳时机。当谈到无服务器架构时，DevOps的思想并不是用来被逐步接受的(通常这样会代来巨大的痛苦)，而是需要刻在其底层的基因上。

　　按使用收费：

　　与IaaS计算模型相比，无服务器架构带来了另一个革命性的变化，即对单个功能调用进行收费的定价模型，而不必为保持服务器运行进行付费。

　　使用公共云的组织更习惯于将云基础设施成本看作运营支出(OPEX)而不是资本支出(CAPEX)，但是在IaaS架构中，他们最终往往会进行大量前期投资以降低总成本，例如预留计算实例或购买其他云服务的预留容量。而在无服务器架构中，这就不必要也不经济了，因为只对功能调用进行支付比保持服务器持续运行会便宜许多。

　　由于用于构建无服务器架构的大部分服务都是按使用进行计费的，这样就可以运行多个环境以支持软件交付涉及的开发、测试和操作活动。毕竟，如果不进行调用，就不会产生很多花费，甚至根本不需要支出。无服务器架构在成本上的影响正在消除DevOps在许多公司实践过程中的诸多障碍。

　　能够拥有尽可能多的环境来满足各种团队或业务利益相关者的需求，会带来一些新的巨大的可能性。例如，每个开发人员可以在云上拥有个人的开发环境，或者正在开发的每个功能都可以部署到专用环境中，从而可以独立于其他任何任务进行演示。这样的独立环境甚至可以在单独的提供者帐户上托管，以提供终极的隔离。

　　持续部署将成为新常态：

　　持续交付是使DevOps可行的关键功能之一，但对许多公司来说，尤其是在企业领域，这点仍然相当难以实现。虽然持续交付提供了许多好处，并实现了更高的业务敏捷性，但它没能了解到组织的全部潜力。

　　无服务器架构可以用来实现业务灵活性的最高境界，即持续部署。持续部署让任何合并到主干中的代码更改都自动升级到包括生产在内的所有环境。为了让这种方式在不影响用户的情况下工作，持续部署的系统显然需要从不同的角度进行严格的质量检查。

　　鉴于诸如基础架构配置和安全性等运营问题可以也应该在功能代码的开发阶段解决，基础设施堆栈就可以从一开始就配置好，或根据源代码仓库中包含的代码和配置进行更新。这些堆栈可以由提供商提供的原生工具(如AWS的Cloud Formation)，或其他通用工具(如Hashicorp Terraform)进行管理。

　　通过全自动化的基础设施堆栈的配置和代码部署，就可以对任何环境进行应用或取消(回滚)变更，当然这其中也包括生产环境这一环节。为了保证万无一失，在部署或整个流程结束后需要自动在各个相关环境运行那些确保系统质量的测试案例，包括功能性和非功能性的测试。

　　每个人都是云工程师：

　　无服务器架构模糊了软件交付过程中常涉及的各类技术角色之间的界限。传统的架构师、开发人员、测试人员、数据库管理员、运营和安全工程师将共同合作来发布系统并维护生产环境，在无服务器架构的世界中，这些角色都会被合并为云工程师。

　　正如许多传统开发过程已被移除或被大大简化一样，如今已经不再需要在项目中引入诸多专家。相反，具有广泛技能且熟悉云提供商平台的工程师就可以完成这些工作，甚至更多，同时也可以做得更快。许多开发和运营过程可以被合并到同一个周期内，并且可以完全消除昂贵的交接或从外部借用资源的成本。

　　但这并不意味着团队中不再拥有专门从事特定领域的人员，毕竟每个人会自然而然地更偏重于软件交付的某些方面，但理想情况下，团队中的每个成员都应该能够参与到发布一个功能的所有流程中，包括在生产环境中进行运营。这是激励所有工程师能在一开始就构建一个可维护的高质量软件的最佳方法。

　　实际上，与那些谈论着要拉近开发和运营距离的团队不同，使用无服务器的团队天生就有着DevOps的文化，即软件在开始构建阶段就准备着运行在生产环境中。

　　适者生存：

　　无服务器架构可以用来实现终极的业务敏捷性。然而，这完全取决于组织理解无服务器架构全貌的能力。虽然许多组织仍在努力建立某种形式的DevOps文化和实践，无服务器架构提供了一种全新的方式来创建快速业务价值交付和稳定运营的文化，同时最大限度地降低成本。

　　并没有多少组织可以接受无服务器架构这个新领域所带来的挑战，因为整个领域仍然非常年轻并且还不成熟，所以要接纳它真的需要很大的勇气，因此需要大量额外的工作来弥补目前初级阶段所带来的差距及挑战。很多健全且愿意采纳无服务器架构的组织，可能会发现自己还在试图套用他们现有的流程和组织结构，并且失去他们已有的敏捷性，或更糟糕的是，还在建立和运行无服务器架构上花费了大量的精力。

　　那些希望能够充分利用无服务器架构来获得在市场中竞争优势的公司，可能不仅需要调整他们提供软件的方式，还需要改变其产品的创建和销售方式。

　　结论：

　　无服务器架构不仅补充了DevOps的理念，更改进了当前IT组织实现更高业务敏捷性的观念。它致力于快速交付商业价值并持续改进和学习，这极有可能会带来文化上大范围的改变，甚至对那些已采用了DevOps文化和实践的组织也不例外。

　　使用无服务器架构不仅可以使组织更快更省地提供新产品和功能。它还将改变整个流程中的内在文化。

　　知识分享：

　　无服务器架构是指大量依赖第三方服务(也叫做后端即服务，即“BaaS”)或暂存容器中运行的自定义代码(函数即服务，即“FaaS”)的应用程序，AWS Lambda是目前最著名的供应商。通过采用这样的方式并将大部分行为移至前端，这种架构使得应用程序内部不再需要具备传统的“始终运行”的服务器系统。取决于具体情况，尽管对供应商依赖增加了，并且(目前)配套服务还不成熟，但此类系统依然可以大幅降低运维成本和复杂度。

　　无服务器是软件架构世界中的热门话题。在这一领域我们已经看到很多书籍、开源框架、大量不同类型的供应商和产品，甚至专门的会议活动。但无服务器到底是什么，为什么值得(或不值得)考虑该技术?通过出版物的进化这篇文章，希望能针对这些问题向你提供一些启发。

　　首先我们要介绍无服务器到底是“什么”，在介绍这种技术的优势和劣势时我会尽量保持中立。

　　无服务器是什么?与软件行业很多其他趋势类似，关于“无服务器”到底是什么并没有一个清晰直观的看法，而涉及到两个截然不同但又相互重叠的领域后，问题就更突出了：

　　“无服务器”这个称呼最早被用于描述大量或完全依赖(“位于云中的”)第三方应用程序/服务管理服务器端逻辑和状态的应用程序。这些程序通常是使用可通过云访问的数据库(例如Parse、Firebase)、身份验证服务(例如Auth0、AWS Cognito)等庞大生态系统的“富客户端”应用程序(例如只包含一个页面的Web应用或移动应用)。这类服务以往也被叫做“(移动)后端即服务”，

　　“无服务器”也可以指部分服务器端逻辑依然由应用程序开发者来编写的应用程序，但与传统架构的不同之处在于，这些逻辑运行在完全由第三方管理，由事件触发的无状态(Stateless)暂存(可能只存在于一次调用的过程中)计算容器内。(感谢ThoughtWorks在他们最近的Tech Radar中对这种情况的定义。)这种做法可以看作“函数即服务/FaaS”。AWS Lambda是目前最流行的FaaS实现，但除此之外也有其他实现。下文将使用“FaaS”作为无服务器这种运用方式的简称。

　　小结：其中一些代价是这种概念与生俱来的，无法通过进一步发展彻底解决，考虑使用无服务器技术时绝对不能忽略这些问题。另外有些代价来自无服务器技术目前的实现，随着进一步完善这些问题有望得到顺利解决。当然如果大家还想了解更多相关方面的详细内容的话呢，课课家教育平台欢迎大家咨询~