Viết code với LLM có đồng nghĩa với sự bùng nổ của Microservices?

Gần đây tại nơi làm việc, tôi nhận thấy sự khởi đầu của sự gia tăng các microservice. Dường như việc lập trình có sự hỗ trợ của LLM (Mô hình ngôn ngữ lớn) tự nhiên xu hướng chảy về phía các microservice nhỏ, mà hệ thống backend lớn sử dụng cho các nhiệm vụ cụ thể. Một ví dụ điển hình là một microservice chuyên xử lý các mô hình AI tạo ảnh và video.

Kiến trúc Microservices

Microservice: Hầm trú ẩn an toàn cho AI tái cấu trúc

Một microservice có phạm vi bề mặt được định nghĩa rất rõ ràng. Mọi thứ đi vào (yêu cầu - requests) và đi ra (phản hồi, webhooks) đều được xác định một cách rõ ràng. Điều này có nghĩa là bạn có thể để LLM thực hiện các hoạt động tái cấu trúc quy mô lớn mạnh mẽ bên trong service, và miễn là hợp đồng với thế giới bên ngoài vẫn giữ nguyên, nội bộ bên trong không còn quan trọng. Microservice có thể có cơ sở dữ liệu, bộ nhớ đệm (cache) và lưu trữ đối tượng riêng của nó, nhưng người gọi không cần quan tâm. Nó giống như một hầm trú ẩn (nơi bạn có thể kích hoạt "quả bom hình dáng Claude" của mình mà không gây ảnh hưởng ra bên ngoài).

Rủi ro tiềm ẩn trong Monolith so với Microservice

Khi viết code trong một mô hình đơn nguyên (monolith), bạn phải lo lắng về sự kết hợp (coupling) ngầm định. Thứ tự thực hiện công việc hoặc tên của một khóa cache có thể được một phần khác của monolith dựa vào một cách ngầm. Việc vượt qua ranh giới và rối rắm các phần của ứng dụng trở nên dễ dàng hơn rất nhiều. Tất nhiên, bạn có thể không làm những điều khó bảo trì này, nhưng đồng nghiệp của bạn có thể không "giàu đức" như vậy.

Một microservice có rủi ro bị kết hợp thấp hơn nhiều. Hãy để Claude làm bất cứ điều gì nó muốn, thế giới bên ngoài không quan tâm miễn là service tiếp tục hoạt động theo cùng một cách.

Góc độ tổ chức: Con đường ít sức kháng nhất

Từ góc độ tổ chức, có thêm những lý do khiến microservice trở thành con đường có sức kháng thấp nhất:

• Vì nằm trong một kho lưu trữ GitHub riêng biệt, việc xem xét Pull Request (PR) sẽ ít khắt khe hơn (hoặc bạn có thể commit trực tiếp vào nhánh chính - main), đồng nghĩa với việc bạn có thể lặp lại (iterate) nhanh hơn.
• Dữ liệu sản xuất và cơ sở hạ tầng có thể dễ tiếp cận hơn — thường thì cơ sở dữ liệu chính của môi trường sản xuất rất khó kết nối cho các kỹ sư hàng ngày, nhưng cơ sở hạ tầng của một microservice không được coi là quá quan trọng để bảo vệ chặt chẽ.

Hệ quả dài hạn

Sự gia tăng ồ ạt các microservice có thể tồi tệ và khó bảo trì hơn trong dài hạn. Khi bạn có hàng chục ứng dụng (tất cả đều có tài khoản thanh toán, thiết lập lưu trữ và tài nguyên riêng), sẽ rất dễ dàng quên gia hạn tài khoản API OpenAI mà chỉ microservice tạo ảnh được lưu trữ trên Vercel của bạn sử dụng.

Tuy nhiên, đây chính là nơi dòng chảy có sức kháng thấp nhất dẫn tới. Nếu bạn muốn áp dụng các phương pháp thực hành tốt hơn (best practices), bạn cần phải giúp mọi người đạt được kết quả mong muốn bằng các quy trình chuẩn đó một cách dễ dàng hơn so với việc họ tự tạo ra các microservice mới.