Những bước đầu của microservices trên B2B SaaS

Nguyên nhân cũng như tiền đề, nếu sản phẩm Money Forward Cloud Accounting không được chuyển dịch sang microservices, các vấn đề sau có thể xảy ra: 

• Số lượng repositories của Cloud Accounting mà tăng lên, thì tốc độ phát triển phần mềm sẽ bị giảm xuống.
• Do liên tục bảo trì các repository trên, các Dev trói buộc vô một loại kỹ thuật duy nhất, nên không thể nâng cao tay nghề mình hơn.
• Ngoài ra, thời điểm đó Money Forward đang tiến hành microservices hoá toàn công ty, nên mình cũng được khuyến khích để thực hiện việc này (mọi người có thể xem dòng tâm tư khích lệ microservices hoá của CTO Nakade tại đây).  

Mình và đồng đội đã quyết định microservices hoá vì hai lý do:

• Muốn được mang lại nhiều giá trị hơn cho người dùng cuối.
• Giải phóng năng lực các Dev trong team, có cơ hội phát triển được tay nghề.

Tuy nhiên, dục tốc sẽ bất đạt, không thể nào lập tức đưa kế hoạch vô thực hiện ngay được.

Điều đặc biệt khó khăn chính là vấn đề tách size của service thế nào cho hợp lý, trong bài viết này mình sẽ giới thiệu các bạn về các vấn đề mà chúng mình đã từng xử lý. 

Mình đã tạo Data Flow Map trong luồng dữ liệu, và lý tưởng nữa thì có thêm Future Map. 

Thông qua việc trực quan hoá vấn đề, chúng mình đã tập hợp được các yếu tố cơ bản quan trọng để đưa ra quyết định, qua đó giúp chúng mình trở nên dễ dàng hơn trong việc quyết định xem việc cần làm tiếp theo là gì.

Ngoài ra, ưu điểm của trực quan hoá là có thể thu thập được feedback từ các nguồn khác nhau, qua đó dễ dàng đưa ra đề xuất về business requirement, nơi các Dev thường không thể tự quyết định được. 

Future Map khá giống Context Map, nhưng là map có liên quan đến system và DB, chúng mình đang dùng nó với cái tên là Future Map.

*Context map là một dạng trình bày trực quan sự tích hợp và phân chia của các nội dung trong hệ thống.  

Những giai đoạn đầu 2021, mình đã phỏng vấn nhiều người để hỏi xem loại service gì thì nên được phát triển trước, và mình đã vẽ ra cái map như thế để dùng.

Dưới đây là các đối tượng chính mà mình đã hỏi ý kiến

• Product owner
• Domain Expert (Chuyên gia có kiến thức về kế toán)
• Team engineer có liên quan

Do vừa phải kết hợp với các plan về phát triển chức năng mới của product, nên rất khó để áp dụng được Future Map và vẫn kết hợp được với các team service khác.

Vì có nhiều bên liên quan như vậy mà việc tạo Future Map rất cần thời gian. Nếu như có thể bảo đảm được việc tập hợp được các nhân viên liên quan trong thời gian ngắn thì việc có thể xong rồi, nhưng thực tế lại không như vậy.

Và Future Map đã ngốn từ 3 - 6 tháng để hoàn thành.

(Ngoài ra, cuối năm 2021 chúng mình cũng làm lại một bản edition để xem tính ảnh hưởng của nó như thế nào, qua đó có thể thấy được trong thực tế công việc đã làm được gì rồi và hiện đang tiến triển đến đâu).

Giải thích từ ngữ:

1. サービス:  Service
2. 外部サービ: External service
3. 凡例: Legend
4. 読み取り: Read
5. 書き込み:  Write
6. クラウド会計: Cloud Accounting

Qua hình trên, chúng ta có thể thấy được một cách sơ bộ structure của Future Map là như thế nào.

Tuy nhiên, nó lại trở nên quá trừu tượng đối với Data flow của các service khác.

Lúc đó mình nghĩ, nếu mình làm gì đó để đào sâu thêm tí, không chừng có thể ngộ ra gì đó mà trước đó mình chưa thấy.

Thế là, mình quyết định tạo sơ đồ Data flow.

Mục đích của sơ đồ này là để thông qua việc trực quan hoá luồng dữ liệu từ góc nhìn của các service khác nhau mà qua đó có thể phát hiện ra các vấn đề mà ở góc nhìn bao quát khó có thể nhận ra.

Dưới đây là các lợi ích có được từ sơ đồ Data flow của mình.

• Thấy được một phần luồng dữ liệu của use case level
• Có thể dùng nó để bàn luận sâu về đề tài như: có nên tạo Data trung gian hay không?
  • Tạo điều kiện cho buổi bàn luận được bàn một cách thực tế hơn về việc microservices nên được thiết kế như thế nào.
• Mình cũng có thể đối thoại với tất cả các bên liên quan (kể cả các thành viên không phải Dev) để bàn về việc nên config Pub/Sub thế nào để tốt hơn.
  • Lợi ích lớn nhất là có thể thông qua Future Map và data Flow chart mà bàn luận được vấn đề một cách trực quan hơn với các member không phải Dev. 

Giờ thì mình đã có thể sẵn sàng cho việc triển khai microservices rồi.

Tiếp đó, mình bắt đầu gửi các sơ đồ trên đến các team để lên bản thiết kế chi tiết.

Vậy nên, dù khi có vấn đề gì xảy ra, chúng mình vẫn có thể dễ dàng truy lại vấn đề, vừa không bỏ sót công việc trong công đoạn thực thi và chuẩn bị với các member liên quan. 

Lần này chúng mình đã tạo ra bản thiết kế dành cho microservices hoá, mình hy vọng sau này, đây cũng sẽ trở thành đề tài nghiêm túc đáng được cân nhắc để vận dụng vào công đoạn thiết kế cho bộ phận coding.

Cá nhân mình cho rằng bên BtoB SaaS còn tồn tại những vấn đề đặc thù của riêng nó do ranh giới giữa các context với nhau còn chưa rõ ràng.

Ngoài việc giải quyết các vấn đề đã đề cập, mình cũng muốn tiếp tục chinh phục với công việc trong công đoạn thiết kế để luôn tạo ra giá trị mới thông qua việc không ngừng đẩy nhanh tốc độ phát triển phần mềm.

Điều mình muốn nhấn mạnh là, microservices là phương thức chứ không phải là mục đích.

Có thể trong công ty của các bạn cũng đã có quyết định là sẽ thực hiện microservices hoá để đạt mục đích nào đó rồi, nhưng mình nghĩ điều quan trọng đầu tiên là phải xác định được chính mục đích này của mình.

Lời kết

Năm nay thì cũng đã tròn 1 năm chúng mình lòng vòng để kiếm cách config microservices rồi.

Cá nhân mình cũng đã đọc đủ loại tài liệu, liên hệ với người hiểu rõ về DDD, thu thập lời khuyên, và cũng tham gia nhiều buổi học các loại..v..v.

Qua việc này, mình cũng hiểu được là kiến thức về DDD có thể phát huy tốt không chỉ nằm trong công đoạn coding, mà việc dùng nó trong đợt này đã giúp mình có thêm nhiều sự tham khảo

Cảm ơn các bạn đã dành thời gian đọc bài viết này. 

Author: Chibicco từ MFC

Translator: Michael

Edit: Jim