(Bài dịch đã được sự đồng ý từ tác giả)

Đọc phần 1 tại đây

Phương pháp tối ưu để chuyển hướng sang kiến trúc Microservices

Việc cô lập các microservices giúp cho chúng đáp ứng được nhu cầu thay đổi nhanh chóng của hệ thống, Tuy nhiên nó đòi hỏi cần được cô lập ở các level: : 

Runtime Processes: Đây là điều rõ ràng nhất và cũng được thay đổi trước tiên, không còn một vài mà là rất nhiều processes  khi triển khai microservices. Những thứ mà bạn phải đối mặt chính ở đây là áp dụng một số bài toán của distributed computing –  những thứ mà rất khó để triển khai hiệu quả: container hoá, event architecture, http management, service meshes, and circuit breakers.

Team/Văn hóa: Nếu các nhóm quá tách biệt và tự chủ sẽ dẫn đến khó khăn trong giao tiếp và làm việc cùng nhau. Điều này còn có thể là nguyên nhân của “knowledge silos” và làm trùng các task giữa các team với nhau. Để giải quyết điều này, bạn có thể tìm đọc quyển: Programming as Theory Building của Peter Naur.

Dữ liệu: Tác động lớn nhất của việc áp dụng distributed computing như microservice nằm ở cách nó ảnh hưởng đến dữ liệu của bạn. Bạn phân vùng dữ liệu của mình dưới một số hình thức và sau đó cần integrate lại dữ liệu ở cấp hệ thống. Điều này sẽ mang lại cho bạn một số lợi ích khá thú vị liên quan đến việc scaling. Tuy nhiên, nó cũng cần nhiều sự đầu tư hơn so với hướng tiếp cận đơn giản của Monolithic tới  kiến trúc dữ liệu. (David Dawson)

 

Lựa chọn công nghệ cho từng microservice cụ thể

Đây là chủ đề mà tôi biết sẽ có rất nhiều ý kiến trái chiều nhau..

Một mặt, mọi người cho rằng việc sử dụng công nghệ và ngôn ngữ lập trình nào không quan trọng cho lắm.

“Hầu như mọi vấn đề đều có thể được giải quyết với bất kỳ công nghệ nào. Mọi người  có vẻ đang dành quá nhiều thời gian để tìm ra một công nghệ phù hợp. Thay vì thế chúng ta hãy cứ bắt đầu với một công nghệ nào đó, sau đó phân tích và đánh giá dựa trên cách nó hoạt động để đưa ra thay đổi phù hợp. Làm như thế nhiều lần, bạn sẽ dễ dàng chọn lựa công nghệ và tránh đưa ra những quyết định không chính xác.” Andras Fincza, Vice President of Engineering tại Emarsys

“Hầu hết những ngôn ngữ hiện đại ngày nay (Python, Java, C++, Node/JavaScript) đều nhanh và có khả năng scale như nhau. Bởi vậy cho nên việc sử dụng ngôn ngữ nào không phải là điều quá quan trọng. Mỗi ngôn ngữ đều có ưu và nhược điểm riêng, và mọi người thường có xu hướng lựa chọn ngôn ngữ theo sở thích cá nhân thay vì đặc tính kỹ thuật của chúng” Viktor Tusa.- DevOps Engineer tại LogMeIn

Dành quá nhiều thời gian lựa công nghệ là việc thực sự không cần thiết bởi sự khác biệt mà nó đem lại không đáng kể.

“Tầm quan trọng của việc lựa chọn công nghệ đang bị đánh giá quá cao. Trừ khi bạn quan tâm nhiều đến chi phí hoạt động, còn không thì đừng đầu tư quá nhiều thời gian vào nó” Andras Fincza.

“Nếu đó là một dự án mới, tôi sẽ dùng ngôn ngữ được các lập trình viên trong team biết đến nhiều nhất. Nếu đó không phải là dự án mới thì tôi sẽ lựa chọn ngôn ngữ có độ bao phủ tốt nhất với các sản phẩm trong hệ thống của khách hàng.” Viktor Tusa nói.

“Một trong những điểm hay ho của microservice là nó sẽ luôn được gói gọn trong một microservice và sẽ giao tiếp với bên ngoài thông qua interface. Tôi thực sự không quan tâm tới những thứ khác, miễn là microservice đó có interface.” Steven McCord

Lựa chọn công nghệ phù hợp dường như không chỉ là một câu hỏi về technical mà còn liên quan đến các quyết định tuyển dụng. 

Nếu bạn chọn một kiến trúc với 10 ngôn ngữ lập trình khác nhau, bạn cần đảm bảo rằng nhóm của bạn có thể xử lý điều đó.

“Tôi không khuyến khích bạn dùng quá nhiều ngôn ngữ lập trình vì nó sẽ khiến việc tuyển dụng developer trở nên khó khăn hơn. Ngoài ra, việc thay đổi  ngôn ngữ lập trình thường xuyên sẽ làm giảm tốc độ làm việc của developer.”  – Robert Aistleitner, VP of Engineering tại Usersnap

“Bạn cần hình dung được kiểu development team mà mình muốn xây dựng. Nếu bạn muốn sử dụng nhiều ngôn ngữ khác nhau, bạn cần lựa chọn những kỹ sư năng động có khả năng học hỏi nhanh nhiều ngôn ngữ cùng lúc.” Steven McCord

 

Một số công nghệ đề xuất

“Tôi rất khuyến khích sử dụng các dịch vụ được quản lý như AppEngine trong Google Cloud Platform. Nó sẽ hỗ trợ bạn được kha khá việc. Ngoài ra, khi lựa chọn ngôn ngữ/công nghệ/framework, bạn cần chọn chính xác ngôn ngữ phù hợp với microservice đang dùng. Đừng sử dụng mãi một ngôn ngữ chỉ vì lâu nay bạn vẫn dùng nó.” Csaba Kassai, Lead Developer tại Doctusoft.

Mặt khác, một số nhà lãnh đạo công nghệ cho rằng có một số công nghệ sẽ phù hợp với một số microservice nhất định. Vậy nên, khi chọn công nghệ cho một microservice, bạn cần cân nhắc đến các vấn đề như:

• Bảo trì
• Khả năng chịu lỗi (fault-tolerance)
• Khả năng mở rộng (scalability)
• Chi phí cho kiến trúc
• Dễ deploy

Một số ví dụ về framework/công nghệ mà nhóm Brujio sử dụng cho microservice:

• Scrapy để thu thập dữ liệu web
• Celery  + RabbitMQ để liên lạc với các dịch vụ siêu nhỏ
• NLTK + Tensorflow (và một số thứ khác) trong phần Machine Learning
• AWS services

Tham khảo thêm: Case study cho việc lựa chọn công nghệ cho cloud-based app. 

 

Lựa chọn công nghệ phù hợp

Bạn cần cân nhắc nhiều vấn đề khi lựa chọn ngôn ngữ lập trình/công nghệ cho microservice của mình.

Một trong những điều quan trọng cần làm là đánh giá năng lực của đội ngũ kỹ sư hiện có và  khả năng hỗ trợ về tool, community của các ngôn ngữ/công nghệ mà bạn dự định sử dụng. Theo kinh nghiệm của tôi, các công ty có xu hướng chọn ngôn ngữ lập trình dựa theo năng lực của đội ngũ kỹ sư mà họ đang sở hữu “- Csaba Kassai, Lead Developer tại Doctusoft

Hãy sử dụng loại công nghệ cung cấp nhiều hỗ trợ ngoài (resources và community). Chẳng hạn, với Ruby và JavaScript, bạn sẽ nhận được nhiều hỗ trợ từ phía cộng đồng khi có vấn đề xảy ra. Tôi cho rằng việc lựa chọn ngôn ngữ không phải là một vấn đề lớn, điều quan trọng hơn là bạn cần chắc chắn ngôn ngữ đó đang được đông đảo người sử dụng. Bởi ngay cả khi nhóm kỹ sư của bạn chưa đáp ứng được các yêu cầu về mặt kiến thức, bạn vẫn có thể tận dụng nguồn lực từ cộng đồng.  –  Varun Villait, CEO tại Industry

Một yếu tố khác cần cân nhắc là các thư viện hiện có của ngôn ngữ có thể tận dụng để đẩy nhanh tiến độ dự án. Ngôn ngữ mà bạn cho là tốt có thể không có các thư viện nhất định mà bạn sẽ cần tới trong tương lai,  buộc bạn phải dành thời gian tự xoay xở và tìm hướng giải quyết. Khả năng chịu lỗi và scaling hiển nhiên cũng là một yếu tố quan trong. Nếu bạn phải viết lại một cái gì đó từ đầu trong một vài tháng kể từ bây giờ chỉ vì sự lựa chọn ban đầu của mình, có lẽ bạn nên nghĩ tới 1 sự lựa chọn khác. Tôi nghĩ mọi lựa chọn về công nghệ nên dựa trên tình hình  cụ thể của team và các khoản chi mà công ty sẵn sàng đầu tư – Greg Neiheisel, Co-Founder & CTO tại Astronomer

 

CÁCH LỰA CHỌN CÔNG NGHỆ TẠI EMARSYS:

Tại Emarsys, nếu muốn sử dụng ngôn ngữ lập trình mới, các developers cần cung cấp lý do thực tế, hợp lý và tham khảo ý kiến từ các Lead Developers. Các thành viên của nhóm sẽ tập hợp và cùng thảo luận về ưu và nhược điểm của ngôn ngữ đó.

Các kỹ sư luôn tạo ra giải pháp vượt bậc bằng các công nghệ khác nhau. Điều này cho phép họ thử nghiệm giới hạn của một công nghệ nhất định và kiểm tra khả năng áp dụng cho microservice. Đây là một cách khá hay để khám phá những hạn chế của một công nghệ.

Bạn nên sử dụng ngôn ngữ mà nhóm của bạn đã quen thuộc. Bằng cách này, họ có thể làm việc thoải mái hơn và tiến bộ nhanh hơn. – Andras Fincza, VP of Engineering tại Emarsys

 

CÁCH LỰA CHỌN CÔNG NGHỆ TẠI SIMILARWEB:

Là một công ty chuyên về dữ liệu và phân tích, chúng tôi thường giải quyết các bài toán ở quy mô rất lớn, điều này làm tăng rủi ro và các tác động nếu lựa chọn sai công nghệ. Một single threaded framework như NodeJS sẽ hữu ích với các dịch vụ network bound nhưng sẽ ko thể scale khi xử lý dữ liệu chuyên sâu theo thời gian thực.

Các kỹ sư nên lựa chọn công nghệ bằng cách cân bằng giữa kỹ năng chuyên môn và chiến lược phát triển, bằng cách xem xét cả những hạn chế về kỹ thuật và tổ chức. Có phải chúng ta đang trong giai đoạn tạo prototype? Service này có thể xử lý một lượng lớn dữ liệu? Chúng ta muốn sử dụng thêm công nghệ mới vì tin tưởng vào hệ sinh thái của nó hay nên sử dụng các công nghệ hiện có mà bản thân đã nắm vững? Chúng ta có thực sự muốn thử nghiệm không? Chúng ta có thể tìm thấy các kỹ sư đam mê những công nghệ này không? Hay chúng ta có sẵn sàng cam kết với công nghệ này trong dài hạn không? Hệ sinh thái của một công nghệ là yếu tố then chốt. Chúng tôi muốn tham gia với cộng đồng mã nguồn mở, sử dụng và đóng góp cho các framework hiện có hơn là phát minh ra điều gì đó mới lạ. 

Xây dựng guideline, checklist rõ ràng có thể hỗ trợ cho quá trình ra quyết định và thu hẹp các tùy chọn công nghệ, từ đó bạn có thể chọn lựa loại công nghệ phù hợp nhất cho nhóm và sản phẩm của mình. 

 

GỢI Ý LỰA CHỌN CÔNG NGHỆ CỦA DAVID DAWSON:

1. Từ góc nhìn của một Data Architecture cho thấy, bạn cần một công cụ có thể cung cấp dữ liệu mà từ đó dễ dàng đồng bộ hóa trạng thái một cách nhất quán giữa các services. Có nhiều cách tiếp cận khác nhau, nhưng đó là những gì tôi đang tìm kiếm trong quá trình triển khai microservice của mình. Vì vậy, bạn có thể lựa chọn các frameworks và công nghệ khác nhau để triển khai  (ví dụ như Kafka, Spring Data Flow, Akka,..vv).
2.  Khi đã đưa ra quyết định về các mô hình và cách tiếp cận, bạn sẽ kết hợp chúng với những tài nguyên bạn đang có sẵn. Nếu bạn lựa chọn data flow với reactive programming và bạn đã có các nhà Developers chuyên sử dụng Java, thì nên chọn Spring, Spring Cloud Data Flow và Kafka và có thể triển khai trên một số Cloud Foundry.

Nếu bạn cần transform nhiều dữ liệu lớn hơn, Spark hoặc Kafka Stream có thể giúp bạn. Tuy nhiên nếu các Developers của bạn dùng Javascript thì cách này chưa hợp lý. Thay vào đó, bạn nên tìm cách áp dụng một số functional language lên JS runtime (clojurescript, v.v.)

TỔNG KẾT:

Đừng căng thẳng về việc lựa chọn loại công nghệ hoàn hảo. Thay vào đó, hãy thử nghiệm và thay đổi nhiều lần.

Mọi kiến ​​trúc microservice là độc nhất; công nghệ được chọn phải phù hợp với nhu cầu của hệ thống.

Hãy nhớ rằng quá nhiều công nghệ khác nhau làm cho việc tuyển dụng trở nên phức tạp hơn.

 

Phần kết luận

Có rất nhiều thách thức khi chuyển sang Microservice

Trước khi bạn bắt đầu chuyển đổi hệ thống của mình thành microservice, hãy chắc chắn bạn hiểu lý do thực sự tại sao mình muốn làm điều đó. Tìm hiểu kỹ càng về ưu và nhược điểm của microservice sẽ giúp bạn đưa ra quyết định chính xác hơn. Thay vì chạy theo trào lưu, bạn cần xem xét các tính năng riêng biệt của hệ thống trước và chỉ thay đổi phần hệ thống “dễ tổn thương” nhiều nhất. Bắt đầu ngay từ đầu  bằng một kiến ​​trúc microservice là điều không khuyến khích vì việc xác định rõ ràng ranh giới của các microservice ngay từ đầu rất khó khăn.

Nếu bạn quyết định chuyển sang kiến ​​trúc microservice, hãy chuyển đổi dần dần bắt đầu từ một phần nhỏ và ít quan trọng trong hệ thống của bạn để xem nó hoạt động như thế nào. Đây cũng là cách phù hợp để thuyết phục tổ chức của bạn tiếp tục tạo thêm các microservice khác.

Không có cách nào để lựa chọn công nghệ hoàn hảo cho microservice. Mọi quyết định liên quan đến công nghệ cần dựa vào kiến thức của các kỹ sư công nghệ và kế hoạch tuyển dụng của công ty bạn. Trong một số trường hợp, việc chọn một công nghệ cho microservice liên quan nhiều đến quyết định tuyển dụng hơn vì nó phụ thuộc vào đặc điểm của nhóm kỹ sư mà bạn muốn xây dựng trong tương lai.

Tác giả: Tamás Török

Xem bài viết gốc tại đây

Tổng hợp và dịch: Vân Phạm, Thảo Ly, Thanh Nguyễn, Nhật Anh