Liệu 2015 là năm của tiểu dịch vụ?

(PCWorldVN) Kiến trúc tiểu dịch vụ - microservices, xuất hiện năm 2014 vừa qua có thể mở đường cho sự bùng nổ ứng dụng web và phát triển ứng dụng di động. Năm nay, nhiều tổ chức sẽ nhận ra ích lợi của kiến trúc này.

• Làn sóng tiếp theo của điện toán doanh nghiệp
• 2014: Năm thành công của điện toán đám mây IBM
• Mở đường cho công nghệ điện toán đám mây
• Điện toán đám mây đến 2015: Kinh nghiệm của Intel

Ý tưởng tạo các ứng dụng sử dụng dịch vụ luôn luôn hấp dẫn. Tại sao phải lập trình từ đầu khi mà bạn có thể lắp ghép nhiều ứng dụng vào một dịch vụ mà chỉ cần thông qua các API? Miễn là những dịch vụ này đưa ra đúng và đủ, bạn có thể tận thưởng được những hiệu quả kinh tế nhờ quy mô mở rộng vô cùng như vậy.

Trước đây, nếu cố gắng tạo một ứng dụng như vậy sẽ tan thành mây khói ngay vì doanh nghiệp sẽ bị sa đà vào việc phát triển ứng dụng (nhất là với những xu hướng kiến trúc như CORBA và SOA). Nhưng một trong những khía cạnh thú vị nhất của tiểu dịch vụ (là những chương trình nhỏ, truy cập qua API và đơn năng) là chúng được sử dụng ở mức rất cơ bản, và được phát triển cho một mục đích mà thôi. Đây là lúc những dịch vụ kiểu này có chỗ đứng riêng.

Chia nhỏ dịch vụ lớn thành từng mảnh ghép dịch vụ nhỏ sẽ là xu hướng cho phát triển ứng dụng trong tương lai?

Ví dụ xác đáng nhất về tác động của kiến trúc tiểu dịch vụ là những gì mà Stefan Borsje, CTO và là đồng sáng lập công ty bán thiết bị hotspot Wi-Fi Karma, đăng trên blog của ông hồi năm ngoái. Theo Borsje, đội phát triển của ông đã đầu tư vào tiểu dịch vụ để phát triển cửa hàng trực tuyến Karma.

"Chúng tôi khởi đầu bằng một app lớn chạy ở nền, rồi chúng tôi chia nhỏ từng phần app đó ra… Khi cứ đi tới và xây dựng app này, chúng tôi trở nên quen thuộc với các vấn đề mà chúng tôi đang cố giải quyết, và khi càng quen thuộc hơn thì càng thấy rõ ranh giới giữa các mảnh ghép của một app. Mỗi lần chúng tôi gặp vấn đề gì thì vấn đề ấy rõ ràng là thuộc một mảnh ghép nào đó, và chúng tôi chuyển mảnh ghép ấy thành một dịch vụ. Đầu tiên, những mảnh ghép ấy rất lớn, nhưng khi nhìn theo hướng tiểu dịch vụ thì những mảnh ghép lại được chia nhỏ hơn, nhỏ hơn", ông Borsje nói.

Ví dụ, một app hoàn chỉnh về cơ bản là có một thành phần "cửa hàng", mà đội của Borsje chia nhỏ ra nữa thành quy trình xử lý đơn hàng, giao hàng, các dịch vụ theo dõi. Thậm chí giao diện ứng dụng cũng được chia nhỏ thành các dịch vụ. Theo Borsje, tách biệt chức năng thành các dịch vụ độc lập sẽ tăng đáng kể năng xuất chung, một phần vì các nhà phát triển không cần nhớ mọi thành phần của một ứng dụng nguyên khối trong đầu khi làm việc.

Đối với Karma, vấn đề lớn nhất ở đây với tiểu dịch vụ là khâu kiểm thử. Vì hành động và kết quả của từng mảnh ghép lại rất khác biệt nhau và khó xác định chính xác được nguyên nhân, kết quả. Vấn đề nào đó phát sinh từ một dây chuyền, nhưng là nằm ở mảnh ghép nào.

Martin Fowler, đồng tác giả của mô hình phát triển ứng dụng agile, hồi tháng 3/2014 đã đăng một bài giải thích thú vị về tiểu dịch vụ, và đến tháng 11/2014, ông diễn thuyết cách tiếp cận đa lớp để thử lỗi ứng dụng. Không có gì ngạc nhiên khi ông đề nghị thử lỗi theo từng mảnh ghép đơn lẻ nhưng ông nhắc nhớ là cho dù các mảnh ghép đơn lẻ đều chạy tốt thì không chắc toàn bộ ứng dụng sẽ chạy được. Ông đã vạch ra một loạt các phương cách về tích hợp, thành phần, tương tác, thử lỗi đầu-cuối để giúp các nhà lập trình xử lý được một trong những vấn đề gay cấn nhất của tiểu dịch vụ.

Một vấn đề khác là bạn không thể dự đoán được một tiểu dịch vụ nào đó, dưới điều kiện nào đó, có thể vượt quá chức năng gốc của nó. Chắc chắn là một lý do mà Karma triển khai nền tảng thương mại điện tử của họ trên AWS (Amazon Web Services), có thể tự động thu nhỏ, mở rộng quy mô nền tảng để đảm bảo không dịch vụ nào bị tình trạng nghẽn cổ chai. Một ứng dụng theo mô hình tiểu dịch vụ khác là Netflix cũng sử dụng nền tảng AWS. Nói cách khác, tiểu dịch vụ và điện toán đám mây "cặp kè" nhau. Về lý thuyết, bạn có thể tự tạo một đám mây riêng, tự động thu nhỏ/mở rộng quy mô, sử dụng VMWare hay OpenStack nhưng điều đó lại không thực tế.

Một công nghệ khác gần đây đang nổi lên dưới danh phận là tiểu dịch vụ: Docker, là công nghệ đóng gói ứng dụng và triển khai chúng trong các bộ chứa Linux (container). Rõ ràng là tiểu dịch vụ và Docker rất hợp với nhau, thêm một lý do nữa tại sao mọi dịch vụ đám mây lớn hiện nay đều hỗ trợ Docker.

Rõ ràng, không ai nói tiểu dịch vụ có thể giải quyết mọi vấn đề. Nhưng kiến trúc tiểu dịch vụ có thể thành công ở những nơi mà cách phát triển dịch vụ khác thất bại, bởi vì tiểu dịch vụ được phát triển từ gốc. Các nhà phát triển xác định loại dịch vụ và từng mảnh ghép riêng rẻ. Và khi xu hướng này lan mạnh trong khối doanh nghiệp lớn thì các đội phát triển ứng dụng có thể quyết định chọn dịch vụ nào là tốt nhất cho toàn tổ chức.

Điều rất quan trọng là các nhà phát triển phải viết ứng dụng theo cách cộng tác với nhau nhiều hơn, vay mượn nhiều hơn để tạo kiến trúc phần mềm từ gốc, không còn ngồi phân tích ứng dụng theo cách từ trên xuống.

Nhiều nhà phát triển trong các doanh nghiệp lớn đã triển khai kiến trúc tiểu dịch vụ. Khi đến thời của điện toán đám mây, cho dù là đám mây riêng hay đám mây dùng chung, thì kiến trúc tiểu dịch vụ không thể tăng được năng suất cho nhà phát triển, nhưng đây là cách mới để phát triển ứng dụng mà trước nay không thể làm được như vậy.