并没有所谓的“无服务器”计算，因为计算资源总是要在某个地方运行。这个术语源于用户必须摆脱对实际服务器和基础设施的管理。我们现在看到的是对“无容器”计算的需求——在这种计算中，应用程序开发人员可以专注于要提供的服务，而不是创建和编排这些服务的基础设施。
当然，事情并不总是这样。自Fortran和COBOL时代，我们被迫从数据库开始，以单体的方式思考应用程序，并朝着前端前进。现在情况不同了；开发人员越年轻，就越有可能从一开始就学习面向对象编程，这使得他们更容易适应微服务的思维方式。
这是一种调整。
为什么要将应用程序分解为服务？
这是一个必要的调整，因为为了创建真正现代化的云原生应用程序，我们需要以一种方便、容错的方式将特定的功能进行容器化和编排。这意味着按功能、按运维、甚至按组织单位将整个最终目标分解为单个服务。
在过去，我们编写这些功能，将它们包含在库中，然后导入到应用程序中。在这方面，这并不是一个很大的转变。这些库现在基本上是存储在诸如Docker Hub这样的存储库中的容器镜像，可以根据需要进行拆分。
但这又如何引导我们走向“无容器”架构的呢？
这样想吧。我们习惯于将无服务器计算与Kubernetes等编排容器的技术分离开来。两者的区别在于（理论上）当一个函数不在无服务器环境中使用时，它就不存在，也不使用资源或花费金钱；而在Kubernetes环境中，你可以将资源缩减到单个容器，但那个容器仍在运行（而且要花钱），即使它没有被使用。
其实不需要这样。在Kubernetes上已经有了启用无服务器计算的方法。但是，如果我们能够创建一个环境，在这个环境中我们可以获得Kubernetes的优势，而不必麻烦用户了解如何使其工作的细节，那会怎么样呢？
假设你作为一名开发人员正在创建一个应用程序来流式传输和分析视频。在这个过程中的某个时刻，你必须对数据进行编码。在分解应用程序时，你已经确定这是一个单独的服务，因此你创建了一个容器，该容器将接收原始数据作为请求并返回编码的版本。现在怎么办？
假设你可以将该容器添加到安全注册表中（这样只有你的组织才能使用它），并且当应用程序需要编码数据时，服务就在那里。你不必担心是否有可用的服务器、可扩展性、网络或任何相关内容。在某些方面，这就是无服务器计算的定义。但是，作为一种实践，无服务器有一个缺点：它没有标准化，使我们回到了供应商锁定状态。
Kubernetes标准化
如果在Kubernetes上被标准化了呢？那就能够避免供应商锁定，使用现有的技能，并轻松创建多集群应用程序。我们甚至可以创建一个环境，其中一些资源是共享的，另一些是私有的——这取决于开发人员的需求。我们还可以使用Istio等服务网格技术来管理和分段网络流量。
事实上，我们可以更进一步。如果我们可以为这些容器的供应添加智能呢？如果一个神经网络或其他机器学习算法可以预测何时可能需要不同的容器，并提前将它们运转起来呢？该算法不仅可以扩展容器，还可以扩展基础设施本身——在最大限度地提高性能的同时，最小化维护基础设施的成本。
所有这些都可以在可信计算的上下文中运行，其中的镜像存储在可信注册表中，并且只能在已通过可信平台模块（TPMs）等技术验证的服务器和设备上实例化。这使分布式计算成为可能，同时降低了安全风险。
变得复杂的地方
当然，不是说毫无挑战。这种新思维方式的另一个重要方面是标准化和安全性。我们现在需要将其规划到架构中，既包括内部运行的内容，也包括外部运行的内容，这样执行中的应用程序就不会受到攻击。在这些领域，企业必须投入大量资金，以实现所需的技术进步。例如，为了实现今天所需的灵活性，我们常常不得不以根用户的身份运行容器；这绝对不是一个长期的解决方案。我们需要一个共同的权威模式，这意味着每个人都必须就该方法的工作方式达成一致。业界需要定义权限，以及可信计算如何在所有这些类型的基础设施（如容器、VM和裸机）中协调工作。
然而，有一点与目前的情况保持一致，那就是围绕这些技术进步形成的新业务最终将把所有东西——容器、编排、网络，甚至硬件——都当作代码。所有新的自动化方法都必须是自我修复、自我扩展、自我配置，甚至跨应用程序进行自我自动化。例如，神经网络需要能够在必要时扩展，预测需要，并根据需要改进其模型（和精度）。
更重要的是，整个技术进步网络需要能够在不中断服务的情况下进行升级和更新，这意味着除了软件开发供应商之外，所有硬件供应商都需要参与其中。
原文链接：
https://thenewstack.io/containerless-computing-the-ultimate-service-decomposition/
