最近两年我不知道你是否和我拥有同样的感受,编程容易了许多,同时乐趣也少了许多
最近有两个契机让我写这篇文章,一是过去一年我陆续把我所有 side project 后端从 Azure App Service 迁移到 Digital Ocean(以下简称 DC) 的 Droplet(Virtual Machine),再迁移到 DC 的 K8S,目的是剥离应用内托管型(managed)资源;前端顺便也从 Azure Static Web Apps 迁移到 Vercel;二是最近读完《Competing in the Age of AI》,其中关于于 operation model 的论述与近期迁移应用的感受不谋而合
书中把公司价值划分为两部分,首先是商业模型(business model),即为消费者带来了何种价值;其次是运营模型(operation model),即如何将价值传递到消费者手中。运营的难点不在交付本身,而在于如何大规模(scale)、大范围(scope)交付,并且持续对交付方法改进和创新(learning)
同样,如果代码的价值在于上线(通俗说派上用场),无论是对自己还是客户还是用户,那么交付对我们来说同样重要,以上所说的大规模、大范围、以及保证持续改进的交付难点也同样成立。
先上线,剩下的以后再说。
你们有没有想过 Netlify 和 Vercel 究竟是做什么生意的?如果你的答案依然是 JAM stack,只能说明你已经 out 了。不妨去看看 Netlify 官网的 slogan,甚至不用是 slogan,看看网站首页的 title 写的是什么:Scale & Ship Faster with a Composable Web Architecture
Netlify 所做的正如上述所标榜的,帮助代码更快的交付上线。换而言之,它们售卖的的是一站式 web 应用的部署解决方案,除 host 和流水线外,还提供免费的用户行为分析、页面性能监控、日志等工具,以及 Redis/SQL/Blob 数据库。
Azure 不是也提供类似的服务吗?问题的关键在于不同平台间的开发者体验,Vercel 能够真正做到上述服务一键集成,你会明显感觉到 Vercel 在加速你的交付,让你更快得到对于产品的反馈。而在 Azure 下开发更像是赤裸裸的买卖,Azure 团队按照他们的理解提供一个最低限度可以使用产品,至于多好用,多大程度能和其它 Azure 服务契合则不在他们的考虑范围内。如下图所示在 Vercel 的 dashboard 上,你可以纵览所有从部署状态到线上监测一系列信息。试想一下如果在 Azure 上集成所有对应的功能并呈现类似的 dashboard 需要付出多少外的精力
再简单聊聊 DevSpace。这里的 DevSpace,也可以是 tilt,可以是 skaffold、telepresence
GitOps 无疑是伟大的,但这种伟大里依然充满了“一板一眼”——我的一次上线需要经过 push 代码、创建 release、推送镜像到GHCR、更新 yaml、通过 ArgoCD 部署。我理解它们是 necessay evil。
相比之下 DevSpace 看上去是反流程的,它可以帮助你在本地直接创建镜像并执行部署,还允许热更新容器内文件。即便是创建镜像,我发现它利用也非是既有的 pipeline,而是借助 buildkit 在我的集群上创建一个 local registry 并将镜像储存在此。
别搞糊涂了,生产环境和开发环境具有完全相反的气质,我们希望生产环境稳定、可追溯,这是 GitOps 的优势所在,但开发过程具有破坏性、需要不停试错,DevSpace 着重解决的则是开发体验问题,对于代码修改它可以带来高效的反馈。
上图已经流传了很多年,图中的 compiling 可以替换成 uploading, deploying,running test 等等。过去十年它是事实,现在应该只是一个笑话
在 Vercel 和 DevSapce上我们看到了一类区别于传统的开发方式,这里没有 pipeline,没有 IaC,没有手动的统计埋点,无需申请第三方资源,从 GitHub 上导入 repo 的那一刻起,它自动为你匹配部署脚本,寻找项目入口。开发者所需要做的,就是专心编写他所需要的业务代码。
模板化的项目是带来这些便利的主要原因,继续往上追溯,主流前端框架自带 CLI 工具的流行功不可没,从大到创建一个新项目小到执行编译,命令行一键即可完成。无论是 React,Vue 还是 Angular,你都不会在官方的教程里找到专门的章节教你为项目编写 webpack 或者 vite 的配置。也许是因为习惯了早年间凡事都需要自己动手的工作方式,我花了很长时间才想通并接受这件事:传统从0到1搭建项目的能力已不再重要。
越来越多的环节像一个个黑盒出现在开发流程中,在此之前如果我对 pipeline 感兴趣,我可以阅读 .github 文件夹中的代码看 action 是如何定义的,而现在我连机会都没有了。连同代码被一同干掉的还有程序员的编程乐趣。站在交付的角度上来说这种乐趣并没有什么道理:为什么我要花上几天的时间只为了研究如何写一段 yaml 把代码送上线运行,更何况这段代码带来不了任何产品收益。
最近另一个类似的体验是,Next.js 编写起来太无趣了,不是说它不够好,而是问题在于它太好到你只能这么写。说起来有些贱,我很怀念那个一种功能有十几个写法,然后这十几个写法还有鄙视链的“坏”时光。当我们再度审视代码的生命周期,你会发现所有人努力的目标,是想让程序员尽可能少的关心核心业务代码以外的事情。一切一切都在想方设法优化运营模型。很明显个性化配置和重复劳动在规模化前是不受欢迎的。
也许换个思路会好受一些:当你加入一家公司之后,发现同等体量的应用利用市面上的工具可以做到随时上线;而你们的产品却只能选择在每个周六凌晨部署,并需要若干人值班守候,这听上去让人有些失望是不是。