Có rất nhiều cuộc thảo luận đang diễn ra trong thế giới Monolith v/s Microservices. Phần lớn thời gian đầu sự nghiệp của tôi dành cho việc xây dựng các khối nguyên khối và tất nhiên khi các kiến ​​trúc hướng dịch vụ bắt đầu bén rễ, chúng tôi đã áp dụng chúng với mức độ thành công tốt.

Kinh nghiệm của tôi

Tôi không cần phải tỏ ra ngầu ở đây và ném những thứ như định luật Conway vào mọi người. Kinh nghiệm hạn chế của tôi đã dạy tôi rằng chúng tôi có các cá nhân, nhóm nhỏ và nhóm lớn, những người rõ ràng được giao phụ trách một mô-đun cụ thể (hãy gọi đó là dịch vụ nếu bạn muốn). Là một phần trách nhiệm của họ, họ đã phải làm như sau:

• Họ phải sở hữu nó
• Họ đã phải duy trì nó
• Họ đã phải giao tiếp về nó
• Tạo các API có thể tương tác để tôn trọng các hợp đồng
• Kiểm tra phần mềm của riêng họ
• Hãy chú ý đến các bài kiểm tra tích hợp
• Có thể chỉ định cách triển khai nội dung của họ trong môi trường
• Gỡ lỗi và quan trọng là theo dõi một cuộc gọi trong sơ đồ tổng thể của mọi thứ.

Không phải về Monolith hay Microservices

Thực sự không có viên đạn bạc nào. Không có góc độ dứt khoát nào để sử dụng microservice hoặc sử dụng nguyên khối. Bất kỳ ai nói về việc đi theo cách này hay cách khác đều không có ý định sai trái trong việc cố gắng lay chuyển bạn nhưng với sự tôn trọng thích đáng, mọi tổ chức và nhóm phát triển của nó sẽ khác nhau, yêu cầu của họ sẽ khác, cách họ cần phát triển hoặc hỗ trợ dịch vụ/thiết bị mới sẽ khác. Trước tiên, bạn cần phải ngồi vào ghế lái để hiểu tổ chức của chính mình trước khi mù quáng áp dụng bất kỳ quan điểm nào về một công ty lớn hoặc người có ảnh hưởng.

Bất kỳ tổ chức nào cũng không được đánh giá thấp nhu cầu quản lý nhóm người, mang lại trật tự cho nhóm, tự động hóa, thử nghiệm, mang lại cho nhóm sự tự do và linh hoạt trong việc lựa chọn công cụ, đồng thời giữ cho họ kỷ luật, v.v.

Tạm gác quan điểm về monolith và microservice sang một bên. Bạn có đang giải quyết các mối quan tâm cơ bản như giao tiếp nhóm, hệ thống phân cấp, ra quyết định, kỷ luật và vệ sinh kỹ thuật phần mềm, phạm vi kiểm tra, tự động hóa, quyền tự chủ, v.v.? Hãy suy nghĩ về điều đó trong một thời điểm.

Tôi khuyên bạn nên làm gì?

Trong cuốn sách của mình, tôi thích xem xét toàn bộ một ứng dụng và về cơ bản tại sao nó lại tồn tại ngay từ đầu? Sau khi bạn có những câu trả lời đó, hãy xem các trường hợp sử dụng hoặc hành trình người dùng của khách hàng mà người dùng tương tác với ứng dụng của bạn là gì? Đối với tôi, cuối cùng nó đi xuống như sau:

1. Bạn cần một quy trình hiệu quả (hoàn toàn tự động hoặc không) để phát triển và triển khai ứng dụng của mình trong nhiều môi trường khác nhau và có thể di chuyển các phiên bản giữa chúng.
2. Bạn cần có một quy trình hiệu quả để theo dõi những thay đổi trong mã nguồn của bạn với những gì đã được triển khai trong sản xuất.
3. Cuối cùng và quan trọng nhất, khi sự cố xảy ra và điều đó sẽ xảy ra, bạn có khả năng theo dõi và theo dõi những gì đang xảy ra, xác định vị trí thành phần gây ra sự cố, gỡ lỗi hiệu quả và hiểu nguyên nhân gốc rễ và sau đó có quy trình triển khai thay đổi để giảm thiểu người dùng bị ảnh hưởng.

Bây giờ nếu kiến ​​trúc nguyên khối và/hoặc vi dịch vụ có thể giúp bạn giải quyết vấn đề đó, với các ràng buộc về tổ chức của bạn, thì hãy làm theo điều đó. Bạn không phải là Google, Facebook, Microsoft, Amazon và họ không phải là bạn. Bạn thậm chí không cần phải ngay lập tức so sánh mình với các tổ chức khác, những tổ chức có thể thông minh hơn, nhanh nhẹn hơn hoặc bất kỳ đặc điểm nào trong số đó.

Tất cả những gì bạn cần làm là xây dựng một nền văn hóa lành mạnh trong tổ chức của bạn, cởi mở để thảo luận và bắt đầu đo lường những gì DORA đề xuất:

• Thời gian khôi phục dịch vụ
• Thay đổi tỷ lệ thất bại
• Thời gian dẫn đầu cho các thay đổi
• Tần suất triển khai.

Nhận xét kết luận của tôi là tập trung vào những gì giúp bạn phân phối phần mềm của mình một cách hiệu quả (chi phí, hoạt động và mọi thứ đi kèm). Mọi thứ khác giống như một cuộc tranh luận về Bản tin 9 giờ tối.