Chọn Công Nghệ: Cái Đẹp và Cái Xấu trong Kiến Trúc Phần Mềm

Giới thiệu

Chào các bạn, tôi là Igor Fraga. Đây là bài viết thứ tư trong chuỗi bài viết nhằm khám phá những thách thức và vai trò của chúng ta như những Kiến Trúc Sư Phần Mềm.

Một trong những nhiệm vụ quan trọng nhất của tôi là chọn công nghệ. Nhưng đây cũng là một trong những công việc nguy hiểm nhất.

Chúng ta thường thấy những công cụ mới, hấp dẫn có hứa hẹn sẽ nhanh chóng và tuyệt vời. Tôi gọi những công cụ này là Cái Đẹp.

Ngược lại, có những công cụ cũ, đáng tin cậy mà chúng ta biết chắc sẽ hoạt động tốt. Chúng có thể không hấp dẫn nhưng rất mạnh mẽ. Tôi gọi chúng là Cái Xấu.

Việc chọn Cái Đẹp và quên đi Cái Xấu là một sai lầm lớn. Tôi biết điều này vì tôi đã thấy sai lầm này xảy ra nhiều lần, kể cả trong một dự án với một đội ngũ rất tốt. Đây là câu chuyện của chúng tôi.

Câu chuyện: Giấc mơ về một hệ thống siêu nhanh

Vài năm trước, một công ty tên là X (tôi sẽ không tiết lộ tên ở đây) cần một hệ thống mới để xử lý nhiều sự kiện từ hàng ngàn người dùng trên toàn thế giới, tích hợp các nền tảng của họ mà trước đây vẫn tách biệt.

Mục tiêu là xử lý những sự kiện này rất nhanh, với độ trễ rất thấp. Đội ngũ của chúng tôi thông minh và có kinh nghiệm, nhưng kiến trúc sư nghĩ rằng hệ thống Java phản ứng là cách tốt nhất để thực hiện điều này.

Cái Đẹp mà anh ấy muốn chúng tôi sử dụng là một công nghệ gọi là Project Reactor và Spring WebFlux. Nó hứa hẹn những điều tuyệt vời:

• Không chặn. Điều này có nghĩa là nó có thể xử lý nhiều tác vụ cùng lúc mà không cần chờ đợi. Nó sẽ nhanh hơn nhiều so với các hệ thống cũ.
• Sử dụng ít tài nguyên hơn. Nó có thể quản lý hàng ngàn kết nối chỉ với một vài luồng. Cách cũ cần một luồng cho mỗi kết nối.
• Mã sạch. Đây là cách hiện đại và đơn giản để viết mã phức tạp.

Sự lựa chọn khác là Cái Xấu mà chúng tôi đã biết rất rõ: Spring MVC cổ điển. Chúng tôi đã sử dụng nó cho nhiều hệ thống khác. Nó rất mạnh mẽ và toàn bộ đội ngũ của chúng tôi đều hiểu nó.

Đội ngũ đã khá hoài nghi về việc sử dụng phản ứng nhưng kiến trúc sư khăng khăng nói rằng đó là cách duy nhất để đủ nhanh.

Tôi lo lắng rằng sẽ khó học và bảo trì nhưng nhìn chung, nếu mô hình này thực sự cần thiết trong một cấu trúc gần như hoàn toàn là di sản.

Nhưng chúng tôi không có lựa chọn nào khác, và anh ấy không lắng nghe ai cả, anh ấy chỉ đưa ra một khung dịch vụ để chúng tôi có thể làm việc trên đó.

Vậy là, chúng ta bắt đầu xây dựng hệ thống hiện đại, siêu nhanh.

Các vấn đề bắt đầu: Khi giấc mơ trở nên khó khăn

Chúng tôi đã xây dựng một hệ thống thử nghiệm nhỏ và nó rất nhanh. Chúng tôi cảm thấy vui mừng và nghĩ rằng mình đã đưa ra lựa chọn đúng.

Mặc dù có đường cong học tập và sự chuyển đổi hoàn toàn về mô hình lập trình, nhưng chúng tôi đã quản lý để vượt qua.

Nhưng sau đó, khi chúng tôi bắt đầu xây dựng hệ thống thực tế cho sản xuất, đó là khi vấn đề bắt đầu.

• Gỡ lỗi là một cơn ác mộng. Mã được tạo thành từ những chuỗi toán tử rất dài. Khi có lỗi, thông báo lỗi rất khó hiểu. Thật khó để thấy vấn đề xảy ra ở đâu.
• Các công cụ khác không hoạt động tốt với nó. Chúng tôi đã sử dụng nhiều công cụ khác cho các vấn đề như bảo mật và dữ liệu. Chúng tôi phát hiện rằng những công cụ này không phản ứng. Chúng đã chặn. Khi chúng tôi sử dụng chúng, chúng đã phá vỡ thiết kế không chặn của hệ thống mới.
• Có những loại lỗi mới. Chúng tôi gặp phải những vấn đề rất khó tìm. Ví dụ, hệ thống sẽ dần dần sử dụng nhiều bộ nhớ hơn và sau đó bị treo. Chúng tôi không biết lý do tại sao.

Đội ngũ của chúng tôi đã ngừng xây dựng các tính năng mới. Thay vào đó, họ đã dành toàn bộ thời gian để cố gắng sửa những vấn đề khó khăn này.

Mã không chặn siêu nhanh và đẹp mà chúng tôi muốn giờ đây đầy rẫy các bản sửa lỗi phức tạp và chúng tôi đang mất rất nhiều thời gian cho nó.

Tôi không nói rằng lập trình phản ứng là xấu và nên tránh hoặc rằng nó không hoạt động. Điều tôi muốn nói là, đối với trường hợp này, nó không hề hợp lý chút nào. Đây thật sự là một cơn ác mộng mà không mang lại lợi ích kinh doanh thực sự cho dự án này.

Giải pháp: Một danh sách kiểm tra để giúp chúng ta chọn tốt hơn

Kinh nghiệm tồi tệ này đã dạy tôi một bài học quan trọng.

Bây giờ, khi tôi chọn công nghệ, tôi sử dụng một khung đơn giản để giúp tôi chọn công nghệ mới.

Điều này không phải là để ngăn chặn những ý tưởng mới.

Mà là để đảm bảo rằng chúng tôi chọn những ý tưởng mới một cách thông minh, phù hợp với từng mục đích.

Danh sách kiểm tra công nghệ

1. Nó có sẵn sàng và ổn định không?

• Phiên bản: Nó có phải là phiên bản ổn định (như 1.0 hoặc cao hơn)? Các phiên bản đầu tiên có thể thay đổi đột ngột. Hãy xem xét những thay đổi đột phá từ Spring AI M5 (phiên bản giai đoạn) đến phiên bản công khai cuối cùng 1.0.0 GA.
• Kỹ năng của đội ngũ: Đội ngũ của chúng tôi đã biết cách sử dụng nó chưa? Hay hoàn toàn mới đối với mọi người? Hãy xem xét đặc biệt về lịch trình và thời gian có sẵn khi xem xét điều này.
• Cộng đồng: Có một cộng đồng lớn người dùng không? Một cộng đồng tốt giúp sửa lỗi và trả lời câu hỏi.

2. Nó có hoạt động tốt với các công cụ khác của chúng tôi không?

• Tính tương thích: Các công cụ quan trọng khác của chúng tôi có hoạt động tốt với công nghệ mới này không?
• Tích hợp: Có dễ dàng kết nối với các hệ thống của chúng tôi cho việc giám sát, bảo mật và triển khai không?

3. Nó có dễ học không?

• Tài liệu tốt: Có tài liệu rõ ràng với các ví dụ tốt không? Nó có giải thích các vấn đề phổ biến không?
• Thời gian học: Mất bao lâu để đội ngũ của chúng tôi học nó một cách thành thạo?

4. Nó có phải là lựa chọn đúng cho dự án của chúng tôi không?

• Phù hợp: Công nghệ này có phải là giải pháp tốt cho vấn đề cụ thể của chúng tôi không? Hay chúng tôi chỉ nghĩ rằng nó thú vị?
• Thử nghiệm nhỏ: Chúng tôi có thể xây dựng một dự án thử nghiệm nhỏ trước không? Thử nghiệm này nên kiểm tra các phần rủi ro nhất.
• Kế hoạch dự phòng: Nếu nó không hoạt động, có dễ dàng chuyển sang công nghệ khác không?

Cách bạn có thể quyết định

Ngày nay, khi nghĩ về một công nghệ mới, hãy làm theo ba bước đơn giản:

1. Sử dụng danh sách kiểm tra: Đội ngũ cùng nhau hoàn thành danh sách kiểm tra.
2. Xây dựng một thử nghiệm nhỏ: Xây dựng một dự án thử nghiệm nhỏ để kiểm tra các phần nguy hiểm nhất.
3. Ghi lại quyết định: Ghi lại lý do đội ngũ chọn nó (cả kiến trúc sư và lập trình viên, CÙNG NHAU), những rủi ro là gì và cách chúng sẽ được quản lý.

Lời kết

Chọn công nghệ là quản lý rủi ro.

Cái Đẹp của các công cụ mới rất hấp dẫn, nhưng chúng có thể chưa trưởng thành và đầy rủi ro.

Cái Xấu của các công cụ cũ thì dự đoán được và an toàn.

Một kiến trúc sư giỏi hiểu cả hai.

Họ biết điều quan trọng nhất là hệ thống hoạt động tốt và đội ngũ có thể bảo trì nó.

Trong bài viết tiếp theo, chúng ta sẽ nói về cách thiết kế hệ thống có thể thay đổi dễ dàng, giống như xây dựng với các khối Lego.

Hẹn gặp lại các bạn!