(Bài dịch đã được sự đồng ý từ tác giả)
Chuyển sang Microservice nghe có vẻ đơn giản, tuy nhiên các Tech Leaders (Chuyên gia công nghệ) có xu hướng đánh giá thấp mức độ phức tạp của dự án nên thường dẫn đến các sai lầm nghiêm trọng.
Trước khi chuyển đổi từ kiến trúc Monolithic sang kiến trúc Microservices hoặc bắt đầu ngay từ đầu bằng Microservices, chúng ta cần xem xét kỹ càng những thách thức về công nghệ và bên trong nội bộ tổ chức có thể phát sinh. Bài viết này dành cho bạn nếu bạn muốn:
- Chuyển đổi từ kiến trúc Monolithic sang Microservice
- Tham khảo góc nhìn chuyên sâu từ các tech leaders giàu kinh nghiệm
- Nắm được ưu và nhược điểm của Microservice.
- Tránh những sai lầm nghiêm trọng
- Đưa ra các quyết định liên quan đến Microservice sáng suốt hơn
Chúng tôi đã thực hiện 13 cuộc phỏng vấn với các Tech leaders từ 5 quốc gia khác nhau, từ Israel đến Mỹ, và tóm tắt các kinh nghiệm của họ trong bài viết này. Vì bài viết khá dài, trong phần 1, chúng ta sẽ bàn về các vấn đề chính sau:
- Hiểu lý do tại sao cần chuyển sang Microservice
- Microservice là gì?
- Ưu và nhược điểm của kiến trúc Microservice
- Những thách thức lớn nhất khi chuyển sang Microservice và giải pháp
HIỂU LÝ DO TẠI SAO CẦN CHUYỂN SANG MICROSERVICE
Sai lầm lớn nhất mà bạn có thể mắc phải là chuyển sang kiến trúc Microservice mà không có mục tiêu rõ ràng. Bạn cần hiểu lý do thực sự tại sao mình muốn chuyển sang loại kiến trúc này.
Steven McCord, người sáng lập, CTO tại ICX Media chia sẻ: “Hầu hết mọi người đều bị hấp dẫn bởi các công nghệ mới như Docker, Microservice! Thế nhưng những công nghệ này có thể không phù hợp với sản phẩm của bạn. Vì vậy bạn cần hiểu lý do tại sao bạn muốn ứng dụng một công nghệ nhất định.”
Nếu bạn đang có một hệ thống hoạt động tốt, vậy động lực của bạn để thay đổi nó là gì? Chỉ vì các kiến trúc Microservice đang được thịnh hành không có nghĩa là bạn cần phải chạy theo trào lưu. Đó có thể không phải là sự lựa chọn về công nghệ tốt nhất cho sản phẩm của bạn. Xác định các lý do là rất quan trọng là những gì mà David Dawson, Steven McCord và Avi Cavale nhấn mạnh.
David Dawson, Kỹ sư hệ thống chia sẻ: “Câu hỏi đầu tiên tôi hỏi khách hàng khi họ yêu cầu tôi giúp họ triển khai Microservice là: Tại sao? Và câu trả lời tôi đang tìm kiếm là: Chúng tôi muốn hệ thống của mình chạy nhanh hơn, chúng tôi muốn tận dụng các lợi thế của cloud tech. Tôi cũng giúp khách hàng hiểu rằng Microservice tốn kém hơn và khó xây dựng một kiến trúc Monolithic. Dữ liệu của họ sẽ bị phân tán trong network và có nguy cơ bị mất. Hệ thống của họ hoàn toàn lệ thuộc vào nền tảng điện toán phân tán.
Phương pháp được đề xuất:
XÁC ĐỊNH RÕ MICROSERVICE LÀ GÌ?
Daniel Ben-Zvi, Vice President của phòng R&D tại SimilarWeb chia sẻ: “Tôi không nhất thiết phải sử dụng Microservice. Tôi sẽ sử dụng các services cỡ trung bình. Chúng tôi không chuyển kiến trúc từ Monolithic sang Microservice với hàng trăng services nhỏ, mà sử dụng các services lớn hơn phù hợp với các nhóm kỹ sư hiện có và lĩnh vực của mình.
Nếu bạn không rõ ràng giữa các khái niệm service, microservice và function, hoặc:
- Phân tách chưa đủ, do vậy bạn sẽ không nhìn thấy lợi ích của kiến trúc microservice.
- Hoặc phân tách quá nhỏ ứng dụng, công việc quản lý sẽ làm mất đi giá trị mà kiến trúc microservice có thể mang lại (Avi Cavale).
Có quan điểm và định hướng rõ ràng về việc apply microservice sẽ mang lại thay đổi gì cho công ty của bạn là đặc biệt quan trọng.
Bạn phải làm như thế nào đây? Có một case study nhỏ để bạn tham khảo như sau:
Avi Cavale, Đồng sáng lập & CEO tại Shippable chia sẻ: “Chúng tôi đã xác định Microservice là gì bằng cách nhìn vào từng đoạn code, nếu thay đổi, sẽ tạo ra các test cases theo cấp số nhân. Chúng tôi bắt đầu loại bỏ chúng vì mục tiêu của chúng tôi là giảm số lượng test cases phải thực hiện cho mỗi sự thay đổi mà chúng tôi tạo ra. Nếu đó mà cách mà bạn làm để xác định microservice thì bạn khác với một người chỉ mong muốn xây dựng Microservice mà không có mục tiêu rõ ràng.
👉 Gợi ý đọc: Kiến trúc Microservice và Monolithic
ƯU VÀ NHƯỢC ĐIỂM CỦA KIẾN TRÚC MICROSERVICE
Ưu điểm của kiến trúc Microservice
Khả năng mở rộng: Khi bạn có nhiều service nhỏ với các nghiệp vụ riêng biệt, bạn có thể mở rộng (scale) từng thành phần thay vì toàn bộ hệ thống.
Maintain dễ dàng hơn: Các nhóm khác nhau làm việc độc lập trên các components khác nhau.
Đóng gói và triển khai độc lập: Bạn có thể đóng gói và triển khai các phần nhỏ của hệ thống mà không ảnh hưởng đến các services khác. Các nhóm phát triển khác nhau có thể triển khai lên production mà không bị giẫm chân lên nhau.
Kiểm soát vấn đề: Cô lập và kiểm soát vấn đề dễ dàng hơn
Tuyển dụng dễ dàng hơn: Khi tuyển dụng mới các Developers hoặc sử dụng dịch vụ của bên thứ 3, bạn chỉ cần đào tạo họ một phần nhỏ của hệ thống.
Trách nhiệm được xác định rõ ràng: Mỗi nhóm chịu trách nhiệm cho một microservice nhất định.
Kiến thức sâu sắc: Các nhóm hiểu và nắm rõ về hệ thống hoặc service mà họ chịu trách nhiệm
Sử dụng đa dạng ngôn ngữ lập trình: Bạn có thể sử dụng các ngôn ngữ lập trình khác nhau, miễn là ngôn ngữ đó phục vụ tốt nhất cho yêu cầu của service
Giám sát và hiểu dễ dàng hơn: Việc chia hệ thống với lượng code lớn thành các dự án nhỏ sẽ cho phép bạn và nhóm của mình hiểu logic/nghiệp vụ tốt hơn.
Expose service dễ dàng hơn: Với Microservice, khi ranh giới và interfaces được xác định rõ ràng, bạn có thể expose các components hay services năng hiện có cho các business unit mới hoặc các thực thể bên ngoài.
Nhược điểm của kiến trúc Microservices
Triển khai và khả năng tương tác: Hạn chế ở đây là việc triển khai và khả năng tương tác trở thành nỗi lo chính.
Quá nhiều ngôn ngữ lập trình: Điều này có thể hạn chế khả năng tái sử dụng lại code của bạn cũng như khả năng maintain và làm việc tuyển dụng trở nên phức tạp hơn.
Làm cho các thành phần hoạt động cùng nhau: Bạn luôn cần đảm bảo rằng các services của bạn được cấu thành đúng cách. Lưu ý rằng việc thay đổi một endpoint cũng có thể phá vỡ các services phụ thuộc vào nó
Khó thực hiện test tích hợp cho toàn bộ hệ thống so với hệ thống kiến trúc Monolithic – nơi mọi thứ đều ở cùng vị trí
Cân nhắc kỹ lưỡng trước khi sử dụng Microservice: Nếu có quá nhiều sự phụ thuộc giữa các service, bạn sẽ gần như không tận dụng được lợi thế nào từ Microservice.
Yêu cầu giao tiếp nhiều hơn: Bạn sẽ phải đầu tư các chi phí liên quan cho việc giao tiếp giữa các services vì sẽ có rất nhiều lỗi có thể xảy ra
Khó monitor toàn bộ hệ thống: Việc theo dõi rất nhiều services cùng lúc có thể là một cơn ác mộng với bạn.
Cần nhiều thời gian để tìm hiểu: Sử dụng kiến trúc microservice đòi hỏi bạn phải học và điều đó khá tốn thời gian
Độ phức tạp: Việc ngày càng có nhiều microservice làm cho toàn bộ hệ thống trở nên phức tạp và khó giám sát hơn về mặt operation
Avi Cavale, Đồng sáng lập & CEO tại Shippable: “Một khi các services được chia nhỏ, nếu không có quy trình quản lý tốt, bạn sẽ bị nhấn chìm trong sự hỗn độn và vô số vấn đề phát sinh.”
Daniel Ben-Zvi, Vice President của R & D tại SimilarWeb: “Debug trên production trên nền tảng microservice là một vấn đề hoàn toàn khác. Nếu không có sự giám sát, logging và tracing thích hợp, hệ thống của bạn sẽ trở nên phức tạp một cách đáng kể. Điều này giống như đi qua một mê cung vậy. Kỹ thuật và tiêu chuẩn hóa trở nên vô cùng quan trọng.”
Sonu Kumar – Site Reliability Engineer tại Microsoft: “Logging vào một nơi là một thách thức. Các dịch vụ logging của bên thứ ba như Loggly, Splunk hoặc Heroku là những giải pháp rất tốt nhưng giá cả lại vô cùng đắt đỏ. Theo kinh nghiệm của tôi, centralized logging là khó khăn lớn nhất. Bạn phải nghĩ về mức độ chi tiết của từng dịch vụ. Nếu không, cuối cùng bạn phải dành đến 50%-60% budget cho việc logging.
NHỮNG THÁCH THỨC LỚN NHẤT KHI CHUYỂN SANG MICROSERVICE VÀ GIẢI PHÁP
Khi doanh nghiệp của bạn bắt đầu chuyển hướng sang kiến trúc Microservice, dưới đây sẽ là những thử thách khó nhằn nhất mà cả tech leader và toàn bộ developer team phải đối mặt:
- Thử thách 1: Chuyển đổi tất cả hệ thống trong một lần duy nhất
- Thử thách 2: Phân tách hệ thống
- Thử thách 3: Thuyết phục tổ chức của bạn
- Thử thách 4: Team
Thử thách 1: Chuyển đổi tất cả hệ thống trong một lần duy nhất
“Chuyển đổi một kiến trúc Monolithic sang kiến trúc microservice không phải là điều bạn có thể làm chỉ trong 1 lần duy nhất. Giả sử bạn có một máy chủ nguyên khối: đi kèm nó chắc chắn sẽ bao gồm repositories, các deploy task, giám sát và nhiều thứ khác được thiết lập chặt chẽ xung quanh. thay đổi tất cả cùng một lúc chưa bao giờ là điều dễ dàng.” – Brujo Benavides, cựu CTO của Inaka cho hay.
“Đối với một công ty chưa từng có kinh nghiệm gì với Microservices, bắt đầu một dự án mới toanh sẽ khó hơn họ tưởng tượng.” – Viktor Tusa, DevOps Engineer tại LogMeIn.
Giải pháp khả thi
“Những gì chúng tôi đã làm khi đó là vẫn giữ server Monolithic, tuy nhiên bất kỳ bổ sung mới nào cũng sẽ được phát triển dưới dạng microservice. Dần dà, mọi thứ sẽ được rút khỏi máy chủ ban đầu cho đến khi nó trở thành microservice lớn nhất và lâu đời nhất của chúng tôi.” – Brujo Benavides nói.
Thử thách 2: Phân tách hệ thống
“Việc cách ly các component và các services có thể khá khó khăn nếu chúng đã được đính kèm với nhau ngay từ khi phát triển dự án.” – Robert Aistleitner
“Bạn cần xác định được sự tương tác và processes giữa các phần. Nếu bạn không tìm được chúng chuẩn xác, hệ thống của bạn sẽ tạo ra nhiều vấn đề hơn.” – Jose Alvarez, Senior Developer tại StyleSage.
“Không bao giờ có 2 microservices giống hệt nhau, không có design pattern, chỉ có các quy tắc độc lập để phân chia một hệ thống thành Microservices. Bạn cần hiểu và tìm ra hướng xử lý phù hợp cho hệ thống của mình.” – David Papp, Chief Architect tại Recart
Giải pháp khả thi
“Cách duy nhất để phân chia một kiến trúc Monolithic thành Microservices là inspect, để tìm ra nơi “tổn thương” nhiều nhất. Những phần bị “tổn thương” này nên được tách ra và chuyển thành một Microservice.” – Andras Fincza, phó giám đốc công nghệ tại Emarsys.
“Nếu bạn không theo dõi đúng cách, bạn sẽ không thể có cái nhìn đúng về cách hệ thống của mình đang hoạt động. Hãy chủ động theo dõi tất cả các services đang hoạt động ra sao và như thế nào. Nếu bạn có thể làm chủ được hệ thống, bạn có thể phát hiện và giải quyết vấn đề khá dễ dàng.” Jose Alvarez
Dần dần, mô-đun theo mô-đun sẽ là cách tốt nhất để phân chia một kiến trúc Monolithic . Nếu bạn chỉ chăm chăm muốn chuyển đổi chúng cùng một lúc, bạn chắc chắn sẽ thất bại.
Một số tool để momitoring:
- New Relic
- Datalog
- Influxdb
- Grafana
Thử thách 3: Thuyết phục tổ chức của bạn
“Việc thuyết phục tổ chức sử dụng Microservice gần như là phần khó nhất.” Steven McCord, người sáng lập và CTO tại ICX Media
Đây không phải là một quyết định công nghệ. Bạn sẽ cần chỉ ra rõ các lợi ích của kiến trúc Microservice để thuyết phục công ty bạn phân bổ các nguồn lực. Đó sẽ có thể là một quá trình dài đằng đẵng và tẻ nhạt cho đến khi nó được chấp nhận. Công ty càng lớn thì việc đưa ra quyết định sẽ càng tốn thời gian.
Các giải pháp khả thi
Cách tốt nhất để thuyết phục công ty bạn chuyển hướng sang kiến trúc Microservice là hãy thử chuyển đổi một phần phụ trong hệ thống thành Microservice trước. Bằng cách này, bạn có thể chứng minh trực tiếp những lợi ích có được khi sử dụng kiến trúc Microservice
Thử thách 4: Team
“Thử thách lớn nhất đôi khi xảy ra ngay trong việc giao tiếp với những người đồng nghiệp của bạn bởi nó đòi hỏi việc tư duy khác biệt.” Avi Cavale, đồng sáng lập & CEO tại Shippable
Các developers cần dành nhiều thời gian hơn để hiểu một cách tổng quan về quá trình chuyển đổi này (end-to-end scenario). Họ cần được làm quen với các công nghệ và đôi khi việc này sẽ yêu cầu thay đổi tư duy cũ của họ – một việc khá tốn thời gian.
“Những người đã quen làm end-to-end test sẽ ko thấy thoải mái khi hệ thống bị chia nhỏ ra làm nhiều phần. Sự thay đổi này đáng kể hơn một thay đổi văn hóa thông thường.” – Avi Cavale
Giải pháp khả thi
“Bắt đầu bằng 1 phần nhỏ mà có thể thấy ngay hiệu quả, đừng quá quan trọng cho toàn bộ hệ thống.Tạo 1 team nhỏ và chuyển phần đó sang microservice để chứng minh được lợi ích của nó và dần dần mở rộng ra toàn bộ tổ chức.” – Avi Cavale
Tránh mắc những lỗi sau đây
“Không nên chuyển đổi toàn bộ hệ thống sang Microservice trong một lần duy nhất” Andras Fincza, Phó giám đốc kỹ thuật tại Emarsys
“Tôi cho rằng lỗi lớn nhất bạn có thể mắc phải chính là chưa có được cái nhìn tổng quan về ý nghĩa việc chuyển đổi kiến trúc microservice mang lại. Có rất nhiều thứ mà bạn cần cân nhắc, xem xét trước khi thực sự bắt đầu thực hiện phương pháp mới. – Robert Aistleitner, Phó chủ tịch kỹ thuật tại Usersnap
“Với kiến trúc Monolithic thì dễ dàng thay đổi giao diện bên trong: bạn chỉ cần sửa code và chạy test. Với microservice, API của bạn phải thật chuẩn. Bạn sẽ không thể biết hết những service nào đang phụ thuộc vào API đó. Phát triển hệ thống mà không cân nhắc đến khả năng thay đổi trong tương lai của API sẽ tạo ra nhiều vấn đề sau này. Ngoài ra, bạn cũng cần chắc chắn rằng đã có một hệ thống monitoring sẵn sàng.” Daniel Ben-Zvi, phó giám đốc phòng R&D của SimilarWeb.
“Đừng cố gắng chuyển hướng sang Microservice mà chưa tìm ra một nền tảng và các phần bổ trợ. Việc có niềm tin vào Microservice chỉ vì mọi Microservice có thể được viết bởi các ngôn ngữ khác nhau là hoàn toàn không nên.” Viktor Tusa, Kỹ sư DevOps tại LogMeIn
“Xử lý dữ liệu vô cùng quan trọng, bởi dữ liệu là thứ cực kỳ dễ gặp vấn đề nhưng lại rất khó khôi phục. Việc migrate dữ liệu cần tiến hành theo nhiều bước. – Andras Fincza, Phó giám đốc kỹ thuật tại Emarsys
“KHÔNG nên chia sẻ dữ liệu giữa các Microservice. Nếu có 2 services đang cùng xử lý chung một database, bạn sẽ gặp phải các vấn đề về tính nhất quán và quyền sở hữu. – Daniel Ben-Zvi & Varun Villait.
“Không nên chia một ứng dụng thành quá nhiều những phần nhỏ hoặc gượng ép chuyển đổi một hệ thống không phù hợp thành Microservice chỉ vì nó được thổi phồng lên.” Csaba Kassai, Development Team Leader tại Doctusoft.
(Hết phần 1)
Đón đọc phần tiếp theo vào tuần sau các bạn nhé! Like và follow Fanpage của Pixta Việt Nam tại đây để cùng đọc và cập nhật những tin tức công nghệ mới nhé!
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