一篇文章看懂无服务器计算的本质与未来

但是这种解决方案也有弱点.首先,执行测试的周期时间很有可能由于部署和网络延迟而相应增加.其次,当网络连接中断以后,我们就不可以继续运行测试用例了(例如,在飞机上).最后,因为生产环境和测试环境最终部署方案很相近,我们也需要格外小心,当我们打算改变测试用例时,不要发生不小心改变了生产环境的事故.如果我们使用AWS,我们可能需要通过类似于IAM角色这样的工具安全地部署,或者对于不同类型的环境使用完全不同的账号进行部署.

测试并不仅仅是一个二进制程序运行成功或者失败,我们也想要去弄清楚测试是如何失败的.我们应该可以调试本地运行测试和正在运行的远端组件,包括可以单步调试一个运行在AWS上的Lambda函数,因为它可以相应测试.所以所有的远端调试,我前面章节提到的工具也需要测试,而不是仅仅交互式开发.

请注意,我并不是基于这些暗示我们的开发工具需要运行在云端,也不是测试本身需要运行在云端,虽然两者将来都会或多或少地走到这一步.我只是表示正在测试的系统仅运行在云端,而不是一个非云端环境.

使用无服务器作为测试驱动环境可以收获有用的结果.一个例子被称为“无服务器火炮”,这是一种负载测试工具,由运行着的许多并行的AWS Lamdbas组成,执行即时、廉价、易于扩展性能测试规模的负载测试用例.

值得指出的是,在某种程度上,我们避免了一些失误.由于技术进步,传统的高层及测试实际上正在变得不那么重要,例如(a)生产环境测试/使用监控驱动开发,(b)平均解决时间(MTTR)的显著降低,(c)基于持续部署.对于许多的无服务器apps应用广泛的单元测试,度量业务水平的生产环境监控&预警,以及一个专用于减少MTTR和基于持续开发的方法,都将会是有效的代码验证策略.

架构：有很多问题需要回答

系统架构较好的无服务器应用程序是怎样的?是如何演变的?

我们正在逐渐看到一些无服务器被有效地应用的案例,即系统架构的学习案例正在逐渐增多,但是我们还没有看到针对无服务器Apps的“模式组”.在2000年早些时候,我们看到了一些这方面的书,比如Fowler的《Patterns Of Enterprise Application Architecture》,以及Hohpe / Woolf的《Enterprise Integration Patterns》.这些书着眼于很多项目,派生出横贯不同领域的通用系统架构知识.

重要的是,在做出统一意见之前,这些书着眼于基础工具几年的使用经验.无服务器技术存在时间太短,还不足以需要编写一本书进行描述,但是这一时刻正在逼近,一年内我们会看到一些有用的实践案例出现(当无服务器架构需要出一本高调的书时,大家一般会选用“最佳实践”这样的术语描述).

系统架构之后(即无服务器应用程序是如何被构建的),我们需要思考部署系统架构(无服务器应用程序如何部署).我已经谈了一些部署工具,但是我们可以如何使用这些工具呢?例如：

• 环境这样的术语在世界上意味着什么?“生产”看上去较过去有点不明确.
• 什么是一个软件栈的side-by-side部署?看上去像是从一组功能/服务版本缓慢地移动业务到另一组功能/服务版本(滚动部署)?
• 世界上有么有类似于“蓝-绿”这样的部署方式?
• 现在的回滚方式是怎样的?
• 我们如何管理数据库的升级/回滚,当我们可能有多个不同的代码生产版本,并且这些版本在同一个功能内运行,这类有状态组件应该如何管理?
• 当使用第三方服务时,如果你不能够完全下线服务或者重新完整地部署,那么一台phoenix-server看起来更像什么?

最后,当我们从一种系统架构样式迁移到其他架构,什么迁移模式是比较有效的?或者是否包括无服务器组件?我们的架构以怎样的方式进化?

许多这些尚未定义的模式(反模式)都不是很明显的,通过我们幼稚的想法明显表现出来的是,如何最好地管理无服务器系统内的状态.毫无疑问,有一些神奇的模式出现了.

我们的组织将会如何变化

成本效益是无服务器前进的一项驱动,最有意思的优势是“生产提前期概念”的降低.通过提供“超级能力”方式,无服务器为大多数既不是系统管理专家,也不是分布式系统开发专家的美国工程师提供了进入无服务器领域的可行性.这些只有一点点技术的应用程序开发工程师,不再需要编写一行Shell脚本,即可完成整套MVP(即Minimum Viable Product,最小可行性产品)的部署,扩展平台能力,或者配置一个nginx服务器.前文中我提到了配置工具还在开发当中,我们现在还没有这类“简单的MVP”解决方案,能够解决所有类型的应用程序问题.但是,我们确实看到了相对于简单的Web Services服务,甚至为其他类型的应用程序部署一些Lambda函数,也比管理操作系统进程或者容器来得更容易.

除了MVP以外,我们也看到了重新部署应用程序的周期时间正在缩短,不再需要关心脚本维护、系统补丁级别,等等.

无服务器为我们提供了技术手段去实现这些需求,但是还不足以真正实现对于一个组织的改进.为了实现这些目标,公司需要去克服、适应以下这些变化.

真正的DevOps

DevOps已经在很多领域都变得很重要了.在开发工作上,额外技术的技术操作越来越常见.我所看见的是系统管理内部的自动化增加和自动化测试,这只是Patrick Debois在创造DevOps概念时所想到的很小一部分.

真正的DevOps是我们思维方式上的变化,以及文化上的变化.让我们假设有这么一个团队,这个团队需要紧密合作、开发和维护一个产品.这就意味着写作,而不是基于协商的工作序列方式.也意味着开发人员需要提供技术支持.而意味着开发工程师需要参与应用系统架构.换句话说,意味着技能与责任的融合.

如果一个公司分离了开发团队和运维团队,即将“DevOps”团队分离,那么他们不会在无服务器领域有任何收获.如果一个开发人员仅仅只是对应用程序进行编码,而部署工作又交给另一个外部团队负责,那就会没有真正意义上的系统部署情况反馈.如果一个业务工程师不会到应用程序的部署环节,那么他们也不可能适应生产环境的部署模型.

换句话说,未来会从无服务器领域收获实际收益的公司,必然是真正使用DevOps的公司.

政策/访问控制的变化

（编辑：财气旺网 - 财气网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!