Câu chuyện startup đang ăn nên làm ra suýt phá sản sau 6 tháng vì áp dụng MSA

Gần đây, tôi đọc bài viết "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" đang gây chú ý trên các blog công nghệ nước ngoài, và thấy nội dung vừa quá đau đớn vừa rất đồng cảm nên xin tóm tắt chia sẻ lại.

Nó giống như một "sổ ghi lỗi sai" rất hay, cho thấy việc áp dụng công nghệ mới một cách vô điều kiện nguy hiểm đến mức nào.

---

1. Khởi đầu sự việc: "Chúng ta cũng hãy làm như Netflix"

• Tình hình: Gọi vốn seed được $2.5M, doanh thu hàng tháng tăng 40%, có 50.000 người dùng. Một startup đang vận hành rất tốt với Rails monolith.
• Khởi đầu vấn đề: Một lead architect xuất hiện, hô hào về "khả năng mở rộng (Scalability)" và đề xuất chuyển sang MSA.
• Lập luận: "Cấu trúc hiện tại gắn kết quá chặt. Hãy nhìn Netflix hay Uber đi. Nếu muốn trở thành như họ thì chúng ta cũng phải đi theo microservices."
• Thực tế: Một đội chỉ có 4 developer và 1 DevOps lại quyết định áp dụng kiến trúc kiểu Netflix.

2. Sáu tháng địa ngục (timeline áp dụng MSA)

[Tháng 1: Tuần trăng mật]

• Tách riêng thành công dịch vụ thông báo. "Thấy chưa! Vẫn ổn mà?" rồi tự ăn mừng.
• Nhưng các dấu hiệu báo trước như thời gian deploy tăng lên, số lượng repository tăng lên cũng bắt đầu xuất hiện.

[Tháng 2~3: Những vết nứt đầu tiên]

• Tách riêng dịch vụ Billing. Nhưng nó lại liên quan tới cả dịch vụ người dùng, tồn kho và đơn hàng.
• Kết quả: Do network latency, tốc độ phản hồi chậm từ 200ms → 800ms. Chỉ cần một dịch vụ chết là kéo theo sự cố dây chuyền làm toàn hệ thống sập.

[Tháng 4~5: Cơn ác mộng của distributed transaction]

• Việc trước đây chỉ cần một DB transaction trong monolith, giờ trong môi trường phân tán còn phải áp dụng cả Saga pattern.
• Tồn kho đã bị trừ nhưng thanh toán lại thất bại, rollback thì rối tung... dữ liệu không nhất quán khiến CS bị quá tải.
• Chỉ để thêm một cột đơn giản mà phải đụng tới 6 dịch vụ, việc đáng lẽ mất 2 giờ thì nay kéo thành 3 ngày.

[Tháng 6: Đội ngũ tan rã]

• Developer dồn toàn bộ thời gian vào quản lý hạ tầng thay vì phát triển tính năng.
• Chi phí hạ tầng tăng từ $3,000 → $12,000 (bùng nổ gấp 4 lần).
• Developer chủ chốt nghỉ việc ("Tôi đến đây để làm sản phẩm, chứ không phải để cả ngày ngồi vật lộn với Kubernetes")

3. Quyết định: "Chúng ta không phải Netflix"

Kiến trúc sư vẫn khăng khăng rằng "hãy áp dụng Service Mesh và tăng thêm công cụ monitoring", nhưng tác giả đã bùng nổ.

> "Chúng ta không phải Netflix! Netflix có 500 kỹ sư, còn chúng ta chỉ có 4 người thôi!"

Cuối cùng, architect nghỉ việc và cả đội quyết định quay trở lại monolith (Rollback).

4. Trở về monolith, và hồi sinh

• Trong 8 tuần, họ gộp code trở lại thành monolith.
• Kết quả:
• Tốc độ ra mắt tính năng được khôi phục (4 việc/tháng → 20 việc/tháng)
• Tốc độ phản hồi ổn định ở mức 220ms
• Chi phí hạ tầng giảm xuống
• Quan trọng nhất là mức độ hạnh phúc của developer tăng lên

5. Bài học cốt lõi (kết luận của bài viết)

1. MSA không phải công cụ giải quyết 'vấn đề kỹ thuật', mà là công cụ giải quyết 'vấn đề tổ chức'.

• Nó chỉ nên được dùng khi có từ 50 developer trở lên và mọi người bắt đầu giẫm chân nhau, hoặc khi chu kỳ deploy của các nhóm chênh lệch quá lớn.

2. Netflix/Google không phải hình mẫu dành cho bạn.

• Chính họ ban đầu cũng là monolith. Họ thay đổi vì quy mô đã lớn lên, chứ không phải ngay từ đầu đã làm vậy.

3. Độ phức tạp là một loại thuế.

• Mỗi khi số lượng dịch vụ tăng lên, chi phí quản lý sẽ tăng theo cấp số nhân.

4. Network call không hề miễn phí.

• Gọi hàm trong bộ nhớ (nano giây) và gọi qua mạng (mili giây) là khác biệt ở một đẳng cấp hoàn toàn khác.

---

Tóm lại trong một câu:
"Monolith không phải kẻ thù. Kiến trúc tồi mới là kẻ thù. Đội 4 người thì làm ơn cứ dùng monolith đi."

[ahwjdekf]

Rồi nhé. Giờ thì đám cuồng tín MSA sẽ kéo đến.

[aer0700]

Đúng là câu “network call không miễn phí” rất chuẩn. Gọi hàm và gọi API rõ ràng là khác nhau.

[bungker]

Tôi đến để làm ra sản phẩm, chứ không phải đến để ngồi vọc Kubernetes cả ngày —> Đây là câu ngu ngốc nhất mà tôi từng nghe.

[hohemian]

Tại sao? Nếu đang ở tình huống làm k8s chỉ vì mục đích là k8s thì có vẻ câu đó là đúng mà?

[roxie]

Mình thích các bình luận của bạn bungker nên vẫn bấm xem từng cái, nhưng riêng cái này thì mình không đồng cảm lắm, hừm, bạn có thể giải thích thêm được không?

[passerby]

Đây là một bài đăng về AI rỗng tuếch, nên dạo này tôi hầu như không đọc Medium nữa.

[mhj5730]

Nếu là dịch vụ do 4 người làm ra thì có lẽ đúng là không có lý do gì để tách nhỏ theo MSA cả

[moderato]

Muốn làm MSA thì tổ chức cũng phải được điều chỉnh cho phù hợp với MSA...

[ifmkl]

Có lẽ ý chính mà mục 4 trong phần tóm tắt muốn nói là điều này. Và nhìn chung thì bản thân nội dung cũng khá đáng đồng cảm.

[bsh998]

Ừm... có gì đó có vẻ kỳ kỳ
Hình như bài này được viết bằng AI.

[baeba]

Dạo này tôi cũng cảm nhận điều đó khá nhiều..
Tôi đoán là nhiều bài trên blog được viết dựa trên trải nghiệm của chính tác giả + có sự hỗ trợ của AI.
Vì các bài viết quá mạch lạc và được viết rất dễ đọc.

[bsh998]

Điều tôi muốn nói là bài này quá mang màu sắc AI và cũng không có tài liệu tham chiếu, nên tôi mong mọi người đừng chia sẻ những bài viết như thế này.

[baeba]

Đây là bài viết được đăng trên Hacker News. Hầu hết các bài tôi đăng đều là nội dung xuất hiện trên Hacker News.

https://news.ycombinator.com/item?id=46469845

Đúng như bạn nói... có lẽ tôi nên đăng kèm tham chiếu Hacker News.

[baeba]

1) Nghi ngờ độ đáng tin của bài viết: có mùi marketing/nội dung do AI tạo ra

Ý chính

• “Cái này được dựng quá khéo kiểu một vở kịch rút ra bài học” → dấy lên nghi ngờ đây là kiểu câu chữ được tối ưu cho một ‘moral play’ mà HN thích
• Trong bài gắn đầy liên kết tới tài liệu trả phí nên có luồng ý kiến mạnh rằng “rốt cuộc đây chẳng phải là bài bán hàng sao?”
• Cách viết lạm dụng danh sách/emoji bị chỉ ra là tín hiệu của “AI slop” (nội dung AI làm ẩu, sản xuất hàng loạt)

Trích dẫn chốt hạ sự thật (dịch)

“Có vẻ toàn bộ thứ này chỉ tồn tại để bán các tài nguyên trả phí được gắn link. Và nó cho cảm giác như AI slop với đống danh sách đó.”
(nguyên văn: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Đánh giá một dòng

• “Trước cả chuyện nội dung đúng hay sai, mùi bán hàng + mùi AI đã quá nồng” là phản ứng số 1.

---

2) Chỉ trích lãnh đạo/architect: vấn đề không phải công nghệ mà là ‘cấu trúc ra quyết định’

Ý chính

• Có nhiều phản ứng cho rằng ngay từ việc “đội 4 người mà có architect?” đã là lệch hướng rồi
• Đặc biệt, góc nhìn xem architect không viết code/vai trò DevOps tách rời là kiểu “nút thắt cổ chai + tối ưu CV” xuất hiện khá mạnh
• Giọng điệu chung là không phải microservices giết công ty, mà là “một cấu trúc nơi không ai thực sự chịu trách nhiệm cho việc deploy/vận hành/khắc phục sự cố” mới là thứ làm hỏng mọi chuyện

Trích dẫn đanh thép (dịch)

“Architect mà công việc là định ra ‘quy tắc’ với ‘pattern’ nhưng không trực tiếp triển khai thứ gì thì gần như lúc nào cũng là ý tưởng tệ. Cứ tập trung ship sản phẩm đi... Khi người không viết nổi 10 dòng code lại độc chiếm quyết định thì sẽ toang.”
(nguyên văn: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Đánh giá một dòng

• Ý kiến “MSA không phải vấn đề, mà vấn đề là thiết kế vai trò có quyền quyết định nhưng không có trách nhiệm” xuất hiện khá mạnh.

---

3) Góc nhìn kinh doanh: nguyên nhân startup thất bại thật sự có phải là MSA?

Ý chính

• Có những bình luận không tin vào chính cách đóng khung “sụp đổ vì kiến trúc”
• Luận điểm cốt lõi: nếu PMF/nhu cầu/độ gắn kết khách hàng yếu thì dùng stack nào cũng có thể thất bại
• Đặc biệt, các chi tiết như “khách hàng chỉ vì chậm hai ngày là bỏ đi ngay?” bị soi để hỏi ngược rằng có phải giá trị sản phẩm vốn đã yếu rồi không
• Và họ cũng chỉ ra mâu thuẫn ngay trong bài: nói “MSA đã giết startup”, nhưng kết luận lại là “đã sống sót?” → nghi ngờ câu chuyện bị cường điệu

Trích dẫn chốt hạ sự thật (dịch)

“Thứ giết startup là làm ra một sản phẩm mà chẳng ai muốn, chứ không phải kiến trúc MSA. Nói MSA giết startup cũng vô lý giống như nói Python hay Go đã giết startup vậy...”
(nguyên văn: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Đánh giá một dòng

• Có một góc nhìn rất rõ là: “kiến trúc chỉ là cái cớ, nguyên nhân thật có thể là thị trường/sản phẩm/dòng tiền.”

---

4) Góc nhìn kỹ thuật: lời khuyên dựa trên trải nghiệm về monolith vs MSA (phần thực sự hữu ích)

Ý chính

• “MSA có một loại thuế chi phí cố định (độ phức tạp vận hành)” → nhiều chia sẻ kinh nghiệm cho rằng điều này có thể chí mạng với đội nhỏ
• Từ khóa chính: Premature distribution (phân tán quá sớm), modular monolith/modulith, “hãy ‘kiếm được’ boundary”
• Các điều kiện khiến MSA thực sự cần thiết cũng được nêu ra khá thực tế: khi quy mô đội ngũ tăng lên và các vấn đề về xung đột/deploy/tổ chức thực sự bắt đầu bùng phát
• Ngược lại, cũng có lời khuyên rằng vấn đề hiệu năng/mở rộng thường không nên “giải bằng MSA” ngay, mà trước hết hãy xem thuật toán/nút thắt cổ chai/sharding/partitioning

Trích dẫn đanh thép (dịch)

“Thứ giết startup không phải là microservices mà là ‘phân tán quá sớm’. Họ tách ra trước khi boundary thực sự hình thành nên chỉ phải trả giá bằng latency và chi phí điều phối; hãy bắt đầu với modular monolith, kiếm được boundary rồi mới tách ra.”
(nguyên văn: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Đánh giá một dòng

• Bài học mà cộng đồng thực sự đồng cảm là:
  “Hãy bắt đầu bằng monolith, và chỉ tách service khi boundary xuất hiện một cách ‘tự nhiên’.”

---

Tổng kết cộng đồng trong một câu

Hầu hết đều đồng ý với câu “chúng ta không phải Netflix”, nhưng đồng thời cũng nghi ngờ mạnh rằng chính bài viết này có thể là một kiểu câu chuyện bán ‘căn bệnh thích bắt chước Netflix’ (= marketing/AI).