作为一名忠于内心的工程师，每当我看到一家公司发布有关它们技术栈的文章时，我都会泡一杯咖啡，坐下来耐心阅读，看看有没有新的发现。了解其他公司业务背后隐藏的一些技术十分有趣。就像娱乐八卦一样，只不过这是技术层面的探索。
几个月前，我开始开发另一个 SaaS，该项目经历无数次迭代。幸运的是，尽管项目仍处于早期阶段，但是很多网站已经对其进行了集成。
作为一个自负盈亏的独立创业者，我相信正是由于专注于自动化，才让我能为来自 80 多个国家和地区的客户提供可靠服务，并且每周持续提供新功能。当我想要了解服务的运行情况或者其他方面的信息时，我会尝试利用我熟悉的工具。当然，我也明白，在一些特殊情况下这些工具并不会帮到我。
现在，我简要地介绍下平时使用的一些工具。
非常重要的一点是，虽然工具列表看起来很长，并且有一些是非常规且不常用的选项，但实际上我在基础架构上花费的时间很少，如果有的话，每个月平均下来也就是几个小时。还有一点就是个人推荐就像是开处方一样，我认为对我非常有用的一些工具，可能并不适合你。一定要考虑自己的实际情况，并利用好当下你熟悉的工具。
编程语言
多年来，我学习和使用过好几种编程语言，但是对于独立项目，我特别挑选出两种编程语言。这两种编程语言可以在生产力以及可靠性上取得很好的平衡。
框架
理论上，我会在这里介绍很多这方面的内容，但是相关论坛上有不少介绍，我也是站在巨人的肩膀上学到很多知识。因此我只想介绍几个非常不错的框架：
数据库
我最初将所有数据都存储在 SQLite 数据库中，对数据进行备份意味着要将副本数据复制到 S3 之类的对象存储中。之前对于测试过的一些小型站点来说，没有什么问题。但是，随着项目的功能及页面越来越多，我需要更多专门的数据库来支持这些功能：
部署工具
与这篇文章描述的一样，我不会将我的基础设施视为宝贝一样对待。服务器和集群本来就是一个工具而已。所以如果某一台服务器出现问题，用另外一台正常的服务器替换一下就好了。这意味着所有的操作在 git 仓库中被描述为代码逻辑，并且我不会通过 SSH 登陆服务器进行一些操作。你可以将这个描述视为一个模板，可以通过一个命令将整个基础架构克隆到任何的 AWS 服务中。
这在灾难恢复时也会对我有所帮助。我只需要运行一些命令，几分钟后，我的应用服务就可以重建并能正常运行了。当我将应用从 DigitalOcean 迁移到 Linode，以及最近往 AWS 迁移时非常有用。所有的操作都通过代码描述和执行。因此，即使在几年后，我也很容易的跟踪项目的相关部署和运行情况。现在所有的公司都拥有 AWS IAM 策略或者 VPC 子网，这些都是通过一些 UI 界面点击操作完成的，现在所有人都离不开这一功能，因为确实给用户带来了很多便利。
基础设施服务
我从最开始使用月费 5 美元的 DigitalOcean 单实例服务器开始，逐步转向使用 Kubernetes 来管理服务，因为我正在彻底改变 Kubernetes 提供的一些开箱即用的功能（比如：服务发现、TLS 认证、负载均衡、日志滚动管理、滚动发布、容量管理等）。
但是，即使在较大的服务器实例上，使用 Kubernetes 管理的 DigitalOcean 也同样存在可靠性问题。集群 API 服务经常会随机地停止工作并且无法恢复，这会破坏包括负载均衡在内的许多集群服务，也就意味着服务停机无法对外提供正常服务。每当发生这种情况时，我会重新创建一个新的集群，尽管使用 Terraform 可以很轻松的实现，但是这并不会增加大家对其托管服务可靠性的信心。我怀疑是他们的资源不是特别充足导致的，考虑到他们的服务收费较低，因此这是可以理解的。
不幸的是，几周后，我就无法解决上面提到的问题了。这就是为什么我决定迁移到的原因，在接下来的一个半月的时间里，系统再也没有出现过任何问题。
但是，AWS 向我抛来了更加诱人的优惠，所以我最近又做了一次迁移。AWS 还支持使用托管服务比如 RDS 来减轻 PostgreSQL 的压力，这对我来讲是个很大的优势。我的迁移工作没有那么复杂，因为我的所有基础架构都是通过 Terraform 和 Kubernetes 配置清单进行描述的。系统迁移可能会花费或长或短的时间，所以一定要有耐心。这一方面的话题可以在其他文章中找到。
Kubernetes 组件
以下组件可以自动完成大部分开发运维工作。我也使用其他的一些组件，但是我最想推荐给大家的是下面几个：
命令行工具
我使用的命令行工具有很多，但经常使用且值得推荐的就下面这几个：
监控工具
邮件工具
开发工具
其他工具
原文链接
