这文章至少值一千元，因为这是我保守估计花出去的冤枉钱（请自行脑补一个苦笑的 emoji）
文章中会穿插选择云服务的一些建议，当然也会提供一些“薅羊毛”的技巧。不过在此之前我们要想清楚一件更重要的事情：我为了什么购买云服务
这个问题不仅决定了你接下来的购买策略，还是你编码开始的前提。
以技术为出发点想达到的目的是：我想把代码写对（先学会），并且把代码写好（然后精通），代码是一切工作的出发点， 编码过程中的困难越多越好，能够遇到的业务场景越复杂越好，对行业内的最佳实践越熟悉越好，收获和实际投入的代码量成正比。
如果从产品侧看，好代码不等于好产品，验证想法的可行性才是当务之急。在有用户买单前，人天、机器、代码都是沉默成本，对于个人开发者而言这些都是自掏腰包承担的损失，所以从做产品出发“快”其实是最高优先级。我相信你或多或少体验过这类技术与产品的矛盾：高质量的代码离不开时间投入，但时间又是一款产品“跑马圈地”最大的敌人——这样的选择一点也不难，公司会毫不犹豫的牺牲前者，如果你在互联网创业公司工作过一定更加深有体会。产品与技术并非二元对立，你依然可以在开发产品的过程中可以刻意熟练某项技术，只不过同时身兼产品和代码作者的你需要小心计算成本和回报。
正如标题所示，本文所处视角是个人（独立）开发者。对于这类群体而言，虽然他们自带编码天赋点，但是把一款产品运营好远比写出完美代码重要，也就是说在本文里“云”所服务的首要对象是产品。
一旦接受了产品优先的前提，你就要开始尝试“克服”各种代码洁癖，学会接受开发产品中的各种不完美。假如回到两年前给我机会重写 site2share，编码实现上我会做大量裁剪，例如：
如果你还是不能理解我为什么推崇各类显而易见的反模式，读下去就知道了
正确的提问题应该是递进式的：
我们要借助产品思维回答这个问题。假如你的网站需要登陆功能——等等，你的网站真的需要登陆吗？
考虑到个人有限的人力和财力，我的建议是在编码前，你需要清晰的认识到网站哪些功能是必须实现 (Must have)， 哪些又是可有可无的 (Nice to have) 的。之所以提前给你打这支预防针，是因为绝大部分产品在寿终正寝之前被人们看到的机会都极其有限，不确定性的投入大概率会造成浪费。不妨看看下面两个例子。
ProductHunt 是一个行业内知名的互联网产品发布平台，如果保守估计每天有十款产品在此发布的话，在过去一年中全世界至少上线了3650款新产品——而你回忆一下在过去的2022年里，有任何一款新应用让记忆尤深吗？
再回到 site2share 的例子上，根据 google analytic 统计，过去一年内至少 3000 名新用户访问了我的网站，但实际使用 google 邮箱进行 OAuth 登陆的用户只有47人。今年恰逢 Google 催促我将 Google Authention SDK 升级，又考虑到后续的维护成本（比如硬件上购买 Azure Redis 每个月就需要花费15美元），我选择将登陆功能彻底下线
回到登陆功能上来，如果确认它是完整功能的一部分，在购买基础设施支撑它之前，还应该想想买是不是唯一的方式：
Auth0 的免费版本支持最多7000名注册用户无限次登陆。也许你会问7000名用户之后该怎么办？我不知道，那是我还没走到过这么远。不过我猜真到那个时候，深思熟虑的用户体系应该被提上议程，资金和人力都不再是问题。不过在此之前，先活下去。
钱不是问题，问题是没钱，所以才会有这篇文章。但是除了钱以外，大家往往会忽略时间上的付出。长远看创作成本不占代码成本的大头，维护成本才是。
举个例子，假如你现在需要做爬虫，必须要用到代理池，是应该自己搭建还是购买代理池？
市面上已经有很多的代理池开源项目了，比如这个 proxy_pool 。代理池的原理非常简单，本质上它是一个聚合服务，替你去抓取互联网上公开的代理库然后存储在一起。回到这个问题上，我倾向于购买现有的代理服务而非自建，以部署这个开源项目为例，自建会给我带来以下困恼：
如果你把你的工资按照小时换算，乘以一下未来相当长一段时间投入在上面这些工作的时间，可能直接把这笔钱买一个适用的代理服务更划算。因为代理池目前是一个非常成熟的产业，行业内有大笔的成熟玩家。以最大的 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 工具，优先级从高到低
如果你真的有兴趣制作自己的应用，有两本书值得推荐：《重来》(Rework)就不说了，我印象中都出版有十年了，basecamp 团队经典著作。它带来的更多是精神支持和抽象的意见。
《The Indie Maker Handbook》是我在 Product Hunt 上发现的。它更偏向实战，比如你应该如何发布，在发布，什么时候发布你的产品。作者自己也是一款从 Product Hunt 上发迹产品的创始人。
你可能也会喜欢：