Serverless正在迅猛发展：根据2019度CNCF调查报告，目前有41％的受访者正在使用serverless技术，另有20％的受访者计
划在未来12至18个月内使用serverless技术。 serverless技术允许云化应用程序开发团队将代码交付给serverless服务商-以减少
开销成本，提高可伸缩性并简化DevOps周期。
一、Serverless标准
Serverless已经被认为是应用程序基础架构的下一个发展阶段，但目前仍然有一些障碍需要克服，特别是标准化工作。
长期以来，推进标准化一直是统一计算领域的重要方式。 正如当初的Mesos、Kubernetes以及Swarm的容器编排之争，在争夺霸主地位的过程中，因为Kubernetes致力于标准化的引进，从而异军突起，后发制人，一举赢得容器编排之争，正是因为秉持标准化的理念，Kubernetes得到越来越多的人员的加入，从社区的维护到使用者的参与，再到CNCF的壮大。更久远的事例，就是浏览器之争，因为2001年成功说服Internet Explorer，Netscape和其他浏览器采用World Wide Web Consortium建立的标准。 结果就是今天我们知道和喜欢的互联网：一个开放，协作且通用的平台，可以在线连接世界各地的人们，从而使Web开发人员的生活变得更加轻松。
如今，serverless的生态系统仍然呈现零散状态，就像早期的互联网一样。 在AWS Lambda，Microsoft Azure Functions，Google Cloud Functions和众多其他平台之间，许多serverless功能都是专有的，这使得将应用程序从一个平台迁移到另一个平台成为一项难题。 平台之间缺乏可移植性和互操作性，这阻碍了serverless的应用，开发人员担心业务与云服务商过于耦合。
在serverless市场较初期的情况下，如果能够降低业务与服务的耦合下，那么在将来存在更好的选择情况下，开发人员就不会陷入选择serverless提供商的困境。 而且，随着新冠病毒给经济造成的不可弥补的伤害，serverless市场有望为快速整合做好准备，这使得云服务商具备跨平台迁移serverless应用程序的能力比以往任何时候都更为重要。
缺乏serverless标准化同时也带来了安全挑战。尽管serverless可以通过减少服务器管理来简化运维等成本，但是由于开发人员无法看到他们在无服务器平台上运行的工作负载。这意味着无法察觉诸如数据泄露，配置错误，过度的访问权限等安全威胁。当然，可以让开发人员通过serverless提供商提供的API来观察可能的安全威胁。但是没有标准化的serverless框架，在整个serverless生态系统中就不会存在标准化的安全工具或最佳实践。
庆幸的是，标准化工作正在推进。位于云原生世界中心的CNCF，已经意识到了”标准化的紧迫性，并指出需要高质量的文档，最佳实践，更重要的是工具和实用程序。通常，有必要将不同的参与者聚集在同一个屋檐下，以通过协作来推动创新”。本着协作的精神，CNCFserverless平台提供商和第三方库开发人员召集到serverless工作组中，以推进标准化。
二、CloudEvent试水
serverless工作组的早期推出的CloudEvents标准，它用于事件描述的标准化。serverless工作组经过两年的工作，于2019年10月发布了1.0版。 CloudEvents为Go，JavaScript，Java，C＃，Ruby和Python等语言提供了标准化的SDK，可用于构建事件路由器，跟踪系统和其他工具，从而简化跨平台和环境的事件数据交付。
Kubernetes已经成为另一个有预期未来的解决方案。容器生态系统已经围绕Kubernetes进行了整合，使其成为统一serverless生态系统的理想平台。在2018年，由Google领导、与Pivotal，IBM，Red Hat和SAP合作推出了Knative开源框架，其用于在Kubernetes之上运行serverless应用程序组件。该平台提供以构建，部署，扩展和运行serverless工作负载的所有API。
除了互操作性和可移植性之外，Knative还具有安全性优势。 Knative允许您使用已经为Kubernetes开发的安全工具，其中安全策略更加成熟。借助Knative，您可以通过将安全代理嵌入Kubernetes中的serverless工作负载来实现更丰富的可扩展性，而无需使用serverless平台提供的基础架构插件。如果您的团队已经在Kubernetes安全性上进行了投资，则这些安全性投资可以扩展到serverless安全性。
Knative是否能够成为serverless标准化的赢家还有待观察。截至3月，Knative的采用率达到17％，这意味着其成熟度和增长空间仍然很大。 Knative本身建立在Kubeless的基础上，Kubeless是先前围绕Kubernetes标准化serverless的前期尝试。但是，有迹象表明，谷歌已经在Knative的基础上构建了其下一代，完全托管的无服务器平台Cloud Run，这表明其他早期的serverless平台可能会加速效仿。
Serverless使开发人员可以心无旁骛的专注于在其代码中构建功能，而不是管理运行这些功能的服务器。从繁重而又至关重要的运维责任中解放出来的有可能为应用程序开发人员释放更多的创新热情和业务价值，但是缺乏标准化的风险会分散serverless生态系统。随着标准化的发展，开源协作的力量便推动了创新。
三、何为CloudEvent
历史
CNCF的Serverless工作组最初是由CNCF技术监督委员会创建的，旨在调查serverless技术并为该领域中与CNCF相关的活动提出一些可能的下一步建议。 建议之一是研究创建通用事件格式，以帮助云提供商之间功能的可移植性以及事件流处理的互操作性。 最终，创建了CloudEvents规范。
目标
起初，制定CloudEvents标准是serverless工作组的一部分工作内容的，而当规范达到其v0.1里程碑时，TOC批准将其作为CNCF一个全新的独立沙箱项目。
CloudEvents通常用于分布式系统中，以实现服务在开发过程中的解耦，并完成独立部署，并且以后以此连接新的应用程序。
CloudEvents规范的目标是定义事件系统的互操作性，该系统允许服务生成或使用事件，其中包括独立开发和部署生产者和使用者。生产者可以在消费者收听之前生成事件，并且消费者可以进行相关订阅操作。需要注意的是，此工作产生的规范集中于事件格式的互操作性以及在各种协议（例如HTTP）上发送事件格式的显示方式。规范不关注事件产生者或事件消费者的处理模型。
CloudEvents的核心是定义了一组元数据，称为属性，以及有关在系统之间传输的事件和这些元数据应如何出现在消息中。该元数据是将请求路由到适当组件并促进该组件对事件进行适当处理所需的最少信息集。尽管这可能意味着事件本身的某些应用程序数据可能会作CloudEvent属性集的一部分，但这也是为了正确传递和处理消息而进行的必要操作。相反，不打算用于此目的的数据应放在事件（数据）本身。
此外，假定协议层将消息传递到目标系统所需的元数据完全由协议处理，那么就没有必要包含在CloudEvents属性中。除了这些属性的定义之外，还将规范如何以不同的格式（例如JSON）和协议（例如HTTP，AMQP，Kafka）来序列化事件。某些协议本身支持将多个事件批处理到单个API调用中。为了帮助实现互操作性，应由协议决定是否实现批处理以及如何实现批处理。