本文讲的是这不是我想要的Serverless【译者的话】本文作者就serverless阐述了一些自己的想法，以及对标准的诉求。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
最近，我们在Container Solution平台上探讨了serverless的适用面，更重要的是，我们讨论了它可能的走向。之前玩过Lambda，我发现讨论远比实际执行更加有趣，因为它始于我们想要的以及我们所得到的。
我拒绝接受由供应商执掌“serverless”发展轨迹的现状，大家需要一个标准。我有一个目标，一个基于个人想法的目标。最后一个纯粹出于个人嗜好，接受它或是提出你的建议。
坦白说，我个人并不喜欢AWS，Azure和GCE对于serverless的描述。我喜欢这些供应商，我认为它们的平台是令人叹为观止的，但我是一个发自内心的纯粹主义者。我认为要落实serverless，必须为其开发一个开放标准。
我也认为这些供应商正在寻求能够满足顾客需求的最廉价的解决方案。但这通常并不会成为最佳解决方案。
当前的FaaS（Function as a Service）根本没有做到这些。它们都在其生态中提供了框架，你只需要在此完成工作。
我们需要一个开放标准，但是它应该是怎样的呢？好吧，首先，我们需要建立关于其如何工作的基本准则。
在现有的产品中，上述内容得不到任何保证。我需要想象一个拥有上述一切的世界。
这并不意味着我们无法开发一个工具以使我们的工具容器化，使之得以在数毫秒内启动，并使所有的功能遵循相同的隔离。
或许unikernel才是答案，而非容器，或许仅需一台经过调整的Linux服务器，使其高效地隔离每个进程，不赋予它们文件访问权，仅允许向外的TCP连接。
Serverless方法的理念就是生成、执行和销毁，对我而言，这是一种获取数据的好规范。
如果你深究云供应商的FaaS实现，你会发现它们仅提供2个变量。其一是“event”，它们不关心内部有什么。其二便是“context”，它将请求置于上下文中。与可执行程序中通过STDIN发送标记和环境变量相比，这并没有什么不同。
考虑更加简单的STDIN/STDOUT确实给了我们很大的自由。它允许我们的方法是语言无关的，并且通过Linux强大的管道命令，我们便可构建非常健壮的功能链了。
当前市场中，我认为存在2种相对理想的格式，Cap'n Proto和Protobuf。前者允许快速传送大量数据，后者则允许向现存载荷拼接数据。从目前来看，我无法确定哪一个才是更加理想的选择，抑或是可能会出现更加优秀的方案。但有一点我很清楚，如果我们建立了进程间共享数据的标准，那么完全可以在之后构建可替换的部分(标准)。
这是一个正在进行中的思想性项目，我期望收到建议。下一篇文章和一个假想的系统相关，它能够实现理想的serverless生态系统。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
最近，我们在Container Solution平台上探讨了serverless的适用面，更重要的是，我们讨论了它可能的走向。之前玩过Lambda，我发现讨论远比实际执行更加有趣，因为它始于我们想要的以及我们所得到的。
我拒绝接受由供应商执掌“serverless”发展轨迹的现状，大家需要一个标准。我有一个目标，一个基于个人想法的目标。最后一个纯粹出于个人嗜好，接受它或是提出你的建议。
供应商
在AWS推出Lambda时，我认为这将会造成业界的兴奋以及许多情况下的困惑。我不太确定是否每个人都能理解它是如何工作的以及这是否会为大家带来帮助。此后，Lambda证明了它是一款非常酷的工具，毫无疑问它能够削减运维的开销。它同样助长了我们正在经历的serverless热潮。坦白说，我个人并不喜欢AWS，Azure和GCE对于serverless的描述。我喜欢这些供应商，我认为它们的平台是令人叹为观止的，但我是一个发自内心的纯粹主义者。我认为要落实serverless，必须为其开发一个开放标准。
我也认为这些供应商正在寻求能够满足顾客需求的最廉价的解决方案。但这通常并不会成为最佳解决方案。
开放标准
开发标准会拉近大家距离，让大家说同样的术语，使工具更具兼容性，这一切完全说得通。当前的FaaS（Function as a Service）根本没有做到这些。它们都在其生态中提供了框架，你只需要在此完成工作。
我们需要一个开放标准，但是它应该是怎样的呢？好吧，首先，我们需要建立关于其如何工作的基本准则。
- 在支持多任务处理时，它必须是安全的
- 它需要足够快
- 对于数据格式需要一致认同
- 它必须是语言无关的
- 它需要在任何地方运行
在现有的产品中，上述内容得不到任何保证。我需要想象一个拥有上述一切的世界。
未来
因此我需要从未来借调一些内容，并且在最后我会带大家回到过去。容器
容器是我们将会在Serverless系统中尝试，并用以实现安全性和速度的技术。当我们谈及容器，大多数人马上就会想到Docker。Docker其实并不能很好地适配Serverless功能，它慢、臃肿且需要一个守护进程。这并不是在挖苦Docker，但他确实并不算是Serverless的一个好选择。毕竟我们需要一把外科手术刀，而Docker是一把瑞士军刀。Docker和Rkt均非容器，它们只是用来促进容器化的工具罢了。这并不意味着我们无法开发一个工具以使我们的工具容器化，使之得以在数毫秒内启动，并使所有的功能遵循相同的隔离。
或许unikernel才是答案，而非容器，或许仅需一台经过调整的Linux服务器，使其高效地隔离每个进程，不赋予它们文件访问权，仅允许向外的TCP连接。
STDIN/STDOUT
在这个议题上，我想我会让我的同事不厌其烦，但是至少就使用标准输入和输出而言，我成为了一名坚定的信徒。自使用诸如AWS KCL之类的工具之初，我便震惊了，它们提供了一个守护进程，并使用其包装你的进程，如此你便可以在任意语言中提取Kinesis消息了。我便在Lambda上使用NodeJS的包装器包装了我的第一个Go程序。我们可以用不同的语言，使用不同的协议进行通讯，但是STDIN/STDOUT则是普适的。Serverless方法的理念就是生成、执行和销毁，对我而言，这是一种获取数据的好规范。
如果你深究云供应商的FaaS实现，你会发现它们仅提供2个变量。其一是“event”，它们不关心内部有什么。其二便是“context”，它将请求置于上下文中。与可执行程序中通过STDIN发送标记和环境变量相比，这并没有什么不同。
考虑更加简单的STDIN/STDOUT确实给了我们很大的自由。它允许我们的方法是语言无关的，并且通过Linux强大的管道命令，我们便可构建非常健壮的功能链了。
数据格式
JSON看起来像是一个事实上的标准，使大家回到通信，但是在云的世界里，我认为需要更进一步。且在道别前花点时间。当前市场中，我认为存在2种相对理想的格式，Cap'n Proto和Protobuf。前者允许快速传送大量数据，后者则允许向现存载荷拼接数据。从目前来看，我无法确定哪一个才是更加理想的选择，抑或是可能会出现更加优秀的方案。但有一点我很清楚，如果我们建立了进程间共享数据的标准，那么完全可以在之后构建可替换的部分(标准)。
未完待续
我并不认为我们当前拥有的“Serverless”基础设施，就是我们想要的供应商无关的那种。尽管我们拥有能够很好工作的工具，但是它们仅为服务提供商的利益而工作，这完全能够理解，然而常止于进一步的开发工作无法为它们带来利润时。是时候开始考虑一个开放的框架了，这使我们能够开发强大而开放的工具。如果我们可以开发一个符合开放标准的平台，那么第三方服务就可以围绕我们的标准开发工具。标准开发的目的并不在于锁定供应商或为迎合你的最高消费顾客。这是一个正在进行中的思想性项目，我期望收到建议。下一篇文章和一个假想的系统相关，它能够实现理想的serverless生态系统。
原文链接：This is not the Serverless I Ordered（翻译：孙科）
原文发布时间为：2017-05-23
本文作者：孙科
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：这不是我想要的Serverless
