本文译自 Everything is an HTTPS interface欢迎在评论区留言，交流技术研发问题。首发于知乎专栏：大前端工程师,大家可以通过【阅读原文】查看和评论。
在 Linux 中，万物皆为文件；而在 Serverless 中，万物皆为 HTTPS 接口。
如其本性使然，Serverless 应用程序被分解为各种各样的服务，例如独立的函数，对象存储，鉴权服务，文档数据库，发布／订阅消息队列。这些服务间的接口都是典型的 HTTPS 。当你使用 AWS SDK 调用 AWS 服务时，所使用的接口在底层就是一个 HTTPS 接口。在绝大多数云平台都是如此，只有偶尔在一些特殊情况下，才会使用其他协议，比如 WebSockets 和 MQTT 。
在 Linux 中，你可以通过文件系统访问底层机器的所有资源；同理，在 Serverless 中，你可以通过 HTTPS 接口访问底层云平台的所有资源。
这种比较已经不仅仅只是上述这种通用接口的使用了， Severless 应用程序设计的最佳实践也越来越像 Unix 哲学了。（ Linux 延伸自 Unix ）
引用一下 Doug McIlroy 对 Unix 哲学精辟入里的总结：
一个程序只做一件事，并把这件事做好。
程序之间能协同工作。
程序要能处理文本流，因为文本流是最通用的接口。
将 Unix 哲学置身于 Serverless 的世界里，就只需改变一下接口：
一个程序只做一件事，并把这件事做好。
程序之间能协同工作。
程序要能处理 https ，因为 https 是最通用的接口。
Doug McIlory 用以下4点扩展定义了 Unix 哲学：
让每个程序做好一件事。如果有新任务，就重新开始，不要向原程序中加入新特性，从而把原程序搞复杂。
期望每个程序的输出都会是另一个程序的输入，哪怕那个程序是未知的。输出中不要有无关信息的干扰。避免使用严格的分栏或二进制格式输入。不要坚持使用交互式输入。
尽早地开始试用设计编译好的软件，最好能在几星期内，就算是操作系统，也要这么做。对于拙劣的代码，果断扔掉重写，坚决不能犹豫。
优先使用工具减轻编程负担，而不是毫无技巧的耗费体力。工欲善其事，必先利其器。
去年纽约的 ServerlessConf 大会上，Paul Johnston 在 《What I Wish I’d Known Last Year》中，提出了对 Serverless 应用程序设计非常有用的极简原则：
开始就要用部署管理
你可以承受尽早失败
在每个函数中，只有 0 或 1 的数据转换
不要让你的数据模型过分复杂
Paul Johnston的观点几乎都是可以从 Doug McIlory 的观点推论出来的。
Eric S. Raymond 在《expands on the Unix philosophy 》 （传说中的 Unix 编程艺术）中，提炼出 17 项简单实用的原则，助力 Serverless 应用程序设计：
模块原则：使用简洁的接口拼接简单的部件。
清晰原则：清晰胜于机巧。
组合原则：设计时考虑拼接组合。
分离原则：策略和机制分离，接口和引擎分离。
简洁原则：设计要简洁，复杂度能低就低。
吝啬原则：除非确无他法，不要编写庞大的程序。
透明原则：设计要可见，以便检查和调试。
健壮原则：健壮源于透明和简洁。
表示原则：把知识放在数据中，从而使程序逻辑蠢笨且健壮。
通俗原则：接口设计通俗化。
缄默原则：如果一个程序没什么好说的，就应该保持沉默。
补救原则：出现异常时，马上退出并给出足够的错误信息。
经济原则：宁花机器一分，不花程序员一秒。
生成原则：避免手工编程，尽可能编写程序去生成程序。
优化原则：雕琢前要先有原型，优化前要先能工作，俗称跑之前先学会走。
多样原则：决不相信所谓“不二法门”的断言。
扩展原则：面向未来设计，未来总比预想来的快。
这 17 点可以毫不犹豫地直接应用在 Serverless 设计中哦！遵循这 17 点，你将拥有一个可扩展的，可调试的，可维护的 Serverless 应用程序。
好的 Serverless 设计就是 Unix 哲学 在“云端”开发应用程序这个新领域的又一次绽放。
回顾我以前的文章：
mock系统接口
如对其他文章感兴趣，欢迎关注大前端工程师：
