Nhà kiến trúc là ai?
Trong nghành phần mềm, từ “kiến trúc” thường gợi nên cái gì đó huyền hoặc và mạnh mẽ. Nó kiến chúng ta liên tưởng đến những quyết định trọng đại và những kỹ thuật đỉnh cao. Và người kiến trúc sư phần mềm thường đường tưởng tượng đến như những người đứng tại đỉnh cao công nghệ.
Nhưng cuối cùng, thì cái tay kiến trúc sư ấy làm việc gì?
Đầu tiên thì, hắn ta là một lập trình viên và sẽ tiếp tục là một lập trình viên. Đừng có bao giờ tin rằng kỹ sư kiến trúc nghĩa là đứng đằng sau chuyện viết code hay tập trung vào những vấn đề cấp cao gì. Họ không! Họ, trước đơn thuần là những lập trình viên giỏi nhất, và họ sẽ tiếp tục nhận task, trong khi vẫn hướng dẫn phần còn lại của nhóm phát triển hướng đến thiết kế có hiệu suất cao nhất.
Họ có thể không viết quá nhiều code như những người khác, nhưng họ vẫn dính líu thôi. Họ đơn giản là không thể nào làm tốt được công việc (thiết kế) của mình nếu không kinh qua những vấn đề mà chính mình tạo ra cho những lập trình viên khác.
Kiến trúc là gì?
Kiến trúc của phần mềm là một loạt các đường kẻ được vạch ra trên hệ thống phần mềm. Các đường kẻ đó chia tách hệ thống thành các component, sắp xếp vị trí của chúng, và định hình nên cách các component đó giao tiếp với nhau.
Mục tiêu của việc kẻ các đường biên đó là để điều phối các hoạt động phát triển, deploy, vận hành, và bảo trì hệ thống phần mềm được bao bởi các đường biên đó, làm sao cho giữ được càng nhiều càng tốt các tùy chọn có thể được quyết định được sau này càng tốt.
Điều đáng ngạc nhiên ở đây là việc kiến trúc lại không phải là nhằm vào mục tiêu giúp cho hệ thống hoạt động tốt. Dĩ nhiên ưu tiên quan trọng nhất của phần mềm là nó phải hoạt động tốt, nhưng sự thật là kiến trúc của phần mềm can dự rất ít vào đó. Vẫn có những phần mềm với kiến trúc rất tệ hại nhưng hoạt động ổn. Thay vào đó các vấn đề có xu hướng xảy ra quanh hoạt động deploy, vận hành, bảo trì hay phát triển của phần mềm.
Kiến trúc vẫn hỗ trợ cho sự hoạt động đúng đắn của phần mềm, nhưng theo một cách thụ động và tô điểm thêm. Kiến trúc không đóng vai trò cốt lõi ở khía cạnh đấy. Trên thực tế, kiến trúc hỗ trợ rất ít trong việc hỗ trợ cho các quyết định về mặt hành vi được uyển chuyển. Thay vào đó, kiến trúc nhắm vào hỗ trợ cho vòng đời lâu dài của phần mềm, làm sao cho hệ thống dễ hiểu, dễ phát triển, dễ bảo trì, dễ deploy, thông quá đó giảm tối thiểu chi phí phát triển và tối đa hóa hiệu suất của các lập trình viên.
Dễ deploy
Để có thể được sử dụng, phần mềm cần được deploy. Chi phí bỏ ra cho deploy càng lớn thì phần mềm càng kém hữu dụng. Nhà kiến trúc, theo đó, sẽ đặt mục tiêu sao cho hệ thống có thể được dễ dàng delpoy chỉ với một thao tác duy nhất.
Điều không may là các chiến thuật deploy thường ít được suy tính đến vào những giai đoạn đầu tiên của dự án phần mềm. Nhà kiến trúc có xu hướng dẫn hệ thống tới trạng thái “dễ phát triển, nhưng rất khó de loy”.
Chẳng hạn, nhà thiết kế bay bổng nào cũng thích ý tưởng về cả một đám mây các micro service bay vòng quanh trong đầu. Cách tiếp cận đó có thể giúp cho việc phát triển trở nên dễ dàng về mặt nào đó – bởi đường biên kiến trúc giữa các component rất dày, và giao diện tương tác khá ổn định. Nhưng một kiến trúc như thế cũng sẽ kéo theo rất nhiều chi phí xoay quanh việc cấu hình, kết nối, xử lý lỗi… Đó sẽ là một cực hình cho những ai đảm nhiệm thao tác deloy.
Vậy nên, nhà kiến trúc phải cân nhắc sớm các vấn đề của deployment. Cụ thể, họ nên ra quyết định làm sao cho hệ thống ít service hơn, và nhiều component tích hợp hơn, như một phép lai giữa service và component nội tiến trình.
Hoạt động của hệ thống
Ảnh hưởng của kiến trúc lên hiệu năng vận hành không lớn như ảnh hưởng của nó tới khả năng phát triển, bảo trì hay deploy. Gần như bất kỳ vấn đề nào liên quan đến khả năng vận hành cũng đều có thể giải quyết được bằng cách tăng cấu hình phần cứng mà không phải chịu ảnh hưởng nghiêm trọng nào từ kiến trúc cả.
Điều đó xảy ra liên tục. Kiến trúc kém về mặt hiệu năng có thể được bù đắp một cách đơn giản bởi bộ xử lý mạnh hơn, nhiều bộ nhớ hơn, nhiều máy chủ hơn. Phần cứng rẻ, còn con người thì đắt đỏ. Vậy nên nỗ lực cho kiến trúc không có giá bằng nỗ lực dành ra cho khâu phát triển, vận hành và bảo trì.
Không có nghĩa rằng tinh chỉnh kiến trúc để cải thiện hiệu năng là việc làm vô ích. Điều đó vẫn có giá trị. Chẳng qua là chi phí sẽ được phân bổ cho các khía cạnh khác nhiều hơn mà thôi.
Một cách phát biểu tốt hơn đó là kiến trúc giúp cho các hoạt động của hệ thống trở nên rõ ràng trong mắt các nhà phát triển. Nó tiết lộ sự hoạt động. Kiến trúc đẩy các ca sử dụng cùng các tính năng và hành vi của hệ thống hiển hiện trên các thực thể lớp đầu – những điểm mốc dễ dàng được nhìn thấy trong mắt nhà phát triển. Điều này giúp đơn giản hóa hiểu biết về hệ thống và do đó rất có ích trong phát triển và bảo trì.
Bảo trì
Trong tất cả các khía cạnh của một hệ thống phần mềm, bảo trì là hoạt động tốn kém nhất. Trong đó, chi phí chủ yếu rơi vào hoạt động thăm khám để tiên lượng và ra quyết định, cũng như chi phí trả cho các rủi ro phát sinh.
Kiến trúc được xây dựng cẩn trọng giảm thiểu những chi phí đó. Nó chia tách hệ thống thành các component, cô lập những component đó qua những giao diện ổn định, hiển hiện các hoạt động, mở cửa với lộ trình thay đổi trong tương lai, và giảm nguy cơ gặp lỗi khó lường.
Giữ khả năng lựa chọn
Một kiến trúc tốt sẽ giúp tối đa hóa số lượng các quyết định lựa chọn không cần thiết phải đưa ra sớm.
Phần mềm mang hai giá trị bên trong nó: giá trị từ hành vi hoạt động của nó, và giá trị của cấu trúc của nó. Giá trị thứ hai to lớn hơn, bởi nó khiến cho phần mềm mềm.
Phần mềm được phát minh là bởi nhu cầu nhanh chóng và dễ dàng thay đổi hành vi của một cỗ máy. Nhưng khả năng đó phụ thuộc nặng nề vào các đường nét thiết kế của hệ thống. Để phần mềm được mềm, chúng ta phải làm sao để giữ cho càng nhiều các lựa chọn có thể được quyết định về sau, càng lâu càng tốt. Những thứ gì cần phải giữ được khả năng lựa chọn? Chính là những chi tiết không chính yếu trong hệ thống.
Phần mềm nào cũng có thể được gom thành hai thành phần chính: các chính sách, và các chi tiết cụ thể. Các chính sách chứa đựng tất cả các quy tắc nghiệp vụ và thủ tục. Chính sách là giá trị thực của hệ thống.
Bên cạnh đó, các chi tiết là những thứ cần thiết để con người, các hệ thống khác, lập trình viên… có thể tương tác với chính sách. Nhưng các chi tiết không gây ảnh hưởng đến sự hoạt động của các chính sách. Các thiết bị vào ra, cơ sử dữ liệu, hệ thống web, máy chủ, framework, giao thức… là những chi tiết như thế.
Mục tiêu của kiến trúc là kẻ các đường nét cho hệ thống phần mềm sao cho nổi bật các chính sách như những phần tử cốt lõi của hệ thống trong khi giữ cho các chi tiết trở nên không cần thiết đối với sự hoạt động của khối chính sách đó. Điều này cho phép trì hoãn các quyết định về các chi tiết. Lấy ví dụ:
- Không cần thiết phải ra quyết định về DB trong thời điểm ban đầu của hệ thống. Các chính sách không quan tâm đến nhãn hiệu cơ sở dữ liệu, quan hệ hay không quan hệ, phân tán hay không phân tán, phân cấp hay không, thậm chí có phải là DBMS hay không hay chỉ đơn giản là dữ liệu file.
- Không cần thiết phải lựa chọn web server sớm. Các chính sách thậm chí còn không nhận thức được nó sẽ được giao tiếp thông qua web hay không
- Không cần thiết phải chốt áp dụng REST sớm, tương tự như thế với những thứ như micro service framework, hay SOA framework…
- Không cần thiết phải chốt DI framework, bởi các chính sách không quan tâm về cách các mối phụ thuộc được giải quyết
Nếu chúng ta có thể phát triển các chính sách cấp cao mà không phải ra quyết định về các chi tiết liên quan, chúng ta sẽ có khả năng trì hoãn việc ra quyết định trong một thời gian dài. Càng trì hoãn được lâu, chúng ta sẽ có càng nhiều thông tin để có thể quyết định chính xác.
Kết luận
Một kiến trúc tốt sẽ phân tách cẩn trọng các chi tiết ra khỏi các chính sách, và gỡ các chính sách khỏi sự phụ thuộc vào các chi tiết. Bằng cách đó các chính sách không chứa tri thức về các chi tiết, vậy nên chúng không phụ thuộc vào các chi tiết theo bất kỳ cách nào. Vậy là các quyết định về các chi tiết có thể được trì hoãn trong thời gian tối đa cho phép.
