过去几年我一直在无服务器社区中试图弄清楚如何帮助其他人理解“无服务器”意味着什么。对于我来说，最近几个月谈论无服务器一直试图避免谈论技术，并试图开始讨论该方法的商业价值。我甚至写过关于其中一些内容的博客：
我注意到的一件事是，过去几年我以各种不同的方式改变了自己的想法。我现在对特定的技术选择不太感兴趣，对组织内部如何实施技术的战略方法更感兴趣，以及组织需要实现的过渡以接受无服务器的思维模式。
然后昨天我偶然发现了斯沃德利在2016年写回一篇关于组织的普遍学说的文章。我意识到了......
无服务器是一种学说
什么是学说？为了我们的目的，一个学说是你从经验中学到的一套原则，并编成了一些书面形式，例如一套最佳实践......就像我的最佳实践博客文章......
考虑到“无服务器作为一种学说”，我认为当有人将任何技术或服务称为“无服务器”时，我发现它真的令人沮丧。最常见的例子是当有人说“无服务器”这个词的意思是“作为服务的函数”或FaaS时 - 它没有。FaaS是无服务器方法的主要支持技术之一，FaaS本身并不是无服务器的。
让我再说一遍：
FaaS不是无服务器的
让我解释…
无服务器特点：
1. 将您的想法从代码转移到配置
无服务器应用程序不是由代码定义，而是由定义资源的配置定义，以及触发将这些资源粘合在一起的少量代码的事件。
代码变得更加关注独特的业务逻辑
配置定义非业务关键应用程序。
2. 将您的思维从高量代码行转移到低量代码行
今天的代码是明天的技术债务
在我的世界中，最好是零代码（全部在配置中）
我们越可以转向配置，我们需要的代码行越少
3. 将您的想法从架构服务转移到消费服务
如果存在可以做我们想要的服务，那么我们就有理由想要构建该服务。
因此，除非业务至关重要，否则不要构建该服务。
4. 将您的想法从拥有工作量转移到不再使用工作量
在运行系统时，您应该只关注业务关键系统。其他一切都不重要。
没有实例，服务器或容器，除非没有其他方法
如果我不需要，为什么我要再管理这些了！除非它是关键业务，否则这些是技术预算中最大的浪费时间之一！
向上和向下缩放应尽可能由服务处理
向上和向下缩放至关键是关键。
这包括基本上配置服务器以在其上运行某些内容的服务。在AWS上运行RDS数据库之类的东西在这一点上是有问题的，因为您必须配置实例，并且缩放是手动的。这也是为什么RDBMS通常不合适存在我的无服务器应用程序视图中的原因 。
数据层应该是特定于应用程序的 - 没有“一刀切”的方法
这个对我来说是关键的，它只是挑战“一切都必须是RDBMS”的假设。
有没有说你不能使用RDBMS，但记得要顾及缩放和管理学说太多。
但是，在过去几年中我遇到的几乎所有场景中，应用程序数据层都有比RDBMS更好的解决方案。
没有有效的业务案例，没有新的服务或技术
我经常让开发人员来找我说“我能做到这一点的唯一方法就是使用X服务/技术”。但愿这永远不会成真。
我的回答是将他们送走并要求他们写一个“业务案例”。在他们编写了一个业务案例（通常需要几个，因为他们不知道是什么）后，我告诉他们离开并确定他们是否可以使用当前的技术堆栈来实现他们所需要的。答案几乎总是肯定的，或者如果不是，它通常是一种完全不同的技术。
例如，我有一个开发人员来问我是否可以使用RedShift，我把他送走了，经过一轮“商业案例”宾果游戏，他意识到他可以使用雅典娜来实现同样的目标。它没有服务器，符合原则。
开发人员需要了解他们必须证明决策的合理性，当他们意识到他们必须了解他们所处的业务时，他们往往会成为更好的开发人员。
企业中的所有技术人员都在那里提供商业价值
企业中的人的工作不是提供技术，而是提供商业价值。
这应该是显而易见的，但对大多数开发人员来说并非如此。
现在，对我而言，无服务器是一种学说