Serverless和Kubernetes到底选哪个，其实没必要非得争个输赢吧

（来源：知乎专栏“云原生技术漫谈”）现在一提到应用部署，很多人就会把Serverless和Kubernetes拿出来对比，非要争个你死我活，好像选了其中一个，另一个就彻底过时了，但说实话，这种非黑即白的想法，有点像是问“出门是开车好还是坐飞机好”一样，答案完全取决于你要去哪里、和谁去、有多少行李以及你的预算是多少，它们俩根本就不是为了解决同一个层面的问题而生的，硬要比较，就像是拿螺丝刀和锤子比谁更好用——工具本身没有高下之分，关键看你手里拿的是什么“活儿”。

（来源：AWS官方博客对计算服务的比喻）我们可以把Kubernetes想象成一套功能超级强大的“自助厨房”，这个厨房里，灶台、烤箱、锅碗瓢盆、各种调料一应俱全，你拥有这个厨房的完全控制权，可以决定用什么牌子的锅，火候开到多大，什么时候放盐，但与此同时，你也要负责很多事情：要去买菜、洗菜、切菜，用完了还得自己打扫厨房，清洗所有厨具，Kubernetes就是这样，它给了你极大的灵活性和控制力，你可以精细地调配每一个“容器”的资源（比如CPU和内存），可以部署任何你想部署的应用，无论它多么复杂或古老，但这份“自由”的代价就是，你需要一个团队来“运维”这个厨房，也就是要持续维护Kubernetes集群本身，负责它的安全、升级、扩缩容和故障排除，这对于需要高度定制化、有复杂微服务架构的大型企业来说,是非常合适的选择。

（来源：某技术社区关于Serverless的讨论帖）而Serverless则更像是一家高档餐厅的“送餐上门”服务，你根本不需要关心厨房在哪里，厨师是谁，用的是燃气灶还是电磁炉，你只需要从菜单上点菜（也就是写好你的业务代码逻辑），然后餐厅就会把做好的菜准时送到你面前，你按吃的菜付费，不用为厨房的租金、厨师的工资或者闲置的灶台买单，Serverless的精髓就在于“无服务器”，开发者完全不用操心服务器运维，只需要关注最核心的业务代码，应用会根据访问量自动伸缩，高峰期来临时会自动准备更多“厨师”来炒菜，流量过去后又会自动减少，你只为实际执行的代码运行时间付费，这对于突发流量明显、业务逻辑相对独立、追求极致开发效率的场景（比如数据处理、API后端、图片处理等）简直是神器。

（来源：CNCF年度调查报告分析）你看，争论“自助厨房”和“送餐服务”哪个更好，意义不大，一个追求美食创作乐趣和款待众多宾客的家庭，可能会选择自建厨房；而一个忙碌的上班族，只想快速吃一顿可口晚餐，显然送餐服务更划算省心，在实际工作中，很多公司采用的也是混合模式，用Kubernetes这套“自助厨房”来部署那些核心的、需要7x24小时稳定运行、服务间调用复杂的核心系统；对于一些边缘的、偶发性的业务功能，比如用户上传头像后生成不同尺寸的缩略图，就用Serverless函数来处理，这样既保证了核心系统的可控性,又享受了Serverless带来的敏捷和成本优势。

（来源：一位资深架构师在技术大会上的分享）选择哪一个，和你团队的技术能力也息息相关，如果一个团队里没有熟悉容器、网络和分布式系统的高手，那么盲目上马Kubernetes，很可能把这个强大的工具变成一场运维噩梦，反而拖慢了业务发展，相反，如果团队规模小，但业务创新速度快，那么从Serverless起步，可以让他们快速验证想法，把产品推向市场，这才是最明智的选择，技术是为人服务的，是推动业务前进的轮子,而不是用来炫技的奖杯。

Serverless和Kubernetes不是取代关系，而是互补关系，它们共同构成了现代云计算中丰富的应用托管生态，作为开发者或架构师，我们的任务不是站队，而是清晰地理解我们自己项目的真实需求：我们的应用特点是什么？流量模式是怎样的？团队的技术储备如何？长期的运维成本预算是多少？想清楚了这些问题，该选什么，或者如何组合使用，答案自然就清晰了，放下无谓的争论，把精力花在如何用最合适的工具解决实际问题上,这才是技术人应有的务实态度。