文章来源 | https://dzone.com/articles/serverless-vs-containers-which-is-right-for-your-b
作者 | Rahul Shivalkar
如果您正在尝试在云中部署应用的理想方式,您应该知道最常见的解决方案是是无服务器(Serverless)与容器(Containers),但决定使用哪个或许难以抉择。
在这篇文章中,我们将讨论无服务器与容器,并解释何时使用它们。除此之外,我们还将讨论另一个值得考虑的流行选项 - 微服务架构以及它如何适应整个图景。在这篇文章的最后,您将确切地知道容器与无服务器的差异,以及哪一个更适合您的业务。让我们深入了解无服务器与容器的世界,找出哪一个才是至高无上的!
什么是无服务器?
无服务器是一种云计算模型,云提供商控制着运行应用程序所需的基础设施。使用无服务器,开发人员在编写代码时不必担心维护基础设施、操作系统或服务器。由于云提供商动态分配资源,开发人员只需支付应用程序的实际使用量,而无需承担闲置资源的费用。
使用无服务器架构的开发人员将其程序划分为一系列小型独立函数,当满足特定条件时调用这些函数。每个函数可以使用各种计算机语言编写,包括Python、Node.js或Java,并旨在执行特定的任务。当事件发生时,相关函数被调用,云提供商会为执行该函数所需的资源提供支持。
通过无服务器计算,开发人员可以快速轻松地创建和部署应用程序,而不必担心底层基础设施。由于其高度可扩展性、灵活性和经济性,在各种用例中都是完美的选择,从简单的Web应用程序到复杂的数据处理流水线。近年来,随着越来越多的开发人员采用这种前沿方法来创建云原生应用程序,无服务器计算变得越来越受欢迎。
什么是容器?
容器是一种小型、独立的可执行软件包,其中包含代码、库、系统工具和配置设置。与传统虚拟机不同,容器共享主机机器的内核,并且不需要单独的操作系统。
使用容器经常创建微服务,微服务是一种软件架构,将大型程序分解为更小、独立的服务,可以分别开发、部署和管理。由于每个微服务都在自己的容器中部署,因此可以根据需求简单地扩展或缩减。
容器的可移植性是它们的主要优势之一。由于容器包含运行应用程序所需的所有内容,因此可以在不同环境之间移动并可靠地运行,无论基础设施如何。这使得在与无服务器相比的容器环境中,在不同云服务提供商和平台上创建、测试和部署应用程序变得更加简单。
总体而言,容器是一项强大的技术,在现代软件部署和开发方面具有许多优势。
什么是Docker?
Docker是一种流行的开源容器化技术,使程序员能够在容器化环境中构建、分发和运行应用程序。多亏了Docker简化的容器创建和管理过程,应用程序可以更轻松地在不同环境中构建、测试和部署。Docker的可移植性是其主要优势之一。
容器可以在各种环境之间轻松移动,包括开发、测试和生产环境,而无需改变底层基础设施。这有助于团队合作项目和在多个设置中统一应用程序部署。此外,Docker提供了一种标准化的打包和交付程序方法,简化了在项目之间分享和重用代码。
最终,通过提供更加简化和高效的容器化方法,Docker彻底改变了开发人员构建和部署程序的方式。
什么是微服务?
微服务是一种软件开发策略,将大型的、单体化的应用程序分解为更易管理的自治服务,这些服务协同工作以提供应用程序的整体功能。系统中的每个微服务都有自己的代码库,旨在执行一个单独的任务,并且可以独立于其他微服务进行创建、部署和扩展。
使用微服务架构进行软件开发更加灵活和敏捷,因为可以对单个微服务进行更改而不影响整个程序。此外,它使团队能够更独立地处理特定的微服务,加快了开发和部署时间。
总体而言,使用微服务可以增强复杂软件应用程序的可扩展性、可靠性和可维护性。
行业使用统计和趋势
在最近几年中,容器与无服务器之间的争论主导了行业使用统计和趋势的讨论。为了了解目前行业的情况,让我们来看一下。
无服务器
过去一年里,无服务器架构和函数即服务(FaaS)在CNCF社区中越来越受欢迎。根据2022年CNCF年度调查,无服务器架构/FaaS的使用率从30%增长到53%,显示出其受欢迎程度明显提升。这一趋势部分归因于无服务器的优势,包括较低的开发成本、更快的上市时间和可扩展性。无服务器计算的增加进一步强调了云原生技术在现代应用程序开发中的重要性。
数据来源:CNCF Annual Survey 2022 | Cloud Native Computing Foundation
容器
根据2022年CNCF年度调查,容器已经达到了主流采用程度,44%的受访者已经在几乎所有业务领域和应用中使用它们。在调查中,另外35%的受访者表示至少有几个生产应用程序使用了容器。
数据来源:CNCF Annual Survey 2022 | Cloud Native Computing Foundation
无服务器与容器之间的主要区别
最近在现代应用程序开发领域,两个众所周知的流行词是容器与无服务器。这两种技术都旨在解决应用程序开发中的特定困难,每种技术都有其独特的优势。虽然无服务器是开发人员工具包中较新的补充,但容器已经存在一段时间了。虽然这两个系统之间有一些相似之处,但它们也有显著的区别,使其更适合特定目的。
为了帮助您决定哪种策略更适合您的应用程序开发需求,我们将在本节中讨论无服务器和容器之间的关键差异。
上市时间
无服务器:有了无服务器,开发人员可以专注于编写代码而不是处理基础架构,这减少了上市所需的时间。
容器:在部署应用程序时,容器需要更多的设置时间和管理工作。
易用性
无服务器:由于开发人员不需要处理基础架构,无服务器架构简化了应用程序的开发和部署。它使他们能够更专注于编写代码,而不是与基础架构相关的职责。对于那些希望专注于业务逻辑和产品开发而不是基础架构管理的团队来说,无服务器是最好的选择。
容器:可以在各种环境之间轻松移动的应用程序受益于容器的轻量级、便携式运行时环境。然而,管理容器可能会很困难,并且需要对底层技术有深入的了解。这限制了小团队或具有少量基础架构背景的开发人员使用容器的可访问性。
扩展性
无服务器:使用无服务器,无需手动扩展应用程序,因为云提供商会根据使用情况自动进行扩展。此外,它能确保基础架构具有弹性和可用性,以管理故障。
容器:水平扩展容器很简单,但需要构建机制或手动进行扩展。对于大规模应用程序而言,这可能耗时且困难,因此如果您想自动化扩展,则无服务器是首选选项。
高可用性
无服务器:由于云提供商处理基础架构管理和故障转移机制,无服务器架构具有高可用性和抗故障能力。
容器:容器也可以具有高可用性,但为了确保故障转移机制正常运行,需要更多的手动配置和基础架构管理。对于小团队或拥有较少基础架构专业知识的开发人员来说,这可能更加困难。
云端成本
无服务器:与完整基础架构的固定成本相比,开发人员只需为其应用程序使用的特定资源付费,因此无服务器可以更具成本效益。
容器:无论使用情况如何,容器可能更昂贵,因为它们需要更多的基础架构管理,并且通常对整个基础架构收取固定费用。
开发成本
无服务器:由于开发人员可以更专注于编写代码而不是管理基础架构,因此无服务器的开发成本可能较低。这可能导致较低的开发成本和更快的上市时间。
容器:对于容器,需要管理和配置额外的基础架构,这可能会消耗开发人员的时间和金钱。这可能导致较高的开发费用和较长的上市时间。
性能
无服务器:对于较小的应用程序,无服务器可以提供良好的性能,因为云提供商处理底层基础架构,并根据需求动态增加资源。对于较大或更复杂的程序,可能会存在冷启动或其他因素影响性能。
容器:另一方面,容器需要更多的人工配置和性能优化,但它们可以为更大、更复杂的应用程序提供出色的性能。为满足需求,它们还可以进行水平扩展。
与语言或平台的兼容性
无服务器:Node.js、Python和Java是众所周知的与无服务器技术兼容的部分编程语言。无服务器只支持少数编程语言,不同的无服务器平台允许的具体无服务器语言也会有所不同。
容器:开发人员必须确保应用程序和支持基础架构与容器兼容,因为它们能够使用多种计算机语言和平台。只要主机服务器接受该语言,就可以将任何语言创建的应用程序放入容器中。
供应商锁定
无服务器:由于开发人员必须依赖云提供商的基础设施和服务,因此无服务器设计存在供应商锁定的风险。
容器:容器降低了供应商锁定的风险,因为在选择供应商和基础架构管理方面更加灵活。
安全性
无服务器:由于云提供商处理基础设施的安全性和补丁更新,无服务器系统可能更安全。但是,开发人员必须确保他们的代码安全,并遵循最佳实践。
容器:容器也可以具有安全性,尽管这需要更多的人工基础架构维护和配置。开发人员需要遵循最佳实践,并确保他们的容器已经应用了补丁。
日志
无服务器:无服务器架构提供了集中化的日志记录和监控,使开发人员更容易监视和检查应用程序日志。
容器:由于容器需要更多的手动配置进行日志记录和监控,因此跟踪和分析应用程序日志更具挑战性。
用例
由于其适应性,无服务器和容器技术都非常适合多种用例。随着这些技术的发展和成熟,它们越来越受欢迎,并在各种项目中发展和应用。
以下是一些最常见的使用情况,可以在无服务器与容器中实现。
无服务器
一、Web应用程序
Web应用程序是可以通过web浏览器或其他基于web的接口访问的应用程序。它们旨在实现各种功能,包括电子商务、社交网络、协作工具和内容管理系统。处理意外的流量峰值是开发在线应用程序时的主要问题之一,这可能是由用户活动的急剧增加、营销活动或外部事件引起的。在传统系统中,这通常需要通过添加更多服务器或计算资源来扩展底层基础设施,这可能耗时且昂贵。
无服务器架构可以解决这个问题,它使得Web应用程序能够根据需求变化自由地扩展或缩减而不需要手动干预。这是通过将应用程序分解为可管理的独立函数来实现的,这些函数可以根据事件或触发器的需求即时运行。
无服务器架构适用于开发在线应用程序的原因如下:
- 可扩展性:无服务器函数基于需求动态扩展,因此它们可以处理意外的流量峰值而不会降低性能或可靠性。这使得Web应用程序即使在高峰时段也能保持高度可用和响应。
- 成本效益:无服务器架构允许您避免维护庞大的专用基础设施,而只需按需支付所需的计算资源费用。由于您只支付实际使用的资源,这可能是对遇到波动流量模式的在线服务而言成本效益较高的解决方案。
- 敏捷性:无服务器架构使开发人员不必担心管理底层基础设施,因此他们可以专注于快速创建和部署应用程序。结果,开发人员可以更快、更敏捷地尝试和测试新功能,而不必担心扩展问题。
总体而言,由于无服务器架构能够实现可扩展、成本效益和灵活的开发和部署,所以它非常适合开发需要应对意外流量激增的在线应用程序。
二、后端处理
数据处理、文件处理和数据分析是一些可能需要大量时间和资源的任务,因此它们非常适合使用无服务器计算。开发人员可以使用无服务器架构创建和执行这些操作,而无需担心管理底层基础架构。
由于可以根据需求自动扩展,无服务器函数可以在没有任何手动干预的情况下处理大量数据。对于像数据分析这样的任务,需要按照特定顺序或序列处理大量数据,这可以从中获益。
无服务器计算的经济性是进行数据处理、文件处理和数据分析等操作的重要优势。与维护庞大的专用基础设施不同,无服务器架构只需要在调用函数时支付所使用的计算资源费用。
总体而言,由于它能够以批处理或实时方式处理数据,并且具有经济性和可扩展性,所以无服务器计算非常适合进行数据处理、文件处理和数据分析等任务。
三、事件驱动的应用程序
事件驱动的应用程序是为了对特定事件或触发器作出反应而创建的,比如收到消息或用户操作。由于无服务器计算使得开发人员可以创建在特定事件或条件下触发的代码,而无需管理基础设施,因此非常适合创建事件驱动的应用程序。
在事件驱动架构中,事件可以由各种来源生成,包括数据库、消息系统或物联网(IoT)设备。无服务器函数可以在响应事件时被触发执行特定的操作或一系列操作。
例如,当文件上传到存储桶时,可以使用无服务器函数自动处理该文件,例如调整图片大小或从文档中提取内容。类似地,当向数据库添加新条目时,可以触发无服务器函数来更新其他系统,例如发送消息或启动工作流程。
由于无服务器函数能够处理大量的事件而不需要手动干预,因此无服务器架构使得事件驱动的应用程序能够根据需求自动扩展。
总体而言,无服务器计算是创建事件驱动的应用程序的最佳选择,因为它使得程序员能够设计根据特定事件或情况触发的代码,并且具有可扩展性和经济性。
容器
一、应用程序部署
开发和交付软件的过程必须包括应用程序的部署。在实际情况中,容器已经成为一种常见的方法来实现应用程序的部署。下面更详细地解释了容器如何用于应用程序部署:
- 一致性:无论使用什么底层基础设施或操作系统,容器都提供了一个一致的环境来运行应用程序。换句话说,当相同的容器化应用程序在开发、测试和生产等不同环境中部署时,不会出现兼容性问题。
- 可靠性:使用容器时,应用程序表现更加一致和可靠,因为它们被设计为与底层基础设施隔离。这样做是为了将运行应用程序所需的所有依赖项和库打包到容器中,使其始终可访问和更新。
- 可扩展性:对于工作负载波动或流量不可预测的应用程序来说,容器非常适合,因为可以根据需求快速扩展或缩小规模。这是因为可以使用容器编排系统(如Kubernetes或Docker Swarm)来部署和管理容器,并提供自动扩展和负载平衡功能。
- 可移植性:容器是可移植的,可以轻松地将它们从一个环境移动到另一个环境,例如从开发人员的笔记本电脑到测试或生产环境。这是因为容器被设计为可移植和轻量级,并且它们附带了所有必要的依赖项和库。
总体而言,容器是在实际情况中部署应用程序的一种一致可靠的方法。对于希望简化应用程序部署流程并确保其应用程序在各种环境中正常运行的企业来说,容器是一个完美的选择,因为它们具有一致性、可靠性、可扩展性和可移植性。通过使用容器,企业可以提高应用程序部署过程的效率,并确保应用程序始终以正确的方式运行。
二、持续集成和持续部署(CI/CD)
持续集成和持续部署(CI/CD)是一种软件开发实践,旨在自动化整个软件开发过程,从代码更改到在生产环境中部署。容器为应用程序的测试、构建和部署提供了一个稳定可靠的环境,使其成为CI/CD流水线实施的理想选择。
在CI/CD流水线中使用容器具有以下优势:
- 一致性:通过为测试、开发和部署程序提供一致的环境,容器使得在各种环境中获得相同的结果成为可能。
- 可扩展性:由于容器可以轻松地根据开发过程的需求进行扩展或缩减,资源得到有效利用。
- 自动化:使用容器可以自动进行测试、构建和部署。
总体而言,容器为软件开发和部署提供了统一、可扩展和自动化的环境,使其成为CI/CD流水线实施的理想选择。
三、微服务
应用程序被拆分成较小的独立服务,可以使用微服务架构方法单独创建、部署和管理。由于容器提供了轻量级和可移植的环境来交付和维护单个微服务,它们是实施微服务架构的绝佳方式。
在微服务架构中使用容器有多种优势:
- 独立部署:由于容器的存在,每个微服务可以独立部署,这使得管理和部署微服务更加简单,因为对一个微服务的更改不会影响其他微服务。
- 隔离性:容器在不同的微服务之间提供了隔离,防止一个微服务的问题或故障影响其他微服务。
- 一致性:通过为微服务部署和管理提供一致的环境,容器使得在各种环境中获得相同的结果成为可能。
- 可扩展性:由于容器可以根据特定微服务的需求进行快速扩展或缩减,因此更加简单地管理各种服务之间的可变工作负载。
四、现代化传统应用程序
现代化传统应用程序涉及对其进行修改或迁移到更新的平台或技术,以增加其功能性、性能和可扩展性。由于容器为部署和维护程序提供了灵活且可扩展的环境,因此它们可以在传统应用程序的现代化中使用。
使用容器进行传统应用程序现代化有多种优势:
- 性能提升:容器提供了一个轻便且可移植的环境来部署应用程序,可以增强传统应用程序的性能。
- 增加敏捷性:容器使得管理和部署传统程序更加简单,从而更容易集成更新和功能增强。
- 节省成本:由于容器为交付和维护程序提供了灵活且可扩展的环境,它们可以降低更新传统系统的成本。
总的来说,容器是现代化传统应用程序的绝佳方式,因为它们可以提高传统应用程序的性能、敏捷性和可扩展性,使得管理和更新这些应用程序变得更加简单。
无服务器架构的组件
一个设计、部署和管理无服务器应用的环境通常由几个组件协同工作。以下是无服务器环境的主要组件:
- 云提供商:提供运行无服务器应用所需的基础设施和服务。例如亚马逊网络服务(AWS)、谷歌云平台(GCP)或微软Azure。
- 函数即服务:无服务器架构的基础是FaaS。FaaS使程序员能够创建小型专用函数,这些函数在响应事件(如API调用或数据变化)时运行。
- 事件源:事件源产生事件,启动无服务器函数。数据库、消息队列系统和HTTP请求是一些事件源的示例。
- API网关:API网关是无服务器应用所有传入请求的入口点。它接收客户端HTTP请求,并将其发送到正确的下游服务。
- 数据库:无服务器应用通常使用NoSQL数据库(如DynamoDB)来管理和存储数据。
- 监控和日志记录:使用监控和日志记录工具来监视无服务器应用的性能和整体状况,及早发现问题并解决问题。
- 安全性:无服务器安全性包括保护应用代码,确保访问控制设置正确,并防范常见安全威胁,如SQL注入和跨站脚本(XSS)攻击。
容器架构的组件
容器环境通常由几个部分组成,它们共同工作以创建一个平台,用于开发、部署和管理容器化应用程序。容器环境的基本要素如下:
- 容器运行时:用于管理和运行容器的软件被称为容器运行时。容器运行时维护着容器的生命周期,为容器中的应用程序提供隔离的环境,并确保容器能够访问所需的资源。
- 容器镜像:容器镜像是一个小巧独立的软件包,包括运行容器化应用程序所需的应用代码、依赖项和配置。通常,容器镜像存储在Docker Hub或AWS Elastic Container Registry(ECR)等容器注册表中。
- 容器存储:通过容器存储,可以存储和访问数据。本地卷和网络附加存储(NAS)是常见的容器存储解决方案组件。
- 容器监控:对容器进行监控可以了解到容器化应用程序的功能和状态。通常,通过容器监控应用程序收集CPU和内存使用情况、网络流量和应用日志等指标。
- 容器安全性:在任何一个容器环境中,安全性都非常重要。容器安全性包括保护容器运行时环境、容器镜像以及将各个容器相互隔离。访问限制、漏洞扫描和加密通常是常见的容器安全特性。
- 容器编排工具:自动化管理、扩展和部署容器化应用程序的系统被称为容器编排工具。Kubernetes、Docker Swarm以及Amazon EKS或ECS都是容器编排工具的示例。
什么情况下不适合使用无服务器?
在某些情况下,尽管无服务器架构已经变得广受欢迎并非常有用,但仍然存在一些情况,可能不适合使用无服务器。以下是一些情况,您可能需要考虑使用其他替代方案:
长时间运行的函数
无服务器可能不是理想选择的情况是针对长时间运行的函数。由于无服务器函数的设计是无状态和事件驱动的,因此对于需要持久状态或持续计算的长时间过程,无服务器函数不合适。如果您的应用程序需要函数持续运行较长时间,则可能需要选择容器等选项,这可以更好地控制环境并允许长时间运行的进程。此外,无服务器函数有最大运行时间限制,可能不足以满足您的需求。此外,在无服务器平台上进行长时间运行的进程可能会造成更高的成本。
使用不受支持的编程语言
如果您需要使用不受支持的编程语言,这也是不使用无服务器的原因之一。虽然大多数无服务器平台支持许多广泛使用的编程语言,包括Node.js、Python和Java,但某些语言或框架可能不受支持。这可能会使您难以使用所选择的框架或语言,迫使您要么选择受支持的语言,要么选择具有更大自由度的其他云计算服务。
供应商锁定的风险
无服务器解决方案依赖于云提供商提供的基础设施和服务,这可能带来供应商锁定的风险。切换到另一个供应商或平台可能具有挑战性且耗时。结果可能是您依赖于一个供应商,无法转向另一个供应商,即使后者更经济实惠或提供更优质的服务。因此,如果避免供应商锁定是目标,您可能需要考虑替代方案,这些方案提供更大的灵活性和可移植性。
最终,您选择采用无服务器架构的决策应基于您的应用程序特定需求。尽管无服务器架构有许多优点,但它并不总是最佳选择。
什么情况下不适合使用容器?
尽管容器是一种有效的技术,具有许多优点,但在以下情况下可能不是理想的选择:
大型单体应用程序
容器的典型目的是在单独的环境中运行单个进程或应用程序。使用容器化大型、庞大且具有许多组件的单体应用程序可能不是一个好主意。
低资源环境
容器需要大量的系统资源,例如CPU、RAM和存储空间,以使其正常运行。在资源有限的环境中运行容器可能会过度消耗资源,并严重影响性能,例如嵌入式系统或物联网设备。此外,在资源有限的环境中成功管理和扩展容器化应用程序可能很困难,因为它们可能没有支持容器编排系统所需的基础设施。
桌面应用程序
一般来说,桌面应用程序不应使用容器。容器旨在在服务器环境中执行独立的应用程序,而不是像桌面应用程序一样直接安装和运行在用户的计算机上。使用容器打包和分发桌面应用程序可能具有挑战性,并且可能会出现依赖于用户硬件和操作系统的问题。
小型和简单应用程序
对于小型和基本应用程序,容器化的开销可能超过了优势。在这种情况下,直接在主机操作系统上运行程序可能更简单、更有效。
最终,尽管容器是一种强大的技术,但在决定是否采用之前,考虑到您的独特用例和要求非常重要。
什么情况下不适合使用微服务?
尽管微服务有许多优点,但它们可能并不总是每个项目的最佳选择。以下是一些使用微服务可能不是一个好主意的情况:
小型和简单应用程序
如果您的应用程序规模较小且相对简单,与微服务架构相比,单块设计可能更合适。对于一个小型应用程序来说,使用微服务架构可能会增加复杂性和开销。
有限的预算
如果预算有限,微服务可能不是最佳选择,因为创建和部署微服务可能比使用单块架构更昂贵。
小型且经验不足的开发团队
如果您的团队规模小且对该架构缺乏经验,正确实施微服务可能很困难,因为开发和部署微服务需要较高水平的能力和协调能力。
低复杂度应用程序
如果您的应用程序的复杂性要求较低,单块设计可能足够。对于较简单的应用程序使用微服务架构可能会增加额外的复杂性,因为它旨在处理复杂的应用程序。
遗留应用程序
将遗留系统整合到微服务架构中可能具有挑战性,可能会导致兼容性问题并增加复杂性。
因此,在决定是否部署微服务之前,有必要仔细评估项目的需求,并权衡其优缺点。
总结
现在,让我们通过以下表格总结一下Serverless和容器之间的区别。请记住,每种技术都有其优缺点,决定使用哪种技术最终取决于项目的具体需求。
类别 | 无服务器 | 容器 |
上线时间 | 由于减少了基础设施管理,更快上线 | 由于需要更多设置和管理工作,上线时间较慢 |
易用性 | 简化开发和部署 | 可移植但难以管理,并需要专业知识 |
扩展性 | 根据使用情况自动扩展 | 可横向扩展,但需要手动操作 |
高可用性 | 非常弹性并可用于处理故障 | 具有弹性,但需要手动故障转移机制 |
云端成本 | 由于按需付费模式成本更低 | 由于固定基础设施成本成本较高 |
开发成本 | 由于减少了基础设施管理成本较低 | 由于额外的基础设施管理成本较高 |
性能 | 对于较小的应用程序具有良好的性能,但可能存在问题 | 对于更大、更复杂的应用程序具有出色的性能 |
兼容性 | 支持特定的编程语言和平台 | 兼容主机服务器支持的任何语言 |
供应商锁定 | 由于依赖云提供商存在供应商锁定风险 | 由于供应商选择灵活性高,供应商锁定风险较低 |
安全性 | 由于云提供商处理基础设施更安全 | 在适当维护和配置后可以保持安全 |
日志 | 提供集中式日志记录和监控 | 跟踪和分析应用程序日志更具挑战性 |
结论
在选择应用程序的理想架构时,没有一种通用的方法适用于所有情况。Serverless、容器和微服务都是强大的技术,每种技术都有其特定的优势和缺点。您的项目需求,如应用程序复杂性、预算、团队技能和与现有系统的集成,应是您在Serverless与容器之间选择时的基础。
在选择Serverless与容器之间时,必须权衡可扩展性、适应性和维护成本。如果您的应用程序需要长时间运行的函数或不支持的编程语言,则Serverless可能不是理想选择。如果您拥有一个小型或简单的应用程序、有限的预算或一个小而经验不足的开发团队,则微服务可能不是最经济有效的选择。如果您的应用程序是一个桌面应用程序、一个庞大的单体系统或资源有限,则容器可能不是最佳选择。
重要的是要记住,在Serverless与容器之间进行选择对于您的应用程序来说是一个重要决策,不应轻率对待。