… 但当我需要在雇佣1名额外的开发人员和支付同样昂贵的托管费用之间做出选择时，我会选择在团队中多雇佣一名开发人员。每次都是这样。如果你处理得当，托管费用可能比单个开发人员的月成本低一个数量级。参考一下，我们每月为生产环境支付大约400美元。这包括Google云服务和一个Elastic Cloud搜索集群。当然，其他公司出于各种合理的原因可能会做出不同的选择。但这些选择对我来说是可行的，我对这些权衡感到满意。
源讨论去云化和去K8s化 – 把我们的应用带回本地原帖 409 条评论 · 导入时统计不管"去云化"对于这家特定公司来说有什么优缺点，在我看来，他们的运维团队只是非常无聊，或者对任何解决方案都永远不满意。 他们说他们已经尝试在以下所有地方部署他们的应用： * 他们自己的数据中心 * ECS * GKE * EKS * 现在又回到他们自己的数据中心 即使他们新的"去云化"部署，似乎他们为部署看起来像各种通用的 Ruby CRUD 应用程序（我可能错了，但我在帖子中没有看到任何不同之处）创造了巨大的复杂性。 他们尝试过各种工具和集成，名字都很奇怪；Capistrano、Chef、mrsk、Filebeat、traefik... 从复杂性来看，这与一个完整的 K8s 部署（包括所有附加功能，如日志记录、监控、网络等）相当。 谷歌显示，这家公司37signals有34名员工…
完整原文把你的经验，加入这段讨论。
我完全同意这一点。大多数中等或低流量的产品都可以这样处理。自动化成本往往不值得投入资金。 将微服务到处部署是一种危险的趋势。要达到与单体架构相同质量水平，需要无限的额外工作和专业人员。你的产品必须非常成功才能负担得起这些费用！ 我的经验法则：只要你的业务能负担得起，就使用单体架构和PaaS。
完整原文哪里，哦上帝，还有像你这样更理性思考的人吗！这很实际且直接。在你描述的策略中，几乎没有技术性无意义工作的空间。大多数地方，以及我遇到的许多开发者都无法想象如何在没有一堆奇怪名称的工具的情况下完成他们的工作，他们只了解其中一种使用方式。
完整原文如果我使用Terraform，通过AWS Serverless来处理这个你所提到的工作负载，同时保持在免费层级，而不是使用虚拟机和负载均衡器会怎样呢？ 我只是不明白为什么人们更喜欢基于虚拟机的方法而不是无服务器架构。
完整原文我完全同意。我认为系统设计面试部分要为此负责，因为它们挑选出那些认为设计系统唯一方法就是系统设计面试准备书籍和课程所宣扬的“cargo cult”方法的人，即： - 将一切分解为微服务 - 为负载均衡、缓存、无状态应用服务器、数据库服务器等设置独立的水平可扩展层 - 至少使用两种不同类型的数据库，因为将键值数据存储在关系型数据库中是禁忌 - 在每一层之间插入Kafka队列层和死信队列，因为每次将一个东西分成两部分，你就可能遇到一部分宕机而另一部分仍然运行的情况 - 在10个不同的数据中心复制这些，因为如果纽约的用户需要与达拉斯的服务器通信，我可不会让这种情况发生 而所有这些只是为了一个最多有10k次交易的服务…
完整原文这实际上是一篇对我很有意思的帖子。我目前在一家与初创公司完全相反的公司工作，预算非常有限。我们是一家中型公司，有100到150名技术人员。作为一个独特的问题，我们处理大量相当敏感的数据——财务数据、人力资源数据、预测和规划数据。我们的客户是大公司，他们对这些数据非常谨慎。因此，我们被迫自托管我们大量基础设施，因为这从一个愚蠢的决定变成了该领域的一个独特卖点。 从那里，大约有7到12名技术人员在我们团队、SaaS运维、我们的硬件运维团队或CI/镜像/部署/构建服务器等一般支持团队工作。大约5-10%的人力资源投入其中。 有趣的是：你的观点正是我们基础设施上运行的团队的梦想愿景。 就像——1和2和…
完整原文我唯一不同意的是Terraform。对于这种特定情况，它非常出色，因为它具有自我文档化功能。当你两年后需要更新这些SPF记录时，将其作为Terraform文件提交会比查阅（可能已过时的）markdown文件要好得多。它几乎不需要维护，而且非常简单。此外，它能够将不同的服务结合起来（比如从同一个地方配置Fastly和Route53）也很方便。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。