Bảo vệ kiến trúc đơn giản (2022)

• Wave là công ty trị giá $1.7B (2,3 nghìn tỷ won) với 70 kỹ sư (cung cấp dịch vụ ngân hàng di động cho châu Phi)
• Sử dụng kiến trúc ứng dụng CRUD tiêu chuẩn: một Python monolith dựa trên Postgres
• Bắt đầu từ một kiến trúc đơn giản và giải quyết vấn đề trong khi giảm thiểu độ phức tạp, nhờ đó các kỹ sư có thể tập trung vào việc tạo ra giá trị cho người dùng
• Stackoverflow đã phát triển thành công bằng cách mở rộng một monolith đến mức được mua lại với giá 1,8 tỷ USD

Dù kiến trúc đơn giản hiệu quả, phần lớn truyền thông lại yêu thích kiến trúc phức tạp

• Ở các hội nghị công nghệ có rất nhiều bài nói về kiến trúc phức tạp dựa trên microservices, nhưng hầu như không có bài nào về monolith đơn giản
• Nhiều công ty dù chỉ có ứng dụng quy mô nhỏ vẫn bắt chước công nghệ phức tạp, rồi nhờ đó được chú ý tại các hội nghị và trên HN
• Kiến trúc chúng tôi dùng đơn giản đến mức thậm chí không cần phải vẽ sơ đồ kiến trúc

Cách duy trì sự đơn giản

• Wave dùng Python đồng bộ, nghĩa là tiến trình máy chủ sẽ bị chặn trong khi chờ I/O
• Họ từng thử các framework bất đồng bộ như Eventlet, nhưng có quá nhiều lỗi nên chi phí đó không đáng để đánh đổi lấy nỗi đau vận hành
• Thay vì tăng thêm độ phức tạp, các tác vụ cần thời gian chạy dài được tách ra xử lý qua hàng đợi
• Để tuân thủ quy định về lưu trú dữ liệu, ở một số quốc gia họ phải vận hành trung tâm dữ liệu on-premise
  • Senegal/Côte d’Ivoire dùng cloud, nhưng Uganda và các quốc gia khác cần on-premise vì quy định
  • Trong những trường hợp như vậy, kiến trúc đơn giản dễ xử lý hơn rất nhiều so với kiến trúc phức tạp

Tự xây thay vì mua

• Vì là đội ngũ ít người nên ban đầu họ ưu tiên mua phần mềm, nhưng khi không thể xử lý các lỗi nghiêm trọng thì họ phát triển công cụ riêng
• Tự xây công cụ là một dạng phức tạp mà họ không muốn gánh, nhưng ở một số nhóm sản phẩm, ngay cả sau khi khảo sát rất rộng họ vẫn không tìm được nhà cung cấp nào có sản phẩm phù hợp
• Đôi khi, ngoài năng lực cốt lõi, vẫn cần tự phát triển công cụ và duy trì chuyên môn nội bộ

Những lựa chọn đang được cân nhắc lại

• Họ đang cân nhắc lại các lựa chọn công nghệ như RabbitMQ, Celery, SQLAlchemy và Python, vì chúng làm tăng độ phức tạp hoặc gánh nặng bảo trì
• Nếu bắt đầu một codebase mới, họ sẽ cân nhắc cẩn thận các lựa chọn công nghệ này

Những lựa chọn họ hài lòng

• Họ hài lòng với các lựa chọn như GraphQL, giao thức truyền tải tùy chỉnh và Kubernetes
• GraphQL có các ưu điểm như tự tài liệu hóa, sinh mã và trình khám phá tương tác GraphiQL
• Họ cho rằng khi dùng GraphQL, ưu điểm lớn hơn nhược điểm
  • Ưu điểm
    • Tự tài liệu hóa cho kiểu dữ liệu trả về chính xác
    • Nhờ sinh mã cho kiểu trả về chính xác, phía client an toàn hơn
    • Tăng năng suất nhờ trình khám phá tương tác GraphiQL
    • Nhiều ứng dụng khác nhau (ứng dụng người dùng, ứng dụng hỗ trợ, ứng dụng đại lý Wave, v.v.) có thể dùng chung phần lớn một API, giúp giảm độ phức tạp
    • Với ngôn ngữ truy vấn có thể cấu hình, client có thể lấy đúng dữ liệu cần thiết chỉ trong một vòng packet round-trip mà không cần xây nhiều endpoint chuyên biệt
    • Loại bỏ việc tranh luận vụn vặt về điều gì được xem là RESTful API
  • Nhược điểm
    • Các thư viện GraphQL không thực sự tốt vào thời điểm họ áp dụng GraphQL
    • Cách mã hóa GQL mặc định bị lặp lại, và vì nhiều khách hàng dùng băng thông thấp nên họ rất quan tâm đến giới hạn kích thước
• Kubernetes được dùng để đáp ứng yêu cầu vận hành trung tâm dữ liệu theo từng quốc gia

Kết luận

• Bằng cách giữ kiến trúc ứng dụng đơn giản nhất có thể, họ có thể dành ngân sách cho độ phức tạp (và nhân lực) vào những nơi mà nó thực sự giúp ích cho doanh nghiệp
• Chính nhờ tư duy làm mọi thứ đơn giản nhất có thể trừ khi có lý do rất mạnh để tăng thêm độ phức tạp, họ đã xây dựng được một doanh nghiệp khá lớn với không nhiều kỹ sư, dù đang vận hành mảng tài chính châu Phi vốn thường được xem là một lĩnh vực khó

[secret3056]

Có vẻ như phải là "tự xây thay vì mua" chứ không phải "mua thay vì tự xây".

Một lĩnh vực khác là phần mềm mà chúng tôi đã phải tự xây dựng (thay vì mua).

[xguru]

À, tôi định nhấn mạnh điều đó nhưng lại khiến tiêu đề trở nên kỳ quặc. Tôi đã sửa lại rồi. Cảm ơn bạn.

[savvykang]

Có phải xu hướng thay đổi theo chu kỳ kinh tế không? Bất kể xu hướng ra sao, bắt đầu với monolith sẽ có lợi hơn về giảm chi phí cố định và bảo trì.

[aer0700]

Kiến trúc dễ hiểu thì cũng dễ bảo trì hơn.

[mhj5730]

Theo quan điểm của tôi, với bất kỳ dịch vụ nào thì bắt đầu bằng kiến trúc nguyên khối vẫn có vẻ tốt hơn. Nếu ngay từ đầu đã chọn MSA rồi lao vào thì chỉ tổ lãng phí tiền thôi.

[dhlee0305]

"Khi độ phức tạp tăng lên, chi phí (tiền bạc, con người, thời gian...) cũng tăng theo"
"Đừng cố giải quyết vấn đề có thể xử lý bằng kiến trúc đơn giản bằng một kiến trúc phức tạp."

[xguru]

Ý kiến trên Hacker News

• Lời khuyên kỹ thuật về microservices

  • Microservices không phải là chiến lược cải thiện hiệu năng, mà là chiến lược giảm chi phí tiềm năng và điều phối kỹ thuật.
  • Giữa ứng dụng monolithic có thể mở rộng theo chiều ngang và microservices không có khác biệt lớn, trừ khi bạn muốn thu nhỏ một chức năng cụ thể.
  • Với ứng dụng monolithic, không thể chỉ thu nhỏ riêng một phần của ứng dụng.
  • Việc tiết kiệm chi phí chỉ bắt đầu có ý nghĩa ở quy mô lớn và cần ít nhất 3 bản sao.
  • Ở hầu hết các công ty, lợi ích thực tế nằm ở việc điều phối kỹ thuật.
  • Với monolith có một kho lưu trữ duy nhất, một nhóm có thể sở hữu và quản lý, nhưng với shared monolith thì không ai thực sự sở hữu nên rất khó quản lý.

• Các buổi nói chuyện về microservices

  • Ở các hội nghị công nghệ tổng quát, đã có nhiều bài trình bày về độ phức tạp và tác dụng phụ của kiến trúc microservices, nhưng không có bài nào về việc xây dựng monolith đơn giản.
  • Bài nói của David Schmitz về các mẹo để thất bại với microservices rất ấn tượng, và phong cách trình bày hài hước của ông rất cuốn hút.

• Thiên kiến nhận thức và sự đơn giản

  • Mọi người thường tập trung vào việc thêm thứ gì đó vào, và bỏ qua các giải pháp đơn giản.
  • Nghiên cứu cho thấy giải pháp tốt hơn là giải quyết vấn đề bằng cách bỏ bớt gạch Lego thay vì thêm vào cấu trúc.

• Over-engineering và thiếu kinh nghiệm

  • Kiến trúc nên "đủ đơn giản nhưng cũng đủ phức tạp khi cần", nhưng để làm được điều đó cần có kinh nghiệm.
  • Ngành IT có xu hướng thiếu kinh nghiệm, và kinh nghiệm thì cần thời gian mới tích lũy được.
  • Các kỹ sư và quản lý thiếu kinh nghiệm thường dùng những công nghệ hoặc chỉ số không cần thiết.

• Công ty coi trọng cân bằng công việc và cuộc sống

  • Đang tìm một công ty muốn tập trung cải thiện sản phẩm và dành phần thời gian còn lại cho cuộc sống cá nhân.

• Trải nghiệm cá nhân với Dan Luu

  • Dan Luu rất hào phóng trong việc tương tác với người hâm mộ blog và có chuyên môn sâu về ranh giới giữa phần mềm và phần cứng.
  • Ông rất rộng rãi trong việc chia sẻ góc nhìn và chuyên môn của mình, và học hỏi từ ông là một trải nghiệm rất thú vị.

• Tầm quan trọng của kiến trúc đơn giản

  • Trong hầu hết các trường hợp, kiến trúc cần thiết là những thành phần cơ bản như load balancer hỗ trợ SSL, nhiều app server, cơ sở dữ liệu sharding, message queue, v.v.

• Kiến trúc và cấu trúc xã hội của đội ngũ kỹ thuật

  • Kiến trúc nên phản ánh cấu trúc xã hội của đội ngũ kỹ thuật; nếu không tính đến điều này, có thể dẫn đến hỗn loạn và kém hiệu quả.
  • Kho mã monolithic quy mô lớn và kiến trúc đơn giản có thể khó quản lý, và ngay cả những công ty như Google và Meta cũng tự phát triển rất nhiều công cụ nội bộ.
  • Kiến trúc có thể hỗ trợ hoặc cản trở sự cộng tác giữa các nhóm, nên ban lãnh đạo kỹ thuật cần cân nhắc điều này.

• Sự ưu tiên cho kiến trúc đơn giản

  • Kiến trúc đơn giản và monolith phù hợp trong phần lớn trường hợp, nhưng cần cẩn thận để tránh các vấn đề do synchronous I/O gây ra.
  • Bug về tính toàn vẹn dữ liệu là vấn đề quan trọng cần tránh trong các hệ thống tài chính.

[dangyup]

Có thể cho tôi xin liên kết tới bài thuyết trình nói về các mẹo của David Schmitz về những thất bại của microservices được không.

[xguru]

Đây là https://www.youtube.com/watch?v=r8mtXJh3hzM