参加无服务器会议后得到的信息

18-09-12 banq
              

无服务器日前在美国非常热门,一场场会议不断举行,从twiiter有关无服务器的话题更新之快也可见一斑,这是一位参加旧金山的Serverlessconf会议以后得到的一些信息披露:

无服务器非常棒,因为:

更快地构建应用

发展重点

无服务器架构提供最高的生产力和灵活性

永远不要考虑服务器

永远不要考虑成本(🤔)

永远不要考虑性能

无服务器让你专注于应用程序业务/逻辑,它确保几乎无限的可扩展性,只需在函数功能运行时付费。无需担心服务器,维护,部署等。

“专注于应用业务/逻辑”很有趣,因为过去的每个新技术/软件/框架告诉用户相同的信息。

AWS Lambda无疑是无服务器领域的领导者。可能是因为他们是第一个在他们的云上引入无服务器的商家。我认为大多数非亚马逊发言者提到或使用过AWS Lambda,微软通过Azure功能,谷歌云功能和IBM云功能紧随其后。

容器与函数

这是两种选择,函数更容易,并提供更高的抽象,容器为你提供更多控制和灵活性,这取决于你要解决的背景和问题。

发展路径是: 虚拟云主机 --->容器 ---->函数

函数冷启动

许多会谈提到函数冷启动可能是一个问题,但相信这个问题很快就会被云提供商解决,是,我认为背景在这里很重要。如果该函数是负责将火箭发射到太空,那么每一秒都可能很重要。在这种情况下,冷启动可能是一个问题;如果一个函数用于提供内部业务应用程序,那么冷启动可能不是什么大问题。

3个神话和3个预测

来自AWS的Tim Wagner谈到了关于无服务器的三个神话:

1.无服务器是不安全的

2.无服务器很昂贵

3.无服务器只是容器的解压缩库

然后有一些预测:

1. 无服务器是新的超级计算机

2. 区块链/分类账连接到无服务器

3. 提供商限制消失了

(1)内存

(2)规模

(3)冷启动

无服务器和安全性

无服务器架构中影响安全性的两个主要领域:

1.函数代码

2. 执行环境

也提到了:

“无服务器是默认安全的,因为它是其他人的问题”

这听起来不错,但我不相信这是100%的真实。 🤔

业务逻辑的演变

首先尝试无服务器,看看你可以构建什么。并非每个应用程序都需要立即进入容器路径。如果某些服务需要优化配置,那请使用容器。

更多提示,模式和反模式

Microsoft Azure团队的Yochay Kiriaty分享了一些最佳实践:

1.函数逻辑应该是无状态的

2.函数应该是幂等的

3.每个函数一个任务

4.函数应尽快完成

5.避免递归

6.并发和速率限制

避免功能试图做太多事情。否则你最终会得到一个“迷你巨石单体”功能函数。

无服务器和BaaS

我有点惊讶没有人提到后端即服务(BaaS)。我认为无服务器是BaaS的一个组成部分。定价结构不同 - 是的。现在,BaaS提供商已存在很长时间了。你可能听说过Parse(Facebook广告现在作为一个开源项目获得);StackMob(被PayPal收购)和Kinvey(被Progress收购)。这些公司提供了一个服务器端环境,你可以在其中执行代码。语言支持可能仅限于JavaScript,他们还提供存储服务(数据库即服务)和其他服务,如推送通知。

快速开发/低代码/公民开发人员

将低代码/快速开发/可视化开发与无服务器结合起来非常合适。

无服务器与FaaS与云函数命名

我认为无服务器应该引用通用应用程序架构 - 这意味着应用程序是由各种组件和服务构建的(无服务器或可用作某种服务)。云函数只是无服务器架构的一个组成部分(你编写应用程序代码/逻辑的服务器端环境),无服务器架构的其他组件可以是数据库,推送通知和其他服务(定价和可扩展性可以与当前的无服务器模型不同)。

我认为专门针对执行代码的环境(今天人们称之为无服务器),我更喜欢“云函数”名称或FaaS(功能即服务)而不是无服务器。

What I Learned Attending a Serverless Conference –