สตาร์ทอัพของคุณจำเป็นต้องมี Cloud Infrastructure ที่ซับซ้อนหรือไม่?

 (hadijaveed.me)
4 คะแนน โดย GN⁺ 2024-09-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

จำเป็นต้องมีคลาวด์อินฟราสตรักเจอร์ที่ซับซ้อนจริงหรือ?

  • ได้ข้อคิดมากมายจากการฟัง Pieter Levels พูดในพอดแคสต์ Lex Friedman
  • Pieter รันแอปพลิเคชันบนเซิร์ฟเวอร์เครื่องเดียวและสร้างธุรกิจ micro SaaS ที่ประสบความสำเร็จ
  • สิ่งสำคัญคือการหลีกเลี่ยงความซับซ้อนของคลาวด์อินฟราสตรักเจอร์และโฟกัสที่ product-market fit
  • แม้อาจไม่เหมาะกับทุกสตาร์ทอัพ แต่ควรหลีกเลี่ยงความซับซ้อนที่มีไว้เพียงเพราะความซับซ้อน

สิ่งที่สังเกตเห็นล่าสุด

โปรเจ็กต์ 1: Lambda ใช้งานเกินพอดี

  • ใช้ Lambda 20-30 ฟังก์ชันเพื่อรันบริการหลากหลายอย่าง
  • ใช้ SQS และ Lambda สำหรับงานเบื้องหลัง
  • ล็อกกระจายอยู่ใน CloudWatch

ผลลัพธ์: ดีบักยาก แก้ไขเปลี่ยนแปลงลำบาก และการดีพลอยซับซ้อน ทั้งที่สามารถทำให้ง่ายลงได้ด้วย NodeJS container เดียว หรือแอป Python Flask/FastAPI ร่วมกับ Redis

โปรเจ็กต์ 2: ความวุ่นวายของ microservices

  • รัน microservices ขนาดเล็ก 7 ตัวบน Kubernetes (EKS)
  • แยกบริการสำหรับ CRUD และ business logic ออกจากกัน

ผลลัพธ์: ใช้เวลากับการจัดการอินฟราสตรักเจอร์มากกว่าเดิม จึงน่าสงสัยว่าการแยกระดับนี้จำเป็นจริงหรือไม่

พลังของการตั้งค่าแบบเซิร์ฟเวอร์เดี่ยว

  • เซิร์ฟเวอร์สมัยใหม่มีประสิทธิภาพสูง Hetzner และ latitude.sh มี VM ทรงพลังในราคาย่อมเยา
  • GCP VM และ EC2 instances ก็มีราคาสมเหตุสมผล
  • ให้พลังประมวลผลสูงด้วย RAM 40GB และหลายคอร์
  • ทุกอย่างรวมศูนย์ ทำให้จัดการได้ง่าย
  • ปัญหาการสเกลไปถึงระดับหลายล้าน QPS สามารถค่อยไปแก้ภายหลังได้

สิ่งที่ต้องมีสำหรับการตั้งค่าแบบ VM เดียว:

  1. เครื่องที่แรงพอ (EC2, GCP VM, Hetzner เป็นต้น)
  2. การเข้าถึงที่ปลอดภัย (HTTPS, SSH จำกัด IP หรือ SSM)
  3. CI/CD สำหรับการดีพลอยแบบไม่มี downtime
  4. การตั้งค่า DNS
  5. การสำรองฐานข้อมูลอย่างสม่ำเสมอ
  6. มี VM สำรองเพื่อรองรับความซ้ำซ้อน

Docker Compose

  • Docker Compose ยอดเยี่ยมสำหรับการพัฒนาแบบโลคัล
  • จัดการหลายบริการได้ด้วยคำสั่งเดียว
  • ถูกใช้น้อยกว่าในสภาพแวดล้อม production
  • อาจเกิด downtime ระหว่างการอัปเดต

Docker Compose Anywhere: โปรเจ็กต์สุดสัปดาห์

  • พัฒนา Docker Compose Anywhere ภายในช่วงสุดสัปดาห์
  • มีความสามารถดังต่อไปนี้:
    • ตั้งค่าเซิร์ฟเวอร์ Linux แบบ one-click ผ่าน GitHub Actions
    • ดีพลอยแบบไม่มี downtime ด้วย GitHub Container Registry และ Docker Rollout
    • จัดการ environment variables และ secrets (กำลังพิจารณาใช้ age หรือ sops)
    • สำรองข้อมูล Postgres แบบอัตโนมัติผ่าน GitHub Actions
    • รองรับหลายแอปบน VM เดียว
    • SSL อัตโนมัติผ่าน Traefik และ Let's Encrypt

ข้อควรพิจารณาบางประการ

เพื่อความปลอดภัย:

  • ตั้งกฎไฟร์วอลล์อย่างเข้มงวด (เปิดเฉพาะพอร์ตที่จำเป็น)
  • ดูแลความปลอดภัยของ SSH keys (บน AWS นิยมใช้ SSM, บน GCP นิยมใช้ CLI)
  • ใช้ bastion host เพื่อเสริมความปลอดภัย
  • พิจารณาการปกป้อง secrets และใช้ WAF หรือ Cloudflare

การปกป้องข้อมูล:

  • ส่งฐานข้อมูลสำรองที่เข้ารหัสแล้วไปเก็บบนคลาวด์สตอเรจที่ปลอดภัย (เช่น S3)
  • สร้าง disk snapshots เป็นประจำเพื่อเพิ่มความซ้ำซ้อนอีกชั้น
  • ใช้นโยบายการเก็บรักษาสำหรับแบ็กอัปและสแนปช็อต

สรุปโดย GN⁺

  • บทความนี้เน้นว่าสตาร์ทอัพควรหลีกเลี่ยงคลาวด์อินฟราสตรักเจอร์ที่ซับซ้อน และใช้การตั้งค่าที่เรียบง่ายเพื่อโฟกัสกับ product-market fit
  • อธิบายข้อดีของการตั้งค่าแบบเซิร์ฟเวอร์เดี่ยว และวิธีดีพลอยอย่างเรียบง่ายด้วย Docker Compose
  • สิ่งสำคัญคืออย่าเสียเวลากับการจัดการอินฟราสตรักเจอร์ที่ซับซ้อน และให้โฟกัสกับการพัฒนาผลิตภัณฑ์หลัก
  • โปรเจ็กต์ที่มีความสามารถคล้ายกัน ได้แก่ Heroku และ DigitalOcean

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-15
ความคิดเห็นจาก Hacker News

  • ในหลายโปรเจ็กต์ มักเห็นทีมที่พยายามใช้เทคโนโลยีใหม่ล่าสุดแต่กลับสร้างผลงานคุณภาพต่ำ

    • มีทีมที่ยังไม่พร้อมและไม่เข้าใจ Kubernetes แต่ก็พยายามจะใช้งานมัน
    • สร้างกระบวนการอัตโนมัติด้วย Puppet เพื่อรันบริการ Docker หรือแบ็กเอนด์ Python บน VM หลายเครื่อง
    • สตาร์ทอัพจำนวนมากใช้จ่ายเงินบนคลาวด์มหาศาล แต่กลับสร้างผลงานที่แย่กว่าผู้บุกเบิก DevOps ในปี 2017
    • บทความบล็อกที่เกี่ยวข้อง: The Emperor's New clouds

  • ในสตาร์ทอัพขนาดเล็ก ใช้ VM เครื่องเดียวรัน nginx, webapp, postgres, redis เป็นต้น

    • นักพัฒนาสามารถทำงานบนสภาพแวดล้อมโลคัลที่มีการตั้งค่าเดียวกันได้ จึงดีบักได้ง่าย
    • สามารถขยายแบบแนวตั้งได้ จึงเหมาะกับช่วงเริ่มต้น

  • เริ่ม SaaS จากเซิร์ฟเวอร์เครื่องเดียวแล้วค่อยขยายเป็นหลายเครื่อง

    • รันฐานข้อมูลแบบกระจายได้โดยไม่ต้องใช้ Kubernetes
    • ใช้เซิร์ฟเวอร์ bare metal ที่ทรงพลังกว่า virtual machine ของผู้ให้บริการคลาวด์
    • จัดการเซิร์ฟเวอร์ด้วยเครื่องมืออัตโนมัติอย่าง ansible และ terraform

  • ฟีเจอร์หลักของ Kubernetes เช่น deployment, บริการของ pod และ blue-green deployment นั้นมีประโยชน์

    • ในสภาพแวดล้อม cloud-native การใช้ระบบโอเพนซอร์สหลายตัวร่วมกันอาจทำให้ซับซ้อนขึ้น

  • หลายคนสร้างอินฟราสตรักเจอร์ที่ซับซ้อนเพื่อเรียนรู้ Kubernetes

    • มันอาจมีประโยชน์เมื่อต้องขยายไปสู่ลูกค้ารายใหญ่
    • แต่อาจมีประโยชน์น้อยกว่าสำหรับผู้ก่อตั้งหรือ CTO

  • แม้แต่หนังสือเกี่ยวกับไมโครเซอร์วิสก็ยังแนะนำว่า "ให้สร้างโมโนลิทก่อน"

    • ในช่วงแรก การใช้โมโนลิททำให้ดีบักได้ง่ายกว่า
    • ใช้ Docker เพื่อลดความซับซ้อนในช่วงเริ่มต้น
    • จากนั้นค่อยเปลี่ยนไปใช้ Kubernetes ตามความต้องการของธุรกิจ

  • ไม่แนะนำให้เลือกเฟรมเวิร์กที่ซับซ้อนตั้งแต่แรก

    • การใช้เครื่องมือที่ทำขึ้นเองอาจไม่ได้มีประสิทธิภาพมากกว่าเสมอไป
    • การใช้เครื่องมือมาตรฐานอาจมีประสิทธิภาพกว่าในระยะยาว

  • บนคลาวด์ ใช้แค่ VM, block storage, blob storage, DNS, IdP และผู้รับจดทะเบียนโดเมน

    • บริการอย่าง FaaS นั้นซับซ้อนและดีบักได้ยาก
    • VM เครื่องเดียวกับโค้ดเบสแบบโมโนลิทิกคือทางเลือกที่เหมาะที่สุด

  • รันโปรเจ็กต์บน VPS ราคา $10/เดือน เครื่องเดียวมาเป็นเวลา 6 ปี

    • เทคโนโลยี VPS พัฒนาไปมากจนมีความน่าเชื่อถือสูง
    • ใช้คลาวด์อินฟราสตรักเจอร์เพื่อความสามารถด้านการทำงานร่วมกันและการจัดการการปฏิบัติการ

  • ชอบโซลูชันแบบคลาวด์ แต่เลือกใช้เฉพาะส่วนที่จำเป็น

    • ใช้ Google Cloud Platform (GCP) เพื่อลดต้นทุน
    • ไม่ใช้ Kubernetes
    • ใช้ Docker เพื่อทำให้การดีพลอยง่ายขึ้น
    • บริการแบบจัดการของ GCP ช่วยประหยัดเวลา