Hà và các bạn thân mến,
Hà có một số câu hỏi khá thú vị và quan trọng, trong thư này, tôi chỉ xin thử góp ý về một trong các câu hỏi ấy:
Q: Những điểm vượt trội của OpenStack so với Eucalyptus, OpenNebulla?
Xin nói ngay, tôi sẽ không trả lời thẳng vào câu hỏi, bằng cách so sánh OpenStack vs Eucalyptus vs OpenNebula, mà lại thử xoay quanh vấn đề phương pháp và "đánh giá" các "món" ấy.
1. Tôi gọi ba thứ được kể ra là "món" vì thật ra, nếu làm so sánh có phương pháp, ta có thể sẽ phải so sánh chúng như những "kiến trúc", hay những "reference implementation" hay những "sản phẩm". Thí dụ: nếu ta xem OpenStack là "sản phẩm" thì rất có thể nó sẽ vấp ngay chuyện "hoàn chỉnh như một sản phẩm sẵn sàng để đem ra dùng" (trong một bối cảnh ứng dụng nào đó). Trong lúc đó, nếu so về "kiên trúc" ta lại phải đi vào các yếu tính cần phải so sành các kiến trúc với nhau, và rất có thể bạn sẽ thấy kiên trúc này phù hợp với nhu cầu của bạn hơn cái kia.
Xin thí dụ: việc tích hợp thuân lợi với một Hypervisor XYZ nào đó có thể là chuyên Go/No Go (theo hay bỏ) cho một người dùng này, trong khi nó có thể không quan trọng gì với người khác. Hoặc "phải có ngay bây giờ" hay "phải có trong một năm tới".
2. Đã nói thế, khi nói tới sự "vượt trội" là ta phải có những tiêu chí để đánh giá thật cụ thể để đánh giá và so sánh. Đây cũng là một điêu khá quan trọng. Vì, một vụ đánh giá nghiêm túc sẽ phải dựa trên một bảng liệt kê các "tính năng hay thuộc tính" đặt ra do nhu cầu ứng dụng cụ thể của một "khach hàng". Ngay cả khi hai khách hàng có hai bảng liệ kê khá giống nhau, mỗi khách hàng lại có thể có những cách "cho điểm" (năng nhẹ -- weight) khác nhau vì sự quan tâm, đòi hỏi cụ thể của chính khách hàng đó. Và từ đó, kết quả so sánh sau cùng có thể khác nhau.
3. Như thế, việc đánh giá chỉ thật sự có ý nghĩa (đối với một ai đó) khi ta biết người ấy cần gì, tìm kiếm gì, mong đợi gì ở một "món" nào đó. Tôi nói "mong đợi" vì có nhiều trường hợp người làm đánh giá (evaluation) phải nghĩ tới cả tiềm năng, tiền đồ, triển vọng, tuổi thọ của "món" ấy. Có người nói: không có sản phẩm tôt nhất, chỉ có sản phẩm thích hợp nhất cho một nhu cầu cụ thể. Người ấy có thể có lí.
Cho tôi kể một kinh nghiêm vui có thật trong đời hành nghề của tôi. Lâu lắm rồi, có lần tôi phải đánh giá một hệ CSDL quan hệ (RDBMS) có tầm cỡ nhỏ để nhúng (embed) vào một sản phẩm khá phức tạp của công ti. Tôi gò lưng cân, đo, đong đếm. Xong viết một báo cáo khá tỉ mĩ, nói đủ điều, dựa cả vào các lí thuyết về RDBMS. Lúc đem ra báo cáo cho sếp, sếp nghe ngiêm túc. Một lúc, sếp cười cười, bảo tôi: Cậu liệu cái công ti bán sản phẩm ấy nó sông được bao lâu? Tôi hiểu ý, lão này muốn biết cái công ti bé bé kia liệu còn sống bao lâu để làm "support" nếu mình mua sản phẩm của nó. Đôi lúc vì khả năng chết yểu của công ti, sự vượt trội của sản phẩm bị chém ngang lưng. Vui là thế.
4. Quay lại chuyên của chúng ta đang bàn, tôi thử đưa ra một vài tiêu chí để may ra Hà có thể dùng nó để so ba món kia (nếu một số tiêu chí may mắn trùng hợp với quan tâm của Hà):
-- Một kiến trúc mở, có những quan tâm về scalability, extensibility, Open and rich API, etc...
-- Có nhiều công ti, nhóm, và cá nhân tham dự vào các khâu của qui trình phát triển
-- Có nhiều vendors tham dự và năng động trong việc tạo nên và hỗ trợ những "sản phẩm" cụ thể dựa trên một reference implementation
-- Dễ dàng chuyển hóa theo các phiên bản dọc theo con đường phát triển và hoàn thiện của "món đó" (với những công cụ và phương tiện hữu hiệu và dễ dùng)
-- Có một cộng đồng tham dự tích cực vào việc phát triển và bảo vệ tính mở của "món " đó...
-- Có khả năng tích hợp với nhiều hệ thống, tiểu hệ thống, packages phổ dụng hiện có
-- Có mức độ đầu tư vật chất và trí tuệ cao và ngay càng gia tăng của a) cộng đồng PMNM, và b) Những người quan tâm đến cloud computing.
-- (Và như bạn Luu Van Hau góp ý) Độ "chín" (tôi chỉ xin thêm: khi nói về độ chín, ta cũng nên có một khung thời gian cho mùa thu hoạch. Và lại nữa, mỗi nhu cầu có thề có lịch thu hoạch khác nhau).
-- ??? ???
-- ??
Xin dừng ở đây. Còn lại, xin nhường cho các bạn khác góp ý. Và đánh giá sau cùng là của Hà.
Mến,
NH