自己做产品一年多了，对于个人开发者如何购买云服务有一些经验可以分享

过去两年时间自己写了一个应用 site2share，运维过程中积累了一些经验。原文在这里：https://www.v2think.com/how-to-pick-up-cloud-service，跳转阅读体验更加。

这文章至少值一千元，因为这是我保守估计花出去的冤枉钱（请自行脑部一个苦笑的 emoji ）

文章中会穿插选择云服务的一些建议，当然也会提供一些“薅羊毛”的技巧。不过在此之前我们要想清楚一件更重要的事情：我为了什么购买云服务

做产品还是做技术

这个问题不仅决定了你接下来的购买策略，还是你编码开始的前提。

以技术为出发点想达到的目的是：我想把代码写对（先学会），并且把代码写好（然后精通），代码是一切工作的出发点， 编码过程中的困难越多越好，能够遇到的业务场景越复杂越好，对行业内的最佳实践越熟悉越好，收获和实际投入的代码量成正比。

如果从产品侧看，好代码不等于好产品，验证想法的可行性才是当务之急。在有用户买单前，人天、机器、代码都是沉默成本，对于个人开发者而言这些都是自掏腰包承担的损失，所以从做产品出发“快”其实是最高优先级。我相信你或多或少体验过这类技术与产品的矛盾：高质量的代码离不开时间投入，但时间又是一款产品“跑马圈地”最大的敌人——这样的选择一点也不难，公司会毫不犹豫的牺牲前者，如果你在互联网创业公司工作过一定更加深有体会。产品与技术并非二元对立，你依然可以在开发产品的过程中可以刻意熟练某项技术，只不过同时身兼产品和代码作者的你需要小心计算成本和回报。

正如标题所示，本文所处视角是个人（独立）开发者。对于这类群体而言，虽然他们自带编码天赋点，但是把一款产品运营好远比写出完美代码重要，也就是说在本文里“云”所服务的首要对象是产品。

一旦接受了产品优先的前提，你就要开始尝试“克服”各种代码洁癖，学会接受开发产品中的各种不完美。假如回到两年前给我机会重写 site2share，编码实现上我会做大量裁剪，例如：

• 使用原生 SQL 语句而不是 ORM 做数据存储
• 不写测试
• 不做 CI/CD ，而是选择本地编译、人工压缩、手动上传部署

如果你还是不能理解我为什么推崇各类显而易见的反模式，读下去就知道了

购买哪些服务

正确的提问题应该是递进式的：

• 产品的哪些功能是需要服务支撑的？
• 这些服务我可否自行编写？
• 如何判断又或是我应该购买自第三方？

从 MVP(Minimum Viable Product) 开始

我们要借助产品思维回答这个问题。假如你的网站需要登陆功能——等等，你的网站真的需要登陆吗？

考虑到个人有限的人力和财力，我的建议是在编码前，你需要清晰的认识到网站哪些功能是必须实现 (Must have)， 哪些又是可有可无的 (Nice to have) 的。之所以提前给你打这支预防针，是因为绝大部分产品在寿终正寝之前被人们看到的机会都极其有限，不确定性的投入大概率会造成浪费。不妨看看下面两个例子。

ProductHunt 是一个行业内知名的互联网产品发布平台，如果保守估计每天有十款产品在此发布的话，在过去一年中全世界至少上线了 3650 款新产品——而你回忆一下在过去的 2022 年里，有任何一款新应用让记忆尤深吗？

再回到 site2share 的例子上，根据 google analytic 统计，过去一年内至少 3000 名新用户访问了我的网站，但实际使用 google 邮箱进行 OAuth 登陆的用户只有 47 人。今年恰逢 Google 催促我将 Google Authention SDK 升级，又考虑到后续的维护成本（比如硬件上购买 Azure Redis 每个月就需要花费 15 美元），我选择将登陆功能彻底下线

回到登陆功能上来，如果确认它是完整功能的一部分，在购买基础设施支撑它之前，还应该想想买是不是唯一的方式：

• 如果登陆是为了保存个性化数据，能否采用类似于excalidraw 本地缓存（比如 localStorage ）方案解决？
• 如果需要后端保存个性化数据，那么登陆功能我们能否采用轻量级实现，比如集成 OAuth 而非从零开始搭建账号体系
• 如果确认使用 OAuth ，直接选择 Auth0 是否是更好的选择？

Auth0 的免费版本支持最多 7000 名注册用户无限次登陆。也许你会问 7000 名用户之后该怎么办？我不知道，那是我还没走到过这么远。不过我猜真到那个时候，深思熟虑的用户体系应该被提上议程，资金和人力都不再是问题。不过在此之前，先活下去。

衡量隐藏成本

钱不是问题，问题是没钱，所以才会有这篇文章。但是除了钱以外，大家往往会忽略时间上的付出。长远看创作成本不占代码成本的大头，维护成本才是。

举个例子，假如你现在需要做爬虫，必须要用到代理池，是应该自己搭建还是购买代理池？

市面上已经有很多的代理池开源项目了，比如这个 proxy_pool 。代理池的原理非常简单，本质上它是一个聚合服务，替你去抓取互联网上公开的代理库然后存储在一起。回到这个问题上，我倾向于购买现有的代理服务而非自建，以部署这个开源项目为例，自建会给我带来以下困恼：

• 需要重新捡起 Python 和 Docker ，这是学习成本
• 我的 web 服务是部署在 App Service 上的，如果要将 proxy_pool 部署为独立服务，需要额外购买虚拟机
• 服务的安全、测试、维护、监控成本
• 需要额外的开发工作量对 IP 做再次有效过滤，因为公共 IP 库通常质量不高，无法满足抓取指定网站的需求和 web 服务进行联调

如果你把你的工资按照小时换算，乘以一下未来相当长一段时间投入在上面这些工作的时间，可能直接把这笔钱买一个适用的代理服务更划算。因为代理池目前是一个非常成熟的产业，行业内有大笔的成熟玩家。以最大的 bright data 为例，它不仅可以更细分的提供代理 IP ，还可以替你把代码写了，直接提供抓取服务 API ，并且支持在浏览器内调试：

bright data 可能存在一些准入门槛，但你总可以在行业内找到适合于你的“平替”，出于竞争考虑大家提供的服务都类似，比如对我来说我觉得 Geonode 的代理服务可能更适合我。

我想表达的是，不一定不花钱就等同于免费，别忘了需要把隐形成本计算在内。话说回来手动搭一个还是能学到不少东西的，也可以算是当作学费了吧。但我在这里的立场还是从产品出发，fast 很重要，无论是 move fast 还是 fail fast 

买什么配置的服务

在确定购买云服务之后，接下来的问题是应该购买什么配置的云服务。我自己对云服务有个不正经的分类：托管型（ managed ）和非托管型（ non-managed ）。简单来说非托管型不提供你基本需求以外的额外价值，例如你需要服务器，那它能提供给你的真只有一台（虚拟机）服务器而已，DigitalOcean 的 Droplets 或者是 阿里的 ECS 都属于这种类型，这些产品类型下还会有子类，比如 CPU 优化型、内存优化型。有的在购买时你可以选择预装的系统或者运行时环境，但本质上它们依然是服务器，不关心你将来要用它们做什么。

相反，托管型除了能够满足你程序的基本需求以外，它还提供更多的额外服务，比如 Digital Ocean 的 App Platform 在首页展示的 slogan 便是 "Fully-managed infrastructure"，提供了包括直接从 GitHub 部署、应用监控、日志分析等功能，以我现在正在使用的 Azure App Service 为例，在界面上我可以使用到以下功能：

但问题是，你的应用支撑得起这么多功能吗？没错，我问的是你的应用能否支撑的它？

我所购买的是最低配置套餐 Basic B1, 它提供的内存容量是 1.75G 。但根据 app service 服务提供的监控统计，我的应用常年使用的内存（ memory working set ）只需要 140MB 。想当然硬件基础设施在相当长一段时间内都足以保证功能的正常运行。所以我不需要 Monitoring 里的对于基础设施的报警 alert （运行 alert 也需要额外花费），也不需要在菜单栏上常驻一个升级硬件用的 Scale up 按钮。而关于应用级别的监控，我可以利用第三方的免费服务 UptimeRobot：

再比如以 Deployment slots 为例，它提供的是多环境部署机制：你可以先创建一个 Staging 环境，将即将上线的代码部署其中，在测试无误之后，一键将 Staging 环境程序切换为 Prod 环境。但是作为小本经营的个人开发者，准备隔离的多个环境其实是奢侈的一件事（比如隔离的数据库环境），并且作为冷门应用宕机部署以及直接用线上环境试错也是可以接受的——deployment slots 也不是刚需。

所以关于应该购买何种配置的云服务，我的答案是够用就行，扩容便利。如果 Digital Ocean 上 4 美元一个月内存只有 512MB 的虚拟机能够运行你的应用，那买它就好了。至少在项目初期托管型服务带来的效用没有那么明显，但如果有一天现有的基础设施支撑不住流量了，保证扩容不应该是举步维艰的一件事就好。

免费的怎么选

“免费”的云服务比我们想象中的要多——打引号是因为这个说法并不准确，大部分服务只会在一定限额内免费，只不过个体开发者“薅羊毛”的行为大部分情况下达不到免费的上线额度而已。

我以 阿里云效、Azure DevOps、GitHub Actions 三个免费 DevOps 工具为例，说明我认为应该如何选择的选择免费 CI/CD 工具，优先级从高到低

• 熟悉程度：“快”是本文的主题。如果有任何的工具是你已经在日常工作中熟练使用的，它就是首选
• 选择生态：所有的云服务最好都来自同一家提供商。如果你的应用部署在 Azure 上，那么用 Azur DevOps 是最好的选择。它天然会提供较好的支持，例如会内置机制便于你一键将流水线连接到云服务
• 附加价值：Github Actions 最为纯粹它聚焦于 CI/CD 。但另外两者还同时提供团队协作、项目的管理功能，因为它们倡导的是 DevOps 价值而非仅限于流水线。云效甚至还能和阿里生态进行结合，比如钉钉。在我使用 Azur App Service 的过程中，我发现它默认提供日志收集工具 Application Insights  非常好用，几乎可以满足你对日志工具的一切幻想：支持多种编程语言、同时支持前后端以及分布式追踪、主动采集，还有（部分）免费
• 开发体验：包括和第三方集成的难易程度，对排查问题是否友好等等。提一点：云效的 UI 很棒，还可以提供免费的人工的咨询服务，但是却不支持 IaC （ Infrastructure as code ）。对我来说 IaC 更加重要。
• 核心功能：CI/CD 流水线作为业内标准的，大家已经领悟的很透彻了。这方面无需多虑，差异不大。
• 行业地位：这个参考条件并非针对这三者而言的，在这个领域内差别不会太大。但是其他云服务，比如静态资源托管，我的经验是 Netlify 会比 Azure Static Web Apps 体验更好，提供的服务也更多更专业。例如可能考虑到许多人会使用 Netlify 托管单页面应用，它们还提供表单功能。你可以在你的网页上集成表单提交到它们给出的指定地址上，它们会自动为你收集整理。当然也有免费的第三方服务 FormKeep 可供选择

书籍推荐

如果你真的有兴趣制作自己的应用，有两本书值得推荐：《重来》(Rework)就不说了，我印象中都出版有十年了，basecamp 团队经典著作。它带来的更多是精神支持和抽象的意见。

《 The Indie Maker Handbook 》是我在 Product Hunt 上发现的。它更偏向实战，比如你应该如何发布，在发布，什么时候发布你的产品。作者自己也是一款从 Product Hunt 上发迹产品的创始人。