Startup của bạn có thực sự cần hạ tầng Cloud phức tạp không?

 (hadijaveed.me)
4 điểm bởi GN⁺ 2024-09-15 | 1 bình luận | Chia sẻ qua WhatsApp

Có thực sự cần hạ tầng đám mây phức tạp không?

  • Khi nghe Pieter Levels chia sẻ trên podcast của Lex Friedman, tôi đã nhận ra nhiều điều
  • Pieter vận hành ứng dụng trên một máy chủ duy nhất và xây dựng được một doanh nghiệp micro SaaS thành công
  • Điều quan trọng là tránh sự phức tạp của hạ tầng đám mây và tập trung vào độ phù hợp sản phẩm-thị trường
  • Điều này có thể không phù hợp với mọi startup, nhưng cần tránh tạo ra sự phức tạp chỉ vì sự phức tạp

Những quan sát gần đây

Dự án 1: Lambda quá tải

  • Vận hành nhiều dịch vụ với 20-30 hàm Lambda
  • Công việc nền sử dụng SQS và Lambda
  • Log bị phân tán trong CloudWatch

Kết quả: khó debug, khó thay đổi và triển khai phức tạp. Hoàn toàn có thể đơn giản hóa bằng một container NodeJS duy nhất hoặc một ứng dụng Python Flask/FastAPI cùng Redis

Dự án 2: Hỗn loạn microservice

  • Vận hành 7 microservice nhỏ trên Kubernetes (EKS)
  • Tách riêng các service cho CRUD và business logic

Kết quả: tốn nhiều thời gian hơn cho việc quản lý hạ tầng. Khó tránh khỏi câu hỏi liệu mức độ tách biệt này có thực sự cần thiết hay không

Sức mạnh của mô hình một máy chủ

  • Máy chủ hiện đại rất mạnh. Hetzner, latitude.sh cung cấp VM mạnh với giá rẻ
  • VM trên GCP và instance EC2 cũng có mức giá hợp lý
  • Cung cấp năng lực tính toán mạnh với 40GB RAM và nhiều lõi CPU
  • Mọi thứ được tập trung, nên dễ quản lý
  • Bài toán mở rộng lên hàng triệu QPS có thể giải quyết sau

Những gì cần có cho một thiết lập VM đơn:

  1. Một máy mạnh (EC2, GCP VM, Hetzner, v.v.)
  2. Truy cập an toàn (HTTPS, SSH giới hạn IP hoặc SSM)
  3. CI/CD để triển khai không downtime
  4. Cấu hình DNS
  5. Sao lưu cơ sở dữ liệu định kỳ
  6. Bảo đảm dự phòng bằng VM chờ

Docker Compose

  • Docker Compose rất tuyệt cho phát triển cục bộ
  • Có thể quản lý nhiều service bằng một lệnh duy nhất
  • Ít được dùng hơn trong môi trường production
  • Có thể phát sinh downtime trong quá trình cập nhật

Docker Compose Anywhere: dự án cuối tuần

  • Docker Compose Anywhere được phát triển trong một cuối tuần
  • Cung cấp các tính năng sau:
    • Thiết lập máy chủ Linux bằng một cú nhấp qua GitHub Actions
    • Triển khai không downtime bằng GitHub Container Registry và Docker Rollout
    • Quản lý biến môi trường và secret (đang cân nhắc dùng age hoặc sops)
    • Sao lưu Postgres tự động qua GitHub Actions
    • Hỗ trợ nhiều ứng dụng trên một VM duy nhất
    • SSL tự động với Traefik và Let's Encrypt

Một vài điểm cần cân nhắc

Về bảo mật:

  • Thiết lập quy tắc firewall nghiêm ngặt (chỉ mở các cổng cần thiết)
  • Bảo mật SSH key (trên AWS ưu tiên SSM, trên GCP ưu tiên CLI)
  • Dùng bastion host để tăng cường bảo mật
  • Cân nhắc bảo vệ secret và sử dụng WAF hoặc Cloudflare

Bảo vệ dữ liệu:

  • Gửi bản sao lưu cơ sở dữ liệu đã mã hóa lên bộ nhớ đám mây an toàn (ví dụ: S3)
  • Tạo disk snapshot định kỳ để tăng thêm mức dự phòng
  • Triển khai chính sách lưu giữ cho backup và snapshot

Tóm tắt của GN⁺

  • Bài viết nhấn mạnh rằng startup nên tránh hạ tầng đám mây phức tạp và tập trung vào độ phù hợp sản phẩm-thị trường với một thiết lập đơn giản
  • Giới thiệu ưu điểm của mô hình một máy chủ và cách triển khai đơn giản bằng Docker Compose
  • Điều quan trọng là không lãng phí thời gian vào quản lý hạ tầng phức tạp mà tập trung vào phát triển sản phẩm cốt lõi
  • Các dự án có chức năng tương tự gồm Heroku, DigitalOcean, v.v.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-15
Bình luận Hacker News

  • Trong nhiều dự án, các đội ngũ muốn dùng công nghệ mới nhất thường tạo ra sản phẩm đầu ra chất lượng thấp

    • Có những đội ngũ còn non kinh nghiệm, không hiểu Kubernetes nhưng vẫn muốn dùng
    • Họ xây dựng quy trình tự động bằng Puppet để chạy dịch vụ Docker trên nhiều VM khác nhau hoặc vận hành backend Python
    • Các startup đang chi rất nhiều tiền trên cloud nhưng vẫn tạo ra kết quả tệ hơn cả những người tiên phong DevOps năm 2017
    • Bài blog liên quan: The Emperor's New clouds

  • Ở startup nhỏ, người ta vận hành nginx, webapp, postgres, redis... trên một VM duy nhất

    • Lập trình viên có thể làm việc ở môi trường local với cùng cấu hình nên việc debug dễ hơn
    • Có thể scale theo chiều dọc nên phù hợp ở giai đoạn đầu

  • Bắt đầu một SaaS trên một máy chủ duy nhất rồi mở rộng ra nhiều máy chủ

    • Vẫn vận hành cơ sở dữ liệu phân tán mà không cần dùng Kubernetes
    • Dùng máy chủ bare metal mạnh hơn VM của nhà cung cấp cloud
    • Quản lý máy chủ bằng ansible và terraform như công cụ tự động hóa

  • Các tính năng cốt lõi của Kubernetes như triển khai, dịch vụ pod, triển khai blue-green rất hữu ích

    • Nhưng trong môi trường cloud-native, việc dùng nhiều hệ thống mã nguồn mở có thể khiến mọi thứ trở nên phức tạp

  • Nhiều người xây dựng hạ tầng phức tạp để học Kubernetes

    • Điều này có thể hữu ích khi mở rộng cho các khách hàng quy mô lớn
    • Nhưng có thể ít hữu ích hơn với nhà sáng lập hoặc CTO

  • Ngay cả sách về microservices cũng khuyến nghị: "hãy xây dựng monolith trước"

    • Ban đầu dùng monolith sẽ dễ debug hơn
    • Dùng Docker để đơn giản hóa giai đoạn đầu
    • Chuyển sang Kubernetes theo nhu cầu của doanh nghiệp

  • Không nên chọn framework phức tạp ngay từ đầu

    • Việc dùng công cụ tự xây không phải lúc nào cũng hiệu quả hơn
    • Dùng công cụ tiêu chuẩn có thể hiệu quả hơn về lâu dài

  • Trên cloud chỉ dùng VM, block storage và blob storage, DNS, IdP và nhà đăng ký tên miền

    • Các dịch vụ như FaaS thì phức tạp và khó debug
    • Một VM duy nhất và codebase monolithic là lý tưởng

  • Có người đã vận hành dự án suốt 6 năm trên một VPS giá $10/tháng

    • Công nghệ VPS đã tiến bộ rất nhiều nên độ tin cậy cao
    • Hạ tầng cloud được dùng cho các tính năng cộng tác và quản lý vận hành

  • Vẫn ưu tiên các giải pháp dựa trên cloud nhưng dùng có chọn lọc

    • Dùng Google Cloud Platform (GCP) để giảm chi phí
    • Không dùng Kubernetes
    • Dùng Docker để đơn giản hóa việc triển khai
    • Các dịch vụ managed của GCP giúp tiết kiệm thời gian