Cái gì sai với ứng dụng nguyên khối? (tiếp tục)
Quyết định liệu đi monolith-first hay microservices-first là một hành động cân bằng cái truyền thống giành chiến
thắng bởi nguyên khối. Tuy nhiên, trong các học phần này, tôi sẽ thể hiện cho bạn cung cấp cải tiến trong công
cụ hóa hiện đại và với cơ sở hạ tầng đám mây thuận tiện, rằng nó là quan trọng để xem xét đi microservices-first
hay ít nhất thúc đẩy tới kết thúc microservices trong dải màu (nhiều hơn về dải màu của các khả năng sớm).
Hầu hết sản phẩm nhìn chung cần phát triển và tiến hóa, và khi nguyên khối của bạn phát triển lớn hơn và có nhiều
đặc tính hữu dụng hơn, nó trở nên khó hơn để biện minh ném đi prototype ném đi. Nên, xuống con đường, bạn có thể
thấy bản thân bạn tắc với nguyên khối tại một thời điểm khi cái gì bạn thực sự cần là tính linh động, an ninh
và tăng quy mô của ứng dụng microservices.
Các nguyên khối đi với nơi chứa của các vấn đề tiềm tàng. Chúng luôn bắt đầu nhỏ và chúng ta luôn có ý định tốt
nhất giữ code sạch và tổ chức tốt. Một đội ngũ tốt các nhà phát triển có thể giữ một nguyên khối thanh lịch và tổ
chức tốt trong nhiều năm. Nhưng khi thời gian trôi đi, tầm nhìn có thể mất, hay đôi khi đã không có tầm nhìn mạnh
mẽ tại nơi đầu tiên. Tất cả code chạy trong cùng quá trình, nên không có các rào cản và không thứ gì dừng chúng ta
khỏi viết code lộn xộn lớn cái sẽ gần như là không thể chia ra sau này.
Nhân viên nghỉ việc có một tác dụng lớn. Khi các nhà phát triển rời đội ngũ, họ lấy đi kiến thức then chốt với chúng,
và họ được thay thế bởi các nhà phát triển mới người sẽ phải phát triển mô hình tư duy của bản thân họ về ứng dụng,
cái có thể dễ dàng so le với tầm nhìn gốc. Thời gian trôi đi, code qua tay nhiều lần, và lực đẩy tiêu cực này buộc
phát triển codebase thành cái gọi là một big ball of mud. Cái tên này chỉ ra rằng trạng thái lộn xộn của ứng dụng
khi không còn một kiến trúc có thể nhận thấy được.