Thông thường 1 service sẽ có 1 database, tối thiểu 1 pods, ngoài ra nó còn có thể đi kèm redis, kafka, hệ thống lưu logs và các kết nối đến service khác.

Trong phần lớn các trường hợp thì việc service gặp vấn đề thì sẽ có hệ thống cảnh bảo (alert manager). Tuy nhiên trong 1 số ít trường hợp, service bị gặp vấn đề (ví dụ 1 API bị hỏng) thì alert manager lại không hoạt động. Dẫn đến việc khắc phục bị chậm trễ (có thể là do khách hàng phát hiện ra thì mình mới biết) thì hậu quả để lại rất lớn.

Việc trace lại logs khi lỗi xảy ra cũng là vấn đề tương đối nan giải. Log có thể nằm phân tán ở nhiều server, hoặc thậm chị là đã bị xoá định kỳ rồi chẳng hạn.

Ban đầu thì nghĩ rằng mình có thể maintain tốt, sau rồi thì con người cũng dần lơ là, chủ quan đi. Thêm vào nữa là các nhân sự trong ngành IT này thay đổi liên miên. Dẫn đến có khi dev cũ nghỉ hết thì phải maintain dự án với hàng chục con server, hàng trăm mối liên kết thì quả là ác mộng.

Vậy nên mặc dù lý thuyết là micro services là hay đấy. Tuy nhiên trong thực tế thì phải hạn chế hết mức có thể, trừ khi không con cách nào khác (do yêu cầu nghiệp vụ, do yêu cầu của khách hàng hay do giới hạn về hạ tầng) thì mới phải tính đến micro services thôi em ạ.

Còn về bộ nhớ để setup pod trên k8s đó không phải vấn đề em ạ.