Cụ thể hơn, microservices là các ứng dụng và hệ thống tự trị có một mục đích duy nhất và đó là chìa khóa. Chúng không bao giờ có nhiều hơn một mục đích và điều đó có nghĩa là chúng có thể được thiết kế để thực hiện một cách cực kỳ tốt một dịch vụ mà không cần các thỏa hiệp thông thường khi phát triển các ứng dụng đa chức năng. Điều này làm cho chúng hữu ích và có lợi theo nhiều cách. Ví dụ, các hệ thống kiểu nguyên khối thường quy định loại công cụ cần thiết để xây dựng và duy trì chúng. Những công cụ đó thường là những công cụ kiểu mẫu số chung thấp nhất, với khả năng phù hợp với một số loại cơ sở mã và nền tảng thử nghiệm. Trong một ứng dụng microservices, công cụ tốt nhất cho chức năng cụ thể đó có thể được xác định và sử dụng, dẫn đến việc phát triển, thử nghiệm và triển khai mã chất lượng cao hơn.

Sử dụng cách tiếp cận MSA cũng có thể giúp dễ dàng hơn trong việc bảo trì, duy trì và mở rộng các ứng dụng và hệ thống. Trái ngược với các hệ thống nguyên khối, nơi mà một thay đổi có thể vô tình cộng hưởng thông qua một số chức năng và cơ sở mã bị tàn phá, microservices cho phép thay đổi chính xác đối với cơ sở mã nhẹ được khép kín. Điều này có những lợi ích, bao gồm:

+  Tính linh hoạt: Thêm hoặc bớt các chức năng khi cần thiết trong thời gian gần thực tế;

+  Khả năng đáp ứng: Đáp ứng các yêu cầu thay đổi của người dùng một cách nhanh chóng và hiệu quả;

+  Khả năng bảo trì: Sửa chữa mã và nâng cấp phiên bản giới hạn cho một dịch vụ duy nhất;

+  Khả năng mở rộng: Thêm chức năng nhanh chóng và tăng dần

Microservices cũng đã giới thiệu một thay đổi quan trọng nhưng mang nhiều sắc thái đối với các phương thức phát triển sẽ phát triển theo thời gian: khả năng tái sử dụng so với khả năng thay thế. Đây là một sự phá vỡ so với các thực hành thông thường xung quanh việc làm việc với các hệ thống nguyên khối cũ và các hệ thống dựa trên SOA gần đây hơn. Do chi phí (nguồn lực, thời gian, ngân sách) liên quan đến việc phát triển mã, một tư duy được phát triển xung quanh việc làm cho mã có thể tái sử dụng nhiều nhất có thể. Điều này có những ưu điểm rõ ràng - chẳng hạn như có thể sử dụng cùng một bộ mã cho nhiều mục đích; và khuyết điểm - chẳng hạn như phát triển mã đủ tốt để làm tốt một số việc nhưng không tuyệt vời một thứ. Tuy nhiên, với microservices và các công nghệ phát triển đã phát triển xung quanh nó, giờ đây việc sao chép và thay thế mã hiệu quả và hiệu quả hơn là cố gắng sử dụng lại những gì tồn tại. Sự rời rạc của các dịch vụ vi mô ngăn cách một dịch vụ với các dịch vụ khác, cho phép phát triển nhanh hơn và “an toàn hơn” cho phép khả năng thích ứng nhanh chóng với các nhu cầu kinh doanh đang thay đổi. Nó cũng có lợi ích phụ là liên tục đưa mã và kỹ thuật mã hóa hiện đại vào một cơ sở mã.

Điều đó nói rằng, microservices không phải là câu trả lời cho mọi thứ và mọi hoàn cảnh. Một trong nhiều lý do mà các ứng dụng kiểu nguyên khối đã tồn tại là mặc dù lớn, nhưng chúng là một dấu ấn phát triển duy nhất. Điều đó có nghĩa là ít chi phí triển khai hơn và ít phối hợp hơn với các nhóm phát triển khác. Nó cũng thường có nghĩa là ít tốn kém và nỗ lực hơn để bắt đầu các dự án thay đổi, vì sau khi nó được tải vào máy của nhà phát triển, họ có quyền truy cập vào trải nghiệm ứng dụng đầy đủ hơn là chỉ một lát. Điều đó không đúng với microservices, nơi nó có thể yêu cầu tải một số dịch vụ rời rạc để có được cảm giác đầy đủ về ứng dụng và mỗi microservice có thể (hoặc không) có một phương pháp triển khai khác nhau. Mỗi nhóm phát triển có trách nhiệm quyết định cách tiếp cận nào là tốt nhất cho tình huống và tổ chức cụ thể của họ.

Cuộc thảo luận lớn nhất xung quanh sự phát triển của microservices hiện nay là: "nhỏ như thế nào là quá nhỏ?" Tương đối dễ dàng xác định các ứng dụng quá lớn và quá phức tạp để bảo trì và cập nhật một cách hiệu quả. Việc phân rã các ứng dụng nguyên khối thành các thành phần microservice có kích thước vừa phải là câu hỏi của Goldilocks. Các ứng dụng phải bắt đầu giống với cấu trúc của các nhóm phát triển Agile hiện đại - quy mô nhỏ và tập trung, không có dấu chân hoặc chức năng dư thừa. Một cách khác để nghĩ về nó là từ quan điểm duy trì so với dịch vụ. Ứng dụng càng dễ duy trì (thay đổi, cập nhật, thay thế, v.v.) thì dịch vụ càng tốt trên giao diện người dùng cho khách hàng cuối cùng, ít nhất là trên lý thuyết.

Nói một cách rõ ràng, cách tiếp cận Kiến trúc Microservice là một phương pháp đang phát triển trong phát triển phần mềm. Do đó, không có - ít nhất là chưa có - một sách hướng dẫn tiêu chuẩn để tuân theo khi thực hiện cách tiếp cận như vậy. Tuy nhiên, điều thực sự quan trọng và điều gì có thể là điểm quyết định mang tính định hướng lúc này, là lợi ích thu được so với nỗ lực đạt được. Nhìn chằm chằm vào khái niệm, hỏi và trả lời câu hỏi như lợi ích của việc tách ứng dụng này thành hai, ba hoặc nhiều phần hơn là gì? Những công cụ hiện đại nào có thể được tận dụng để tạo ra một ứng dụng tốt hơn? Những vấn đề tích hợp nào có thể được cải thiện với cách tiếp cận microservices? Đây chỉ là một số lưu ý khi xem xét cách tiếp cận ứng dụng microservices.