一篇文章看懂无服务器计算的本质与未来
|
这里比较有意思的一个想法是FaaS功能,由于它们轻量级的应用模式,可以将自己紧紧地绑定一个服务,使得FaaS调用服务功能的生态环境时可以调用其他的FaaS功能,诸如此类等等.这会导致“有趣的”级联错误问题,对于这种错误我们需要更强大的监控工具,会在本文稍后介绍. 站在数据中心后面目前来看,绝大多数的无服务器计算是运行在供应商数据中心平台上的.这就给出了一个替代方案,即如何运行你的代码,而不是在哪里运行代码.Amazon发布了一个有趣的新特性,即是允许它们的客户在不同的地点运行Lambda函数,例如,和Lamdba@Edge一起运行在CDN内,甚至在无服务器地点,和Greengrass一起运行的物联网(IoT)设备.这样做的原因是,Lamdba是一个极端轻量级的编程模型,本质上的事件驱动的,并且非常容易适配相同的知识理念、新地点的代码风格.Lambda@Edge是一个特别有趣的例子,因为它提供了在一个地点进行程序定制的可选项,这在以前是没有出现过的情况. 当然,这种做法的缺点是和供应商深度绑定!对于那些不想使用第三方平台,但是又想利用无服务器计算优势的厂商来说,有一种可以接受的解决方案,类似于Cloud Foundry已经推出的PaaS.来自Kubernetes的Galactic Fog、IronFunctions以及Fission,是这种方案的早期作品. 我们将来需要的工具和技术正如我之前描述的,这里有一个明显的减速,使用无服务器方式时存在条件限制、性价比权衡.天下没有免费的午餐.对于已经过了早期适应阶段的无服务器用户来说,我们需要解决或者缓解这些问题.所幸,这方面目前发展势头良好. 部署工具使用AWS的标准工具向Lambda部署函数挺复杂的,也比较容易出错.向API网关中添加Lambda函数,以响应HTTP请求,你更多要做的工作是安装和配置.无服务器和ClaudiaJS开源项目项目已经推动部署改进措施达一年之久,AWSSAM(AWS无服务器应用模型)也在2016年加入到了这一行动.所有这些项目通过在AWS标准工具的顶层增加大量自动化程序,简单化了无服务器应用程序的创建、配置和部署.但是我们还有很多工作要做.未来将会有两个关键动作实现完全自动化：
第一条很重要,我们也已经开始认识到,以便更广泛地推广“生产提前期概念”.部署一个全新的无服务器应用程序应该是像创建一个新的Github仓库一样容易,填充少量字段,然后按下按钮,通过这种一键部署方式让系统自动创建你所需要的所有东西. 然而,光有简便的初始化部署方式是不够的.我们也需要有比较好的工具,支撑前面提到的混合动力系统的持续交付和持续部署.这意味着我们应该可以部署一系列的计算函数以及CaaS/PaaS组件,连同所有应用程序封装服务的变化(例如,在一个API网关配置http路由,或者一个被单一应用程序使用的Dynamo表),一键生效和回滚能力.此外,这些动作都不应该是很费脑力去理解的,也不会需要几天时间去完成安装和维护任务. 这是一个很艰难的抉择,但是我前面提到的工具(类似于Terraform这样的混合动力工具)正在指引解决这些问题的方式,我完全相信他们在未来的几个月或者几年时间里可以在很大程度上解决问题. 本文不仅仅讨论部署代码和配置服务.其他一些操作上关心的问题也会被讨论.安全问题是一大问题.当前,获取AWS凭证、角色,以及设置和维护都可能是一大麻烦事.AWS拥有一套完善的安全模型,但是我们需要一个工具,这个工具可以让这套安全模型对于开发人员来说更加友好. 总之,我们需要开发人员在开发他们的Webtask产品时,做到UX和Auth0都很好,就像AWS一样的宽广而有价值的生态系统. 监控、日志和调试（编辑：网站开发网_盐城站长网 ） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
