这是用户在 2024-10-11 11:47 为 https://www.hadijaveed.me/2024/09/08/does-your-startup-really-need-complex-cloud-infrastructure/ 保存的双语快照页面，由 沉浸式翻译 提供双语支持。了解如何保存？
Skip to content
5 min read
 
5 分钟阅读

Does Your Startup Really Need Complex Cloud Infrastructure?
您的初创公司真的需要复杂的云基础设施吗？

I recently listened to Pieter Levels on the Lex Friedman Podcast, and it was eye-opening. Pieter has built numerous successful micro-SaaS businesses by running his applications on single server, avoiding cloud infrastructure complexity, and focusing on what truly matters: product-market fit.
我最近在Pieter Levels的Lex Friedman Podcast上听到了一个启发性的内容。Pieter 通过在单台服务器上运行他的应用程序，避免云基础设施的复杂性，专注于真正重要的事情：产品市场契合，建立了众多成功的微型 SaaS 企业。

While his approach might not suit teams and generally every startup, but it raises a valid point: we've often made deployment and infrastructure management complex for complexity's sake.
虽然他的做法可能不适合所有团队和初创公司，但他提出了一个有效的问题：我们常常为了复杂而复杂而使部署和基础设施管理变得复杂。

For small dev teams moving past the MVP stage, managing deployments and databases can be challenging. But here's the truth: not every project needs Kubernetes, complex distributed systems, or auto-scaling from day one. Simple infrastructure can often suffice, allowing teams to focus on building a great product and finding market fit.
对于小型开发团队来说，跨越 MVP 阶段，管理部署和数据库可能具有挑战性。但事实是：并非每个项目从第一天起都需要 Kubernetes、复杂的分布式系统或自动扩展。简单的基础设施往往足够，使团队能够专注于构建优秀产品和寻找市场契合点。

Recent Observations
最近观察

Let me share two recent examples of projects I've worked on that highlight this issue:
让我分享两个我最近参与的项目例子，这些项目突显了这个问题：

Project 1: Lambda Overload
项目 1：Lambda 超载

  • 20-30 Lambda functions for different services
    20-30 个不同服务的 Lambda 函数
  • SQS and various background jobs backed by Lambda
    SQS 和各种由 Lambda 支持的后台作业
  • Logs scattered across CloudWatch
    日志分散在 CloudWatch 上

Result? Painful debugging, difficult changes, and complex deployments, even in a monorepo. Could this have been simplified to a single NodeJS container or Python Flask/FastAPI app with Redis for background tasks? Absolutely.
结果？痛苦的调试、困难的更改以及复杂的部署，即使是在单一代码库中。这是否可以简化为一个单一的 NodeJS 容器或使用 Redis 进行后台任务的 Python Flask/FastAPI 应用程序？绝对可以。

Project 2: Microservices Mayhem
项目 2：微服务混乱

  • 7 small microservices on Kubernetes (EKS)
    在 Kubernetes（EKS）上运行的 7 个小型微服务
  • Separate services for CRUD and business logic
    将 CRUD 和业务逻辑分开服务

While Kubernetes is powerful, the team spent more time on infrastructure than building features. Was this level of separation necessary for their scale?
虽然 Kubernetes 功能强大，但团队花费更多时间在基础设施上，而不是构建特性。这种级别的分离对于他们的规模来说是必要的吗？

Note 注意

Enterprise-scale companies face different challenges with compliance and large workforces. Startups don't need to mimic this complexity. Early-stage companies should prioritize product-market fit and rapid iteration.
企业规模的公司面临着合规和大规模劳动力的不同挑战。初创企业不需要模仿这种复杂性。早期阶段的公司应优先考虑产品市场契合和快速迭代。

The Power of Single Server Setups
单服务器设置的强大力量

Modern servers pack a punch. You can get powerful VMs from Hetzner or latitude.sh at budget-friendly prices. Even GCP VMs and EC2 instances are reasonably priced.
现代服务器性能强劲。您可以以预算友好的价格从 Hetzner 或 latitude.sh 获取强大的虚拟机。甚至 GCP VMs 和 EC2 实例的价格也相当合理。

These machines offer robust compute power - think 40GB RAM and multiple cores - often outperforming distributed services or multiple Lambdas or ECS tasks. Plus, everything's centralized and easier to manage.
这些机器提供强大的计算能力——考虑到 40GB 内存和多个核心——通常在性能上超过分布式服务或多个 Lambda 或 ECS 任务。而且，所有内容都是集中管理，更加易于管理。

Worried about scaling to millions of QPS? Cross that bridge when you come to it. By then, you'll likely have an infrastructure team to handle it.
担心扩展到数百万的每秒查询（QPS）？到时再考虑这个问题。届时，您可能已经有一个基础设施团队来处理它。

For a reliable single VM setup, you need:
对于一个可靠的单虚拟机设置，您需要：

  1. A robust machine (EC2, GCP VM, Hetzner, etc.)
    强大的机器（EC2，GCP 虚拟机，Hetzner 等）
  2. Secure access (HTTPS for web, IP-restricted SSH or SSM for deployment)
    安全访问（网页的 HTTPS，部署用的 IP 限制 SSH 或 SSM）
  3. CI/CD for zero-downtime deployments
    CI/CD 用于零停机时间部署
  4. DNS configuration DNS 配置
  5. Regular database backups 定期数据库备份
  6. A standby VM for redundancy
    冗余的备用虚拟机

Yes, you'll need a solid disaster recovery strategy and tested mean recovery time, but it's achievable with a backup VM.
是的，您需要一个可靠的灾难恢复策略和经过测试的平均恢复时间，但通过备份虚拟机这是可以实现的。

Docker Compose

Docker Compose is fantastic for local development, managing multiple services with a single command. Surprisingly, it's underutilized in production environments, and Docker Swarm was deprecated..
Docker Compose 对于本地开发非常出色，可以通过单个命令管理多个服务。令人惊讶的是，它在生产环境中使用不足，而 Docker Swarm 已被弃用。

While Docker Compose can cause downtime during updates, there are guides for production deployment. It's a balance between simplicity and production readiness.
虽然 Docker Compose 在更新时可能会导致停机，但有生产部署指南。这是一种在简单性和生产准备之间的平衡。

Docker Compose Anywhere: A Weekend Project
在任何地方使用 Docker Compose：一个周末项目

To simplify this setup further, I created Docker Compose Anywhere over the weekend. This opinionated template offers:
为了进一步简化这个设置，我在周末创建了 Docker Compose Anywhere。这个有观点的模板提供：

  • One-click Linux server setup via GitHub Actions
    一键式 Linux 服务器设置通过 GitHub Actions
  • Zero-downtime continuous deployment using GitHub Container Registry and Docker Rollout
    使用 GitHub 容器注册表和 Docker Rollout 实现零停机时间的持续部署
  • Environment variable and secret management (considering age or sops for improved security)
    环境变量和密钥管理（考虑使用 age 或 sops 提高安全性）
  • Automated Postgres backups via GitHub Actions
    通过 GitHub Actions 实现自动化 Postgres 备份
  • Multi-app support on a single VM
    单个虚拟机上的多应用程序支持
  • Automated SSL with Traefik and Let's Encrypt
    自动化 SSL 与Traefik和Let's Encrypt
  • Deploy Next.js apps, GO, Python, Node.js, and more
    部署 Next.js 应用程序、GO、Python、Node.js 等更多内容

Few Considerations
少数考虑

For security, remember to:
为了安全，请记住：

  • Set strict firewall rules (open only necessary ports)
    设置严格的防火墙规则（仅开放必要的端口）
  • Secure SSH keys (prefer SSM on AWS or CLI on GCP)
    安全 SSH 密钥（优先使用 AWS 上的 SSM 或 GCP 上的 CLI）
  • Use a bastion host for enhanced security
    使用堡垒主机增强安全性
  • Protect secrets and consider using a WAF or Cloudflare
    保护秘密，并考虑使用 WAF 或 Cloudflare

Don't forget about data protection:
不要忘记数据保护：

  • Send encrypted database backups to secure cloud storage (e.g., S3 or equivalent)
    将加密的数据库备份发送到安全的云存储（例如，S3 或同类服务）
  • Regularly snapshot your disks for added redundancy
    定期快照您的磁盘以增加冗余性
  • Implement a retention policy for backups and snapshots
    实施备份和快照的保留策略

As engineers, our primary goal should be advocating for simplicity in our setup and focusing on the core product.
作为工程师，我们的主要目标应该是倡导我们设置的简单性，并专注于核心产品。

It's all too easy to get distracted by shiny new tools or complex setups that mimic what Google engineers or large enterprises are doing. But here's the truth: whether you're in a startup or not, what truly matters is talking to your users and finding product-market fit.
太容易被闪亮的新工具或模仿谷歌工程师或大型企业的复杂设置所分心。但事实是，无论你是在初创企业还是其他，真正重要的是与你的用户沟通并找到产品与市场的契合。