在云计算领域，容器和无服务器计算已经占据了发展前列。
作者 | Emra Samdan
翻译 | bocloudresearch
一点历史
在不久以前，应用程序的开发、部署和维护要比现在复杂得多，耗时也多。在最初，维护不仅需要修复应用程序的代码，还需要修复对物理机器的支持。保持服务器、硬件和软件的更新也是非常关键的任务。
在本世纪初，一种名为“基础设施即服务(IaaS)”的新模式迅速流行起来。IaaS提供了从第三方提供商租用远程服务器和虚拟机的可能性，这些提供商可以完全负责管理硬件、网络和预订。
IaaS出现之后，消除开发人员的所有非编码职责来简化开发人员工作，这一想法推动了新方法、模型和服务的创新。
容器是什么?
Docker的官方网站提供了以下简短而优雅的定义:“容器是一个标准的软件单元，它将代码及其所有依赖项打包，从而使应用程序在不同的计算环境之间快速、可靠地运行。换句话说，通过使用容器，开发人员可以确保他们的应用程序可以在任何云平台或本地服务器上运行。在某些方面，容器类似于虚拟机，比如两者都是隔离资源。但是，虚拟机模拟物理设备，而容器创建应用程序层的抽象。
无服务器计算是什么？
在无服务器计算中，整个应用程序或应用程序的一部分被解耦为多个函数，每个函数都响应诸如HTTP请求、新消息到达消息队列、或在存储中保存或修改新对象等时间触发的。平台可以在特定的时间或周期运行这些函数，这对cron jobs（定时任务）很有帮助。
要使此系统工作，开发人员只需编写功能代码，并将其及其依赖项打包到zip文件中，然后将该zip文件发送到无服务器端点，由提供商负责供应和扩展。
无服务器的关键特性之一是“按需付费”模型，在这种模型中，公司仅按函数的实际执行时间付费。如今，AWS Lambda应该是最受欢迎的无服务器提供商。
容器和无服务器有什么共同之处吗?
是的。现在，无服务器和容器都很流行，它们允许开发人员专注于自己的代码而不是基础设施，这极大地提高了开发速度。容器和 serverless 都非常适合于微服务和基于组件的体系结构。在使用它们时，部署和扩展通常比使用传统的单体架构更快、更具成本效益，因为你操作的是应用程序的一小部分，而不是整个应用程序。虽然容器和serverless 有这些共性，但是每种技术都有自己的优势、弊端和用例。
容器化的优势
容器的第一个优势是可移植性。由于容器已经包含了它需要运行的所有内容，因此只需放置一台安装了容器引擎的机器即可运行。容器与平台无关，因此它们可以运行在Linux、Windows、macOS、Mesos、Docker、Swarm或Kubernetes上。它们甚至可以在另一个容器中运行。
在计算资源使用方面，容器也比虚拟机更高效。尽管容器和虚拟机都是虚拟化的，但是虚拟机会使用自己的操作系统来模拟整个计算机，因此会消耗更多的资源。另一方面，容器可以共享同一操作系统，从而使操作系统更小，更快地启动和关闭。
容器的另一个好处是允许开发人员完全控制应用程序。虽然这意味着必须手动配置系统设置，但这也意味着拥有真正的灵活性。这在serverless上是无法实现的，因为无服务器的所有内容都是由云提供商管理的。
容器的用例
当我们想要将一些大型的单体应用程序重构为更小的独立部分， 以便迁移到微服务体系结构并获得更好的性能、可测试性和扩展速度时，容器确实是很有帮助的。例如，将以前的大型应用程序拆分为几个独立的服务：其中一个负责用户管理，另一个负责转换媒体文件等。每个服务都可以轻松扩展，以便在其职责范围的负载增加时提供更好的性能。但这对于单体应用程序来说是不可能实现的，在单体应用程序中，需要向整个系统添加新实例，这既昂贵又耗时。
因此，容器适合于长时间运行的应用程序，以及具有特定系统需求的应用程序，如果没有对系统的完全控制，这些应用程序很难设置。
Serverless的优势
由于上面提到的“按需付费”模型，托管无服务器应用程序的成本可能比使用任何其他方法都要低得多。无需为功能的空闲时间付费，如果没有流量，那么每月的账单上就不会有费用。几乎所有无服务器的提供商都有免费层，其中包括每月固定数量的请求和执行时间。通常情况下，所提供的数量足以使小网站或初创公司免费运行。
对于容器，将应用程序分发到部件或微服务是关键步骤。在serverless中，它是将应用程序或其各个部分分发到单个函数中，每个函数负责特定的逻辑段。工程师更容易理解和开发单个功能的逻辑，这极大地提高了开发和部署速度。与部署整个应用程序相比，部署一小部分功能的风险更小。
无服务器的另一个巨大优势是自动伸缩。无服务器的函数在提供者控制下的小型、无状态的临时容器中运行。提供者对响应负载峰值的扩展承担全部责任，并且可以在几秒钟内启动数百个实例。而且，仍然只需要为所有函数的总执行时间付费。
什么时候使用无服务器比较好?
Serverless的事件驱动特性使得它对于不总是需要运行的应用程序(或其部分)非常有用。
假设你正在为一个现有的应用程序开发媒体处理功能。新模块虽然不会经常使用，但是仍然需要足够的计算能力来完成它的任务。将其放如应用程序中可能需要切换到更强大的实例——这是一个冒险的举动，因为如果同时运行一些繁重的任务，可能会导致其他所有用户的延迟。在这种情况下，还需要支付更多的费用，并且仍然面临由上述瓶颈所导致的一些问题。
相反，如果选择了serverless，那么媒体处理功能将与应用程序的其余部分隔离。当它不被使用时，就不需要为此付费，并且可以始终确保它不会影响到应用程序的其他部分。
容器的弊端
即使没有人使用应用程序，也至少有一个承载容器的虚拟机实例始终在运行。由此导致容器比无服务器更昂贵。
即使容器可以在共享计算机中快速扩展，但由于需要对计算机本身进行扩展，因此其他扩展也不很快。 但是，将容器与业务流程系统（如Kubernetes或AWS ECS）一起使用可以使扩展更智能。
无服务器的弊端
对于大多数开发人员来说，serverless最可怕的部分是供应商锁定。当你提交到serverless时，实际上是在单个云提供商上进行堆栈。这些函数中使用的无服务器应用程序和 api 的体系结构因不同的提供商而有所不同，因此更改提供商或切换到内部解决方案的成本可能很高。尽管如此，有一些专家并不同意这个观点，他们声称厂商锁定实际上并不是一个问题。
使用无服务器方法不容易实现可观察性、监视和调试。由于应用程序可以被分散到多个部分，而每个部分都有自己的 bug 和错误，所以控制和查看全局变得非常重要。
容器和无服务器可以一起操作吗?
容器和无服务器可以一起操作，答案是肯定的。将主要应用程序功能作为一个容器化的微服务来运行，同时将无服务器使用于某些后台操作或很少使用的功能（但占用CPU），可能会非常有效。
另一个有趣的组合是AWS Fargate提供的。该服务结合了无服务器和容器的优点，允许你更好地控制你的应用程序，而不必担心伸缩难题。
结论
容器和无服务器通常被认为是相互竞争的技术。但仔细观察就会发现它们只是不同的技术，当在同一个项目中使用时，它们实际上可以弥补彼此的缺陷。重要的是要记住，“旧的”并不意味着“过时”，“新的”并不意味着“更好”。解决方案的有效性取决于特定的用例、项目需求、团队经验和团队偏好。
