#monolith

Microservices Are Not a Sign You’re a Senior Engineer

Bài viết chỉ ra hiện tượng coi số lượng dịch vụ microservices như dấu hiệu của kinh nghiệm cao trong ngành phần mềm. Tac giả lấy ví dụ về một dự án có tới 37 dịch vụ độc lập, mỗi dịch vụ được triển khai trong container và kết nối qua API REST/gRPC. Nguyên nhân kỹ thuật là xu hướng tách hệ thống quá sớm mà không xác định rõ ranh giới nghiệp vụ, dẫn đến sự dư thừa trong quản lý cấu hình, giám sát và truy vết lỗi. Hệ quả là tăngภาระ vận hành, độ trễ giao tiếp giữa dịch vụ và khó duy trì tính nhất quán dữ liệu, khiến đội ngũ tiêu tốn nhiều thời gian cho DevOps thay vì phát triển tính năng. Bài học là trước khi quyết định chuyển sang microservices, cần đánh giá độ phức tạp miền vấn đề, cân nhắc sử dụng monolith mô-đun hoặc các dịch vụ có kích thước vừa phải, và chỉ mở rộng khi có bằng chứng thực tế về nhu cầu mở rộng và đội ngũ có khả năng vận hành.

Bài viết này giúp lập trình viên hiểu rằng kiến trúc microservices không phải là thước đo trình độ kỹ năng hay kinh nghiệm senior thực sự.

Boring Stacks Quietly Won July. Fashion Stacks Quietly Paid for On-Call

Tháng Bảy, các ứng dụng Rails và backend ổn định (calm backends) lại được đánh giá cao về mặt văn hóa, trong khi những "Fashion Stacks" phải trả tiền cho chế độ trực (on-call) dù không thực sự cần thiết.

Lập trình viên nên đọc bài này để hiểu cách các stack truyền thống (như Ruby on Rails) vẫn chiếm ưu thế trong các công việc đòi hỏi sự ổn định và hiệu suất cao, trong khi các stack "trang trí" (mới) chỉ được ưu tiên khi cần giải quyết vấn đề cấp bách ngay lập tức.

What even are microservices? — var0.xyz

Microservices chủ yếu giải quyết vấn đề tổ chức hơn là vấn đề kỹ thuật, giúp đưa ra quyết định kiến trúc rõ ràng hơn.

Lập trình viên nên đọc bài này để hiểu rõ rằng thiết kế microservices không chỉ là kỹ thuật mà còn là cách tổ chức công việc và quản lý dự án, giúp tránh rắc rối về quy mô và sự độc lập trong phát triển phần mềm.

Have less stuff

When I joined Cheddar I was pleasantly surprised to find a sharp, mostly minimalist development culture which was a pleasant departure from the ZIRP-era “platform and team sprawl” that was in full bloom at WeTransfer. The mostly-Shopify-inspired mindset - the Shopify of roughly 2012-2014, when Bouke and Tariq were there, long before the sharded-the-world Shopify of today - was extremely poignant and felt like a breath of fresh air: Let’s not have services, at most - we’ll have 2 Let’s not have Kubernetes and use GCP native VM scaling instead Let’s not have frontend bundling of any kind and rely on Rails builtins for any internal web plumbing Since then I took this approach to heart, and furthered it even when Bouke left for Monumental, and Emil chose for greener pastures as well. Time and time again, when we were faced with adding more systems and services to the stack, we resisted - and while I can’t prove we were right (we never ran the branch of history where we caved), not once did we later sit around wishing we had the extra stuff. So what is it that made stuff my biggest enemy, and why should you consider joining the cause?

Microservice dogma nearly tanked our seed round

Một startup áp dụng microservices quá sớm dẫn đến chi phí vận hành tăng vọt, gần như hủy hoại vòng gọi vốn hạt giống. Sau khi quay lại kiến trúc monolith, họ nhận ra tầm quan trọng của việc lựa chọn công nghệ phù hợp với giai đoạn phát triển.

Đọc bài này để tránh rủi ro khi áp dụng kiến trúc microservices quá sớm, từ đó học cách cân bằng tốc độ phát triển với sự ổn định và chi phí bền vững trong dự án.