@findex 使用 k8s+和 serverless 的技术栈要求和研发投入有很大差别，对于中小型项目或是商业模式验证项目来说，从成本及收益角度 serverless 技术可能更适用。至于受制于人，极端点 ISP 说给你断网不就断网。只要你做的东西和云服务商没有明显利益冲突，我认为一般都是安全的。在阿里云做个垂直电商应用、腾讯云做个小众社交应用也不会说封就封吧。

@findex 你举的 Google Firebase 扣费案例其实套用到 COS/CDN 之类的也一样，只要在公网暴露，被 DDOS 要么下线要么花钱买高防。
至于“别人想给你封号阻断很随意”，要解决这个问题连机房托管恐怕都不行，只能走自建机房的路了。

“自己配置 k8s+容器就完事了”
即使是自建 k8s 集群跑应用，依然会面临 0 访问量情况下机器资源空跑的情况，我之前在的公司一年在公有云费用几千万，就是用传统自建集群方式跑应用，每个应用最少 2 个节点运行，但是应用负载情况非常符合 2/8 原则，在上班时间之外资源利用率非常低，整个架构设计非常有问题。
所以在我看来 serverless 是目前“0 驻留实例做到应用高可用”的极低成本方式。

自建集群还会面临各种问题，简单列一下就有：
1：服务器的软件安装升级维护、漏洞响应修复、参数调优；
2：服务高可用集群搭建、伸缩实现、演练验证；
3：监控平台搭建、监控指标采集、监控告警建设；
4：日志平台搭建、日志采集、链路追踪搭建；
5：注册中心、配置中心、分布式定时任务系统等的高可用建设；

要做到以上要求，可不是“就是多耗费点精力 devops”那么简单，是要运维团队值班的。

而在 serverless 使用 docker 镜像运行，是为了可以自主控制应用环境（比如要部署漏洞扫描器），同时又摆脱云厂商那些拉跨的设计(serverless framework 、layer 等)锁定。

@murmur @ClericPy @InvincibleDream @shuimugan

从使用 Google Firebase 套件来说，做 App ，能不用 Google 套，Amazon 套，就不要用。虽然 Google 会给一些人发个 Google Developer Expert （ GDE ）的称号，“表彰”你是 Google 全家桶用户，被很多人“沾沾自喜”的放到 Twitter 个人说明上。很多 app 开发者连基本的配置环境都不会，就会用个 Google 套开发 app ，后期的定制和业务改变都被 Google 牵制。Reddit 上有人用了 Google Firebase 套被竞争对手打了几天，账单从每天几百刀干到每天几万刀。给谷歌诉苦，谷歌坚持收费。因为 Google Firebase 没有及时阻断（应该是倾向于利益最大化）。中小型创业企业这样被打，几天可以搞破产。
啥玩意都放到别人家里，别人想给你封号阻断很随意。（但不得不说，用起来开发速度快多了）

另外可以自己配置一套 serverless 服务，日志，用户，api 都可以。日后还可添加集群。考虑一下某个开源的 supabase ，起码数据在自己那里。

既然都用 docker/podman/lxc 等来控制镜像开发了，还上啥 serverless ，自己配置 k8s+容器就完事了。就是多耗费点精力 devops 。增加运维成本==增加系统安全性

当你用 serverless 快速做 demo 的时候，未来迁移逻辑到 k8s+容器，这个过程或许是痛苦的。还不如一开始就是这套。

@ifplusor

只是说适合走事件触发, 但是也可以当 rpc 解耦玩同步, 门槛低上限高, 就看架构师水平了

我这边 faas 就是当微服务用, aws 上 boto3 直接同步调用也没啥问题, 用自带的 rest gateway 也很容易配置各种鉴权限流, 就是要花点钱而且 30 秒超时有时候不太习惯.

关键是释放了不少计算资源, 各种适用场景就不赘述了, 这功能解耦粒度比微服务还细, 管它是什么语言实现的反正调用一个函数名字传入内容我就要指定结果

对于低频高计算(平时的定时任务)类型的任务, 比 spot 实例管理起来简单, 真有那种耗时长的再考虑竞价实例. 给我印象最深的就是解决现在公司缺运维导致的机器资源要么长久空闲要么恶意抢占, 钱都花刀把上了

简单地说, 你那边的计算密集任务依然可以留一个调度中心, 有任务在 Serverless 上跑等结果好了返回就行了, 一个 CPU 几百协程还是挺有意思的.

一句话: 没有银弹, all-in 有风险

serverless 的使用成本在一些场景并不低，至少在一个我做过的项目是这样的。serverless 特别适用于实现早期原型、存在不确定性的需求。业务成熟还是推荐自己维护优化。

学我觉得值得学，比如我就会面对一种场景，就是做机器学习，需要大量资源那种，不定时做，如果是用传统虚拟机或者自己的 k8 都可能会不够，用公有云的 serverless 就可以节省很多成本

@ClericPy 看过一些调查报告，国外上 FaaS 的用户还是挺多的。但上了 FaaS 架构模型就要变，这对复杂业务的迁移阻力很大。从 rpc 转 eda ，这难度太大了。

faas 减少运维成本带来的优势明摆着在那了, 至于说绑定什么的, 对象存储和数据库该迁还是得迁, 不可能在一家吊死

去年跟 aws 顾问聊到现在越来越多企业开始布局各类云基础设施, 有的尝试 all-in serverless 也没毛病, 大厂玩家们, 更是多家云混合一起用, 不会只用一家的

至于现状... 去年技术分享了 serverless 同事们不怎么愿意迁, 然后临时调去帮着运维砍成本, 提出来的把花钱的架构拆到 Serverless / spot 竞价实例 / K8S (这几个也是顾问赞同的) 一项都没通过, 只能说习惯是个挺可怕的东西, 不过因为运维走了不愿意担风险也能 "李姐"

最佳实践什么的, 国内相关文章都不多, 之前调研是硬啃的官方文档, 比较麻烦的大概就是服务治理相关经验, 但是哪的服务不用治理的, 现在公司里机器跑的已经乱成一锅粥各种抢资源...

至于成本真的是之前没想到的低, 迁了俩日常定时爬虫任务, 连免费额度都没用光... 之前 faas 貌似都用在 s3 触发的图片裁剪和视频截图上面了

就个人而言, 还是挺希望去一家 all-in Serverless 或者别的云原生相关涨涨经验的, 就竞价实例号称节省 90% 成本这东西, 我就愿意写一大堆无状态 slave 过足瘾的

有没有最佳实践啊

@murmur 一知半解不要信口胡说误导他人。迁移 serverless 方式多种方案选择，肯定要做一些工作，但”掐的死死的“远远谈不上。

@murmur 说明 serverless 要反过来用。面向越多的人提供越多的 serverless 越好。让别人绑定你的服务。

现在 Serverless 都支持了使用 Docker 镜像部署，感觉没有什么绑定不绑定的说法了。核心理念是按量付费，传统项目你的应用怎么说也要 2 个不同机器上在跑才叫高可用，而且应用流量也有高峰低谷时间，低谷的时候就要考虑如何避免浪费资源。在 Serverless 上可以是 0 实例做到高可用，虽然是云厂商在资源上帮你做了兜底，但是你自己节省是实打实的。

传统部署你得考虑这些：
服务器的软件安装升级维护、漏洞修复、参数调优 -> 服务器都没了，注意一下 docker 安全就好，用一下 docker 镜像安全扫描和代码依赖扫描可以解决；
服务高可用集群搭建、伸缩实现 -> 丢个函数上去，配置一下伸缩策略就搞定了；
监控平台搭建、监控指标采集、监控告警建设 -> serverless 可以配置指标和告警，比如 web 函数使用云 api 网关，把 api 采集到的指标做到告警里；
日志平台搭建、日志采集、链路追踪搭建 -> 直接往控制台输出，serverless 一般会集成自己云的日志服务，简单配置就可以让开发登录来排查日志了；
高可用的注册中心 /配置中心 -> 一个函数分配一个域名，配置塞环境变量里，部署时候动态写入就好；
高可用的分布式定时任务搭建 -> serverless 自带定时器；

搞定上面这些你得算下要招什么人来持续维护，成本有多少，搞定就可以下云防止云厂商绑定。

@murmur 哈哈哈哈是这个道理，也就个人玩玩或者临时用跑个短期项目行

我觉得是未来；但可能是很远的未来。

就目前的 serverless 的话，感觉昙花一现，限制太大了而且没有统一规范
从 google trends 热度来看，看不出来有成为未来的趋势，反而有开始走下坡路的趋势

我几年前使用微信小程序的云开发做过一个小应用。
使用小程序云数据库+云函数，
开发非常简单，感觉极大的拉低了个人做全栈开发的门槛。
费用方面，基础套餐就够用了，如果真的是企业用，再卖个套餐（费用非常低）。

唯一的弊端就是平台依耐性。其他都好。香的不行

serverless 的本质在于把脖子伸出来给别人掐，包括云也是这样，云你还能带着镜像和数据库跑路，等 serverless 的时候连 api 都是在别人生态上，一下就给你掐的死死的

“前景如何”，我只能说是未来之一，有用有价值，但又没到必学必用不可。
“值不值得投入时间学习”，如果你现在没有使用它的需求，那么学不学都可以，而且初步入门和使用的话，花个一两天看看玩玩就差不多了，也不难。