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

即便一个组一个组地尝试改变文化,也是做得不够的.很多时候,一个大公司里的一个很有工作热情的团队,往往面对的是冷冰冰的公司政策.这可能意味着在缺乏外部批准的情况下,缺少部署新系统的能力.很有可能是由于对于所有现有应用程序的数据访问限制.也可能是因为超级严格的支出控制.

虽然我不提倡公司把所有与安全和成本相关的问题抛到外部解决,但是为了尽可能做到无服务器化,需要调整他们的政策,允许团队对操作请求作出改变,而不是每一次小的更新操作都需要一个团队外部人员的批准.访问控制政策目前还不是很有必要构建.团队需要被给予一定范围内的预算自由.所有的实验应该被尽可能多地提供免费的沙盒,同事还可以保护公司内部真正敏感的数据或其他需求.

通过我之前提到过的IAM规则和多个AWS账户的使用,访问控制工具正在逐渐完善.然而,不是那么简单的,针对更好的自动化方式正在成熟.同样,无服务器还存在通过几个账户实现基本预算控制,我们需要更容易控制每个团队执行能力限制,对于不同的环境有不同的执行限制范围.

好消息是通过加强权限控制工具,所有这些问题都有可能解决,我们会看到y预算分配模式上的进步,等等,因为无服务器工具在持续改进.事实上,我认为访问自动化和成本控制将会变成新的shell脚本,换句话说,当团队思考suanfa软件的操作问题时,他们不会想要去开始/停止脚本、升级补丁以及磁盘使用率,反而他们会严谨地思考他们需要怎样的数据访问方式,以及需要怎样的预算.因为团队将会经常需要思考这个问题,工程师们会用自动化取代这些问题,仅仅像我们之前做部署那样.

鉴于这种能力和严谨性,未来即便是数据最敏感的企业,也会有富有热情的团队会使用无服务器技术,使用它们去尝试自己的想法,这种做法是之前在白板上从未做过的,最终他们会认识到这种做法真正意义上保护了他们的知识或者避免财务损失.

产品所有权

过去几年时间里我们看到的另一个转变是许多高效的工程团队的聚焦正在从项目专项产品.这一转变的感觉是对于项目规划、迭代和燃尽图等的关注在降低,转而更加关注看板方式的进展、轻量级预估以及持续交付.比这一结构性改变更重要的是虽然角色和心态在转变,转变为更多的职责较差,同样我们看到真正的DevOps.

举个例子,现在很有可能产品经理和开发人员将会密切地充实新思路,开发人员会做一些原型,产品经理在最终产品设计方案明确之前,会深入进行一些技术上的数据分析.相似地,创新的火花,即新的想法或者概念也会进入某人的大脑,可能属于团队中的任何一个人.这个团队的许多成员,不仅仅是一个,现在正在接触到客户喜欢的想法.

无服务器方法为这些团队提供了一个关键好处,即接受整个团队产品思维.当团队中的任何一个人都可以想出一个点子,并且迅速地针对一种尽可能新的创新模式实现一个原型.现在精益启动式试验变成默认的思维方式,而不是由“黑客时代”保留的那样,因为这样做的成本和时间正在大幅缩减.

另一种看待这一问题的方法是,不接受整个团队产品思维的团队很有可能错误这一关键利益.如果团队不鼓励超越项目结构的思考方式,他们就很难尽可能多地使用无服务器所带来的加速交付可能性.

结论

无服务器在软件架构领域相对来说是一个新的概念,但是它也是一个可能和其他云计算创新一样,具有巨大影响力的技术创新.随着技术的发展、工具提升以及无服务器应用架构方面的心得交流,越来越多的工程团队将会拥有提升开发速度的工具,甚至于可能转变他们产品开发方式.适应无服务器,并且适应支撑该技术的文化,这类公司将会在未来领导我们前进.

致谢

感谢为此文贡献知识的朋友们：John Chapin、Chris Stevenson、Badri Janakiraman、Ben Rady、Ben Kehoe,以及Nat Pryce.

英文原文：The Future of Serverless Compute

（编辑：ASP站长网）