Năm 2019, mình có học hỏi và áp dụng được nhiều thứ đã học/đọc vào trong cuộc sống, nhất là xây dựng tổ chức engineering. Mình thấy có cảm hứng khá tốt khi xây dựng được những bệ đỡ giúp các bạn trong team trở nên xuất sắc hơn và hiệu quả hơn.
Tiếp nối phần 1, phần này cũng trình bày một số chiêm nghiệm của mình trong năm qua dưới các khía cạnh truyền thông & cảm thông.
Truyền thông
Microservice là một khái niệm không mới (Bạn có thể xem bài nói chuyện của sư phụ Martin Fowler ở hội nghị GOTO 2014 ở đây). Gần đây mình rất bất ngờ khi đọc được nhận định sau:
The more I work with such architectures the more they feel that they are more about people and less about technologies. Actually “Microservices solve organizational problems and cause technical problems”. For sure they are not a free lunch.
Kiến trúc microservice quả thực có đất diễn khi giải quyết rất tốt việc độc lập phát triển các thành phần khác nhau của hệ thống khi tổ chức lớn lên. Nhưng cũng đồng thời, kiến trúc này tạo ra nhiều vấn đề kỹ thuật phải giải quyết khác, đặc biệt là networking communication (hay truyền thông).
Hình dưới sau cho ta một liên tưởng khá thú vị giữa con người và máy móc.
Sự liên tưởng trên làm mình thấm luật Conway trong phát triển microservice.
Ngẫm lại, phần mềm đa phần được viết ra cho con người sử dụng và phải theo quy trình mà chính tổ chức của chúng ta xây dựng nên. Quy trình nhìn ra thì không khác gì giao thức (hay protocol) là cách máy móc đang truyền thông cho nhau để làm việc cùng.
Vì vậy, xây dựng tổ chức làm việc hiệu quả phải đi kèm với việc xây dựng được cơ chế truyền thông hiệu quả. Các tổ chức lớn cần một framework để các team nhỏ (2-pizza team như Jeff Bezos đã xây dựng ở Amazon) có thể hoạt động độc lập (autonomy), tự xác định được cách truyền thông hiệu quả của họ (sync hay async).
Framework này theo mình có thể dựa trên OKR
Các bạn có thể đọc thêm các bài viết khá lý thú sau về vấn đề này:
- The Single Most Important Internal Email in the History of Amazon
- Spotify Squad framework
- Guide: Set goals with OKRs
Đồng cảm
“Empathy grows as we learn.” — Alice Miller
Càng làm trong công nghệ lâu năm, mình càng thấy rõ một điều: để thiết kế một hệ thống tốt, bạn cần có đủ hiểu biết để đồng cảm với các thành phần trong hệ thống của mình.
Việc đồng cảm ở đây, nghe có hơi lạ! Làm sao chúng ta có thể đồng cảm được với máy móc được? Nhưng xin để mình lấy ví dụ:
- Nếu bạn hiểu cách đĩa cứng (HDD) hoạt động, bạn sẽ thấy truy cập (read/write) tuần tự sẽ tốt hơn là truy cập ngẫu nhiên. Tính chất này nếu được khai thác đầy đủ, sẽ giúp các bạn lưu được thông tin trên đĩa cứng (không lo node crash bất thình lình) và vẫn đảm bảo performance. Ví dụ điển hình nhất là trong các storage engine dựa trên log-structured merge-tree hoặc trong việc lưu trữ log của Apache Kafka.
- Nếu bạn hiểu cách hệ điều hành (Operating System) hoạt động, bạn sẽ thấy quản lý memory rất quan trọng trong các ứng dụng server chịu tải cao. Bộ nhớ sẽ bị phân mảnh, thu hồi & tái sử dụng rất tốn kém. Việc dữ liệu được copy giữa application và kernel space nhiều khi tăng độ trễ trong việc gửi phản hồi cho client.
Việc đồng cảm này không phải tự nhiên mà có. Nó đòi hỏi chúng ta phải học hỏi, trải nghiệm & biết cách hệ thống hóa lại các tri thức của mình một cách khoa học.
“Trí tuệ trưởng thành trong tĩnh lặng. Tính cách hình thành trong giông bão”
Dưới góc độ tôn giáo, nếu luyện được một trái tim vô lượng, bạn có thể đồng cảm với mọi thứ và có hành xử thích hợp.
Phần 3, phần cuối cùng, các bạn có thể xem ở đây.
