- Unkey, đơn vị cung cấp dịch vụ xác thực API, đã chuyển từ kiến trúc serverless dựa trên Cloudflare Workers sang máy chủ trạng thái dựa trên Go để giải quyết các vấn đề về hiệu năng và độ phức tạp kiến trúc
- Kiến trúc mới mang lại tốc độ phản hồi nhanh hơn 6 lần, đồng thời loại bỏ các cách lách cache phức tạp và overhead của pipeline dữ liệu
- Trong môi trường serverless, do không có bảo đảm bộ nhớ bền vững giữa các lần gọi hàm, mọi lần đọc cache đều cần yêu cầu mạng, dẫn đến độ trễ cache p99 trên 30ms
- Khi chuyển sang kiến trúc ứng dụng đơn giản hơn từ một hệ thống phân tán, Unkey có thể self-host, đạt được tính độc lập nền tảng và cũng cải thiện mạnh trải nghiệm nhà phát triển
- Serverless phù hợp với workload không đều hoặc các mẫu request/response đơn giản, nhưng khi cần độ trễ thấp ổn định hoặc quản lý trạng thái bền vững, máy chủ trạng thái sẽ hiệu quả hơn
Giới hạn của serverless và các nút thắt hiệu năng
- Với Unkey, xác thực API nằm ở trung tâm đường đi của request nên độ trễ chỉ vài mili giây cũng tác động trực tiếp đến trải nghiệm người dùng
- Việc triển khai edge toàn cầu và khả năng tự động mở rộng của Cloudflare Workers rất hấp dẫn, nhưng thiếu tính bền vững của cache và độ trễ từ yêu cầu mạng đã bộc lộ thành vấn đề
-
Vấn đề cache
- Hàm serverless không có bộ nhớ duy trì giữa các lần gọi, nên mỗi lần tra cứu cache đều cần một yêu cầu mạng bên ngoài
- Độ trễ p99 khi tra cứu cache trên Cloudflare được đo là trên 30ms
- Dù chồng nhiều lớp cache (SWR, Redis, v.v.), về bản chất vẫn không thể nhanh hơn ‘0 yêu cầu mạng’
- Kết quả là không thể đạt được mục tiêu phản hồi dưới 10ms
-
Vấn đề gắn chặt với SaaS
- Serverless giúp giảm gánh nặng quản lý hạ tầng, nhưng trên thực tế lại khiến các công cụ SaaS bổ sung trở nên bắt buộc
- Cache → Redis, xử lý batch → Queue, log → Durable Objects, v.v.
- Mỗi dịch vụ lại bổ sung độ trễ, chi phí và điểm lỗi
- Dù dùng kết hợp Cloudflare Durable Objects, Queues, Workflows, v.v., độ phức tạp thực tế lại còn tăng lên
-
Vấn đề pipeline dữ liệu
- Vì serverless là môi trường tạm thời nên mọi lần gọi đều phải flush dữ liệu ngay lập tức
- Để xử lý event, log, metric, Unkey phải tự xây dựng các dịch vụ đệm và trung chuyển phức tạp
- Ví dụ:
- Gửi log theo lô sang ClickHouse qua
chproxy
- Khi gửi log sang Axiom, phải dựng một máy chủ đệm riêng để vượt qua giới hạn tốc độ (rate limit)
- Kết quả là ngay cả chức năng phân tích đơn giản cũng kéo theo mức độ phức tạp như một hệ thống xử lý sự kiện phân tán
Chuyển sang máy chủ có trạng thái
- Sau khi áp dụng máy chủ trạng thái v2 dựa trên Go, Unkey có thể gom lô trong bộ nhớ và flush theo chu kỳ
- Không cần thêm dịch vụ phụ hay pipeline phức tạp
- Khả năng bảo trì, debug và kiểm thử cục bộ đều trở nên đơn giản hơn rất nhiều
-
Kết quả hiệu năng
- So sánh
/v1/keys.verifyKey và /v2/keys.verifyKey cho thấy độ trễ giảm 6 lần
- Dù dùng ít hạ tầng hơn 300 POP toàn cầu của Cloudflare, hiệu năng cảm nhận của người dùng vẫn cải thiện rõ rệt
Lợi ích ngoài hiệu năng
-
Self-hosting
- Do phụ thuộc vào runtime của Cloudflare, khách hàng không thể self-host Unkey
- Dù runtime Workers về mặt kỹ thuật là mã nguồn mở, việc chạy cục bộ, kể cả ở chế độ phát triển, cũng cực kỳ khó khăn
- Khi chuyển sang máy chủ Go tiêu chuẩn, self-hosting trở nên đơn giản
- Có thể chạy chỉ với lệnh
docker run -p 8080:8080 unkey/api
- Không cần runtime đặc biệt hay cấu hình phức tạp
- Giờ đây các nhà phát triển có thể chạy toàn bộ stack Unkey cục bộ chỉ trong vài giây, giúp việc debug và kiểm thử dễ dàng hơn rất nhiều
- Tốc độ phát triển và debug cục bộ được cải thiện vượt bậc
-
Cải thiện trải nghiệm nhà phát triển
- Các giới hạn từng gặp ở serverless:
- Cần tính đến các ràng buộc khi thực thi hàm
- Khó duy trì trạng thái giữa các lần gọi
- Việc debug log phân tán rất phức tạp
- Môi trường kiểm thử cục bộ bất tiện
- Khi chuyển sang máy chủ trạng thái, Complexity Tax này đã được loại bỏ
-
Đảm bảo tính độc lập nền tảng
- Không còn bị khóa trong hệ sinh thái Cloudflare
- Có thể triển khai ở bất kỳ đâu
- Có thể dùng bất kỳ cơ sở dữ liệu nào
- Có thể tích hợp dịch vụ bên thứ ba mà không phải lo tương thích runtime
Chiến lược di chuyển và bài học rút ra
- Quá trình migration được tận dụng như cơ hội để sửa các vấn đề thiết kế API đã tích tụ theo thời gian
- API v2 mới chạy song song với v1 hiện có, cho phép khách hàng dùng cả hai phiên bản trong thời gian ngừng hỗ trợ
- Một lợi thế của việc giữ lại serverless là ngay cả khi mức sử dụng giảm về 0, chi phí chạy API v1 vẫn không cao, nhờ đó có được thời gian migration miễn phí
-
Những gì được giữ lại
- Unkey không vứt bỏ toàn bộ cách tiếp cận serverless
- Triển khai edge toàn cầu: dùng AWS Global Accelerator để duy trì độ trễ thấp trên toàn thế giới
- Tự động mở rộng: Fargate xử lý scaling mà không có các ràng buộc của serverless
-
Cải thiện hiệu năng rate limiter
- Trong mô hình serverless, cần đánh đổi đáng kể giữa tốc độ, độ chính xác và chi phí, và do đặc tính phân tán nên gần như không thể đạt cả ba cùng lúc
- Với máy chủ trạng thái và trạng thái trong bộ nhớ, Unkey đã xây dựng được rate limiter nhanh hơn, chính xác hơn và còn giảm chi phí vận hành
Khi nào serverless phù hợp (và khi nào không)
-
Khi serverless phù hợp
- Workload không đều: hiệu quả kinh tế của việc scale về 0 rất tốt khi không chạy liên tục
- Mẫu request/response đơn giản: khi không cần trạng thái bền vững hay pipeline dữ liệu phức tạp
- Kiến trúc hướng sự kiện: rất phù hợp để phản hồi sự kiện mà không phải quản lý hạ tầng
-
Khi serverless không phù hợp
- Khi cần độ trễ thấp ổn định: sự phụ thuộc vào mạng bên ngoài làm giảm hiệu năng
- Khi cần trạng thái bền vững: việc lách tính không trạng thái làm tăng độ phức tạp
- Workload tần suất cao: mô hình tính phí theo mỗi lần gọi là không kinh tế
- Khi cần kiểm soát chi tiết: lớp trừu tượng của nền tảng có thể trở thành ràng buộc
-
Chi phí của độ phức tạp
- Bài học lớn nhất của cuộc migration này là hiểu được chi phí phức tạp khi phải lách qua các ràng buộc của nền tảng
-
Những gì đã phải xây dựng trong serverless
- Thư viện cache tinh vi để vượt qua tính không trạng thái
- Nhiều dịch vụ phụ trợ cho xử lý dữ liệu theo lô
- Pipeline log phức tạp để thu thập metric
- Các cách lách tinh vi cho phát triển cục bộ
-
Với máy chủ trạng thái
- Tất cả những thứ trên đều biến mất
- Chuyển từ một hệ thống phân tán với nhiều thành phần chuyển động sang kiến trúc ứng dụng đơn giản hơn
- Đôi khi, thay vì tìm cách lách ràng buộc, chọn một nền tảng khác mới là giải pháp tốt nhất
Bước tiếp theo
- Hiện tại Unkey đang chạy trên AWS Fargate phía sau Global Accelerator, nhưng đây chỉ là giải pháp tạm thời
- Năm tới, Unkey dự kiến ra mắt nền tảng triển khai riêng mang tên "Unkey Deploy" để khách hàng, cũng như chính Unkey, có thể chạy ở bất cứ nơi nào họ muốn
- Việc chuyển sang máy chủ Go có trạng thái là bước đầu tiên để biến Unkey thành một hệ thống thực sự có thể di chuyển và self-host
- Chi tiết triển khai được công khai dưới dạng mã nguồn mở trong kho GitHub
3 bình luận
Trước đây tôi cũng gần như là một tín đồ serverless và áp dụng kiến trúc serverless khắp nơi, nhưng dạo này tôi lại thích cấu trúc gồm một
ec2và mộtrdshơn. Rồi sau đó dần dần tách từng thứ cần thiết ra. Việc đưa serverless vào giờ khiến tôi phải cân nhắc rất nhiều.Có nhiều lý do, nhưng chỉ cần trong team có một người không có kiến thức về serverless thôi là chi phí giao tiếp/bảo trì đã tăng lên đáng kể. Và khi quay lại vận hành server, tôi lại một lần nữa cảm nhận rằng serverless không hề rẻ như mình nghĩ, cũng không tiện như mình tưởng.
Ý kiến trên Hacker News
Với tư cách là người đã dùng môi trường serverless vài năm nay (chủ yếu là amazon lambda, cùng một số thứ khác), tôi rất đồng ý với tác giả.
serverless đúng là giúp giảm việc ở một số mặt, nhưng đồng thời lại làm tăng việc ở các mặt khác vì phải xử lý những "vấn đề phát sinh một cách nhân tạo".
Một ví dụ của tôi là vấn đề giới hạn dung lượng tải lên.
Khi chuyển một ứng dụng hiện có sang serverless, tôi nghĩ chỉ cần tạo API endpoint cho việc import dữ liệu khách hàng dung lượng lớn rồi gắn thêm worker chạy nền là đủ.
Nhưng ở "api gateway" (proxy gọi code) thì không thể tải lên quá 100MB, và khi hỏi liệu có thể đổi giới hạn này không thì tôi được hướng dẫn rằng cứ bảo khách hàng chia file nhỏ hơn để tải lên.
Nghe thì có vẻ hợp lý về mặt kỹ thuật, nhưng thực tế là khách hàng sẽ không thay đổi cách họ tải dữ liệu lên.
Nó giống kiểu "chạy tốt trong chân không" hơn; nhìn trên lý thuyết thì hay đấy, nhưng khi làm thật thì thời gian và chi phí tiết kiệm được nhờ chuyển sang serverless rốt cuộc lại bị đổ trở lại vào việc xử lý các vấn đề rất đặc trưng của serverless.
Để giải quyết việc này thì cần cung cấp presigned S3 URL.
Có thể tích hợp bằng cách để người dùng tải trực tiếp lên S3 rồi gửi lại kết quả tải lên, hoặc phân biệt file name bằng request id.
Với người đã dùng AWS lâu năm như tôi thì chuyện này khá phiền, nhưng nếu mở hẳn một API upload file tùy ý thì rủi ro bị tấn công DoS là rất lớn nên tôi vẫn hiểu vì sao có giới hạn 100MB.
Tuy vậy, xét việc tốc độ Internet giờ đã nhanh hơn nhiều thì mốc 100MB có cảm giác hơi lỗi thời.
Dù sao tôi vẫn nghĩ cuối cùng thì phải có một giới hạn nào đó.
Công ty chúng tôi từng là khách hàng đại diện cho bộ phận chứng chỉ SSL của AWS.
Vì muốn hỗ trợ Vanity URL (custom domain), chúng tôi cần chứng chỉ SSL cho từng domain, và số lượng lên đến hàng nghìn.
Công cụ quản lý chứng chỉ của AWS chỉ hoạt động mượt đến quy mô vài trăm cái, nên mất khoảng 3 tháng mới xử lý xong vấn đề này.
Tôi khá ngạc nhiên khi thấy một số dịch vụ của AWS không thể phản ứng nhanh trước nhu cầu của một nhóm khách hàng rất nhỏ.
Ban đầu Lambda trông cực kỳ hứa hẹn nên chúng tôi áp dụng, nhưng cuối cùng đã từ bỏ toàn bộ các dự án Lambda và chuyển sang môi trường container khi cần.
Lambda cũng buộc phải nâng cấp Node runtime mỗi 1–2 năm, còn nếu dùng container thì mình có thể tự quyết định chu kỳ đó nên linh hoạt hơn.
Vấn đề khó nhất trong khoa học máy tính là sao chép file từ máy tính này sang máy tính khác.
Để lại tài liệu tham khảo cho độc giả tương lai.
Dùng uploader và endpoint của "tus" thì sẽ có các tính năng như chia nhỏ khi upload, resume, v.v., nên phù hợp để vượt qua kiểu giới hạn này.
https://tus.io/
Như bài viết đã nói, serverless rõ ràng có chỗ dùng riêng của nó.
Nhưng tôi nghĩ nó không phù hợp với phần lớn ứng dụng.
Trừ trường hợp đặc biệt, tôi không định dùng serverless làm hạ tầng cốt lõi.
Thực tế tôi có cảm giác nó còn làm việc quản lý hạ tầng trở nên phiền hơn.
Mỗi nền tảng lại có yêu cầu khác nhau, cách test/phát triển cũng mỗi nơi một kiểu, nên lần nào cũng mơ hồ và rất khó test local.
Các lớp abstraction cũng đầy bẫy theo từng nền tảng và không hề có chuẩn thực sự.
Đóng gói executable bằng Docker image thì tiện hơn, lại có thể abstraction việc thiết lập môi trường ở mức vừa đủ nên với tôi đó là môi trường phát triển tự nhiên hơn.
Tôi thấy mức abstraction tối thiểu ở Linux environment và filesystem là hiệu quả nhất.
Nếu cần thì có thể dựng image đó lên server và vận hành theo kiểu on-demand hoặc luôn ở trạng thái chờ.
Nhìn vào nhiều xu hướng công nghệ nổi lên trong 10 năm qua, có rất nhiều trường hợp một công nghệ trở nên phổ biến chỉ vì các công ty lớn dùng nó để giải quyết những vấn đề thực tế chỉ tồn tại ở quy mô của họ.
Các ví dụ gồm GraphQL, react, Tailwind, NextJS và nhiều thứ khác.
Không có công cụ nào là vạn năng cho mọi vấn đề; điều quan trọng là phải chọn dựa trên kinh nghiệm và sự hiểu biết về hoàn cảnh cùng bài toán của chính mình.
Tôi chỉ muốn nói rằng hiện giờ tôi đang cố chạy app amazon lambda trên local một cách "vui vẻ" đến mức nào.
Muốn test trước khi deploy mà đúng là một thử thách thực sự.
Knative (Serverless cho Kubernetes) nhận trực tiếp container.
Vì đó là định dạng đóng gói tiêu chuẩn nên có thể dễ dàng chuyển giữa nhiều nền tảng.
Nhóm đó thực ra đang phát triển một thư viện để tích hợp vào ứng dụng server có trạng thái, chứ không phải bản thân ứng dụng.
Lợi thế hiệu năng cũng đến từ việc xử lý authentication gần môi trường khách hàng hơn, chứ không phải nhờ bản thân serverless.
Thật ra chẳng phải mọi nền tảng "serverless" đều nhận Docker image sao?
Tôi biết Cloud Run có hỗ trợ.
Điều tôi thực sự lo là việc “serverless function” abstraction quá nhiều thứ.
ClickHouse không thích hàng nghìn lệnh insert nhỏ, nên chúng tôi dùng một dịch vụ Go tên là chproxy để gom event rồi gửi theo batch lớn.
Mỗi Cloudflare Worker gửi analytic event tới chproxy, rồi chproxy gom lại và gửi hàng loạt vào ClickHouse.
Chỉ riêng với dữ liệu ClickHouse thì tôi tự hỏi vì sao họ không dùng tính năng asynchronous insert, thay vì làm hẳn một dịch vụ riêng.
https://clickhouse.com/docs/optimize/asynchronous-inserts
Tôi có cảm giác các lập trình viên đang bị chôn vùi dưới đống công cụ "giúp làm mọi thứ dễ hơn".
Thực ra phần lớn vấn đề hoàn toàn có thể giải quyết dễ dàng chỉ bằng các công cụ cơ bản nhất (compiler, bash script, library).
Kiểu ám ảnh với công cụ như vậy đôi khi lại gây hại cho cả công ty lẫn lập trình viên.
Theo tôi, Docker của năm 2013 có lẽ là công cụ cuối cùng thật sự tạo ra thay đổi tích cực và mang tính phổ quát.
Từ đó về sau, nhiều thứ có thể hữu ích với một số công ty, nhưng khi cố áp cho mọi công ty thì lại dẫn đến giảm năng suất hoặc làm hệ thống sụp đổ.
Dạo gần đây những nơi như Cloudflare đang đẩy v8 isolates như thể đó sẽ là 'docker thế hệ tiếp theo', nhưng nó chỉ bắn trúng một số workload chứ không phù hợp với mọi nơi.
Mô hình "nhận Docker image rồi đưa nó lên Internet chạy" quá mạnh, nên tôi nghĩ đến tận 2040 nó vẫn sẽ là cách mạnh nhất.
Việc ngày càng ít người nắm nền tảng cơ bản cũng là một vấn đề.
Công việc được thực hiện theo kiểu outsource phần lớn stack cho dịch vụ bên thứ ba, còn thứ tự tay mình làm chỉ là một phần ứng dụng cốt lõi.
Thậm chí phần đó rồi cũng có thể do AI viết.
Cả ngành đang nuôi lớn một kiểu "bất lực đã được học".
Nhiều người hơn bạn tưởng là không rành compiler, bash script và library.
AWS lambda rẻ đến mức gần như quá rẻ.
Nó có ích cho mục đích xây dựng tên tuổi đấy!
Tôi chưa từng thấy ai lên đến cấp Staff nhờ viết bash script cả.
Tôi muốn hỏi "vercel security checkpoint" một điều.
Trên iPhone, khi dùng proton VPN với Firefox Focus để kết nối qua các exit node ở California và Canada, tôi liên tục gặp lỗi code 99 "Failed to verify your browser".
Vấn đề là gì vậy?
Chuỗi thảo luận này càng làm tôi tin chắc hơn.
Bản thân từ serverless đã được định nghĩa quá mơ hồ nên tôi thấy cái tên đó rất vô nghĩa.
Rốt cuộc thì server vẫn tồn tại.
Nó giống như cách nói "không dùng điện" trong khi thực tế vẫn dùng điện vậy.
Chỉ đổi tên thôi chứ không nói lên được thực sự đang diễn ra chuyện gì.
Tôi không nghĩ kết luận chỉ đơn giản là "serverless là xấu".
Bài học quan trọng hơn là nếu dịch vụ có dependency, thì ngay cả khi bạn chuyển dịch vụ đó lại gần client hơn, trải nghiệm end-to-end vẫn có thể chậm ngoài dự kiến nếu không chuyển cả dependency đi cùng.
Về bản chất, tốt hơn là build gần dependency; nếu chưa đủ thì phải chuyển hoặc đồng bộ toàn bộ dependency đến gần client hơn, nhưng trên thực tế quá trình đó thường trở nên cực kỳ phức tạp.
Còn tùy dependency được dùng theo cách nào, tần suất bao nhiêu; nếu là DB thì nên ở gần server hay gần client cũng khác nhau theo mục đích.
Có use case cần phản hồi nhanh, có cái chậm cũng không sao.
Tùy việc có thể cache gì ở server hay client mà còn có thể tách nhỏ ra.
Tôi không nghĩ nên nhìn nó theo kiểu nhị nguyên như vậy.
Nếu muốn tỷ lệ giá/hiệu năng tốt nhất, đáp án là tự thiết lập instance và tự làm những gì mình cần.
Không cần để các công ty cloud trở thành những pháp sư tính phí quá tay.
Hiện tại thứ chúng ta đạt tới như một "local maximum" là dùng Docker container làm môi trường/artefact triển khai tiêu chuẩn rồi chỉ inject secret khi cần.
Cách này giúp test local dễ dàng, đồng thời vẫn giữ được hầu hết các lợi ích chính như tự động hóa hạ tầng, khả năng tái lập, v.v.
serverless là cách tiếp cận quá tay đối với đa số ứng dụng, nhưng lại rất hợp với một số loại.
Đặc biệt, các tiện ích đơn giản không cần hạ tầng riêng, dịch vụ on-demand, hoặc ứng dụng stateless quy mô lớn có thể hợp với serverless hơn.
Không phải serverless chỉ dùng cho trường hợp đơn giản, nhưng tôi nghĩ có một sự mâu thuẫn căn bản giữa mô hình "web app truyền thống" và nền tảng serverless.
Có vẻ giờ bạn đã sẵn sàng đón nhận misterio rồi đấy.
https://github.com/daitangio/misterio
Một wrapper cụm Docker stareless đơn giản.
Nó bắt đầu từ homelab của tôi nhưng đã tạo được tiếng vang.
Docker có hơi giống microservices.
Nó phù hợp với một số ứng dụng, nhưng lại có xu hướng bị thổi phồng như thể là chuẩn mực của cả ngành.
Lạm dụng Docker sẽ tạo ra gánh nặng vá bảo mật và vận hành; nếu cứ dùng bừa cho mọi dự án thì sẽ thất bại trong quản lý rủi ro.
Vấn đề dependency giờ cũng đã được phần lớn lập trình viên giải quyết bằng mô hình không cài đặt toàn cục nữa.
Docker không còn là thứ bắt buộc như trước, nhưng vẫn rất thịnh hành.
Ở góc độ nhà cung cấp hosting, tôi đoán biên lợi nhuận sẽ tăng ít nhất 10% nhờ áp dụng Docker.
Tôi có cảm giác Docker cũng nên được tính vào cái mà ai đó bên dưới gọi là "ám ảnh với công cụ".
Ý chính không phải là serverless không hiệu quả, mà là các tác giả đã không hiểu rõ nền tảng họ đang xây.
Đưa một API nhạy cảm với độ trễ lên stateless edge runtime là sai lầm ở mức nhập môn, và những đau đớn họ gặp phải hoàn toàn có thể dự đoán trước.
Theo kinh nghiệm của tôi, phần lớn vấn đề với dịch vụ cloud đều bắt nguồn từ việc dùng sai kiến trúc hoặc hiểu sai kiến trúc.
Đó là những vấn đề do con người tạo ra mà lẽ ra có thể tránh được bằng thiết kế cẩn trọng hơn.
Tuy nhiên, vấn đề là các cloud vendor thường quảng bá sản phẩm bằng marketing rất thuyết phục trong khi lại che giấu các con số hiệu năng thực tế.
Bạn sẽ không biết Lambdas có thật sự đủ nhanh cho workload của mình hay không, hay việc replication bên ngoài AWS RDS có phù hợp không, cho đến khi tự test.
Tôi đã học được qua trải nghiệm rằng hiệu năng thực tế của AWS phải do chính mình benchmark.
Điểm quan trọng không phải là các tác giả đã không hiểu, mà là bản thân thông tin được ai đó chia sẻ đã có giá trị.
Tôi không nghĩ có thể chỉ xem đây là "lỗi của người mới".
Trong thực tế, kỹ sư thường biết một cách làm nào đó không phù hợp cho công việc thực tế, nhưng quản lý lại dễ dàng ép theo kiểu "đó là cách hiện đại bây giờ".
Hoặc vì giới hạn thời gian và chi phí nên buộc phải chọn phương án "kém hơn".
Cũng có thể đội ngũ triển khai ban đầu thật sự không hiểu rõ, nhưng dù sao việc chia sẻ những câu chuyện như thế này vẫn rất có ích cho sự phát triển của cả cộng đồng.
Theo kinh nghiệm của tôi, nếu cần một thứ gì đó chắc chắn (auto scaling nhanh, độ trễ thấp, CPU, đĩa, tốc độ mạng, v.v.) thì cách chắc ăn nhất là tự quản lý EC2 instance.
Nếu giao quyền kiểm soát đi rồi còn kỳ vọng hiệu năng tốt hơn, bạn sẽ dễ đụng phải những nút thắt không thể sửa được.
Cuối cùng thì các tác giả cũng đang thừa nhận mình là "một trong 10.000 người của hôm nay".
https://xkcd.com/1053/
Cá nhân tôi thấy biết ơn vì họ đã chia sẻ kiểu thông tin và cả những sai lầm như thế này.
Kỹ thuật xét cho cùng luôn là cuộc chiến về chi phí
Ban đầu thì dùng để rút ngắn thời gian tạo prototype hoặc xây dựng business
Về sau phải tối ưu hóa để giảm chi phí
Bản thân kiểu bài viết này đã chứng minh người viết không hiểu gì về kỹ thuật
Kiểu như vậy vậy