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.

2. Vận hành song song trên web và cục bộ

Nhìn hình trong bài gốc thì có vẻ anh ấy làm việc bằng cách mở 5 cái ở cục bộ và 5 cái trên web. Không rõ có lý do gì để chia thành 5 và 5 như vậy, thay vì nhất thiết phải chạy 10 cái ở cục bộ và 10 cái trên web?

Đâ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.

Vừa dùng vừa ủng hộ chút... Gần đây tôi đang dùng và thấy khá thú vị.
Tôi thích cảm giác nó chỉ cố cải thiện những điểm bất tiện của C.
Tài liệu chính thức thì vẫn chưa thực sự chín muồi
(muốn tìm hiểu mấy tính năng này kia thì nhiều khi lại được mô tả ở những chỗ rất bất ngờ...)

Tò mò về tương lai của StackOverflow

Excalidraw thật sự rất tuyệt

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

Bây giờ là một dịch vụ cung cấp bản dịch các bài viết từ những trang được liệt kê ở trên...

Tôi đã đọc phần tóm tắt rất kỹ, cảm ơn bạn.

Đâ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.

Mỗi năm đều được đăng vào tháng 11, nhưng năm nay tôi chia sẻ hơi muộn một chút.
Dự đoán công nghệ của CTO Amazon sau năm 2025
Dự đoán công nghệ của CTO Amazon sau năm 2024
Dự đoán công nghệ của CTO Amazon sau năm 2023
Dự đoán công nghệ của CTO Amazon sau năm 2022

Đ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.

Tuyệt vời ^^

Cảm ơn bạn đã trả lời.

Tôi cũng đã nghĩ đến vấn đề chi phí, quả nhiên có vẻ chi phí thay đổi rất lớn tùy theo độ phân giải của ảnh đầu vào. Ngoài ra, tôi hoàn toàn chưa nghĩ đến mối quan hệ giữa kích thước ảnh đầu vào và tốc độ xử lý, thật thú vị. Hóa ra khi crop thì tốc độ xử lý cũng nhanh hơn.

Và mức cải thiện độ chính xác thật sự rất đáng ngạc nhiên!
Hiệu năng của VLM đã được cải thiện rất nhiều, nhưng dù vậy thì hiện tại vẫn chưa thể vượt qua hiệu năng của mô hình YOLO được huấn luyện cho một mục đích duy nhất sao?

Cảm ơn bạn đã ghi lại bằng bài viết những kinh nghiệm và bí quyết đúc kết từ tình huống thực tế.
Nếu sau này tôi gặp một vấn đề tương tự, nhất định tôi sẽ tham khảo những phương pháp bạn đã dùng.

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.

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

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).

Dùng thì ổn hơn tưởng tượng, nhưng vì hỗ trợ bên thứ ba trên Mac vẫn tốt hơn nên cuối cùng lại không dùng.. haha

Cảm giác như đang chê chỉ để chê.

Đây là bài viết giải thích kiến trúc về cách một sản phẩm thực sự được cấu thành.
Nhân lúc đã ổn định ở phiên bản 1.0 và sắp xếp lại tài liệu, tôi cũng thử chỉnh lý lại bài viết.