Ứng dụng đã sẵn sàng để trở thành ảo chưa?

 

Bài viết đề cấp đến việc người dùng xem xét cách làm thế nào để có thể quyết định chọn triển khai nào phù hợp nhất với ứng dụng của mình.

1. Giới thiệu

Trong bài trước, Phần 1 trình bày “Tổng quan về các di trú lên Hệ thống PureApplication”, bạn đọc đã thấy cách IBM® PureApplication® (Hệ thống PureApplication của IBM) hỗ trợ cả các ứng dụng ảo lẫn các hệ thống ảo. Nói ngắn gọn, sự khác biệt giữa chúng là ở chỗ đánh đổi các mức kiểm soát với mức tự động hóa. Phần 2 này xem xét cách làm thế nào để có thể quyết định tùy chọn triển khai nào phù hợp nhất với ứng dụng cụ thể sẽ lựa chọn.

 

2. Những lợi thế và những hạn chế của các ứng dụng ảo

Một ứng dụng ảo là một cách triển khai một ứng dụng JEE cùng với một bộ các quyết định chính sách để xác định cách ứng dụng co giãn quy mô và sử dụng các tài nguyên của máy ảo Java (JavaTM Virtual Machine - JVM) như thế nào. Khi triển khai một ứng dụng như là một ứng dụng ảo, nên tận dụng lợi thế của một bộ các dịch vụ chia sẻ dựng sẵn để xử lý các chi tiết của các vấn đề, ví dụ như việc cân bằng tải và quản lý HttpSession. Tuy nhiên, những lợi ích tự động hóa đó có kèm một giá phải trả, cấu trúc liên kết của ứng dụng ví dụ: có bao nhiêu máy chủ ứng dụng đang chạy cùng một lúc, máy chủ nào xử lý kiểu yêu cầu nào và v.v... được Hệ thống PureApplication chủ động quản lý. Ví dụ nói trên có nghĩa là không thể chia tách ứng dụng của mình thành một tầng Web đang chạy các servlet và một tầng EJB đang chạy các EJB từ xa.

 

Đối với nhiều ứng dụng, đây không phải là một vấn đề, nhưng đối với các ứng dụng cũ hơn hoặc đã dựa vào việc đóng gói nhiều tầng hoặc dựa vào các đặc tính của một cấu trúc liên kết ứng dụng đặc thù thì lại có thể có thể thành vấn đề. Một phần khác của cái giá phải trả là chỉ có một số mô hình lập trình nhất định nào đó được hỗ trợ. Đối với những ứng dụng nào đòi hỏi tính linh hoạt nhiều hơn, Hệ thống PureApplication cũng hỗ trợ các hệ thống ảo.

 

3. Các hệ thống ảo:

Một hệ thống ảo là một cơ chế tạo ra một khuôn mẫu hoặc một mẫu của toàn bộ cấu trúc liên kết được xây dựng từ các ảnh ảo. Người dùng có thể sử dụng các ảnh của IBM-provided Hypervisor Edition (Ấn bản Siêu giám sát do IBM cung cấp) trong khi xây dựng các hệ thống ảo cho mình hoặc có thể xây dựng các ảnh riêng của mình bắt đầu từ một ảnh RHEL cơ sở bằng cách sử dụng công cụ IBM Tivoli® ICON. Một khả năng khác là tính năng “Bắt giữ và Mở rộng” (Capture and Extend) của Hệ thống PureApplication, cho phép bắt đầu với một ảnh ảo và thêm phần mềm bổ sung vào ảnh đó trước khi đóng gói lại để sử dụng sau này. Một lý do quan trọng khác trong xây dựng các hệ thống ảo có thể thêm các kịch bản lệnh riêng của người dùng vào hệ thống ảo. Nếu muốn triển khai một ứng dụng vào một mẫu cấu trúc liên kết đã tạo ra, cần tạo kịch bản lệnh triển khai đó để nó xảy ra như là một phần của quá trình khởi tạo cá thể trong triển khai một cá thể của hệ thống ảo vào phần cứng của Hệ thống PureApplication.

 

4. Chọn cách tiếp cận đúng

Trong hầu hết trường hợp, việc chuyển một ứng dụng lên Hệ thống PureApplication thực sự không phải là một quá trình phức tạp. Tuy nhiên, mấu chốt để thực hiện quá trình di trú của người dùng là phải hiểu rằng cần chọn chính xác một cách tiếp cận đúng để đưa ứng dụng của mình lên hệ thống. Hệ thống PureApplication hỗ trợ một số cách khác nhau để có thể triển khai ứng dụng của người dùng. Phải lựa chọn sao cho dẫn đến lượng công việc ít nhất với lợi ích lớn nhất là quyết định quan trọng nhất mà người dùng có thể đưa ra trong quá trình di trú. Điều đã thấy trong khi đưa lên một số ứng dụng ISV hiện có là cách đơn giản nhất để bắt đầu việc này là chỉ cần hỏi một loạt các câu hỏi sau: Có phải ta đang xây dựng một ứng dụng mới phải không? Lý do tại sao cần đề cập đến câu hỏi này trước tiên rất đơn giản – nếu muốn tận dụng lợi thế của cơ chế triển khai đơn giản nhất và dễ dàng nhất. Như đã thấy ở trên, mô hình triển khai đơn giản nhất do Hệ thống PureApplication cung cấp là ứng dụng ảo. Nếu người dùng đang xây dựng một ứng dụng mới và có cơ hội tác động đến các lựa chọn công nghệ và thiết kế được thực hiện trong ứng dụng, thì hãy chọn những công nghệ và thiết kế nào làm cho một ứng dụng tương thích với một ứng dụng ảo. Tuy nhiên, trong hầu hết các trường hợp, ứng dụng mà người dùng đang xử lý hàng ngày không phải là các ứng dụng làm mới từ đầu. Thay vào đó, người dùng xử lý các ứng dụng hiện có, đã được xây dựng và vẫn đang chạy trong một môi trường hiện có. Rồi họ sẽ phải xem xét câu hỏi tiếp theo. Đây có phải là một ứng dụng Web không? Đó là một câu hỏi có vẻ bề ngoài đơn giản đánh lừa. Điều chúng ta thực sự nghĩ đến khi hỏi câu này là, “Có phải ứng dụng này chỉ nhận các yêu cầu HTTP hoặc HTTPS (http an toàn) gửi đến không?” Định nghĩa này kết hợp một số mẫu khác nhau trong phát triển ứng dụng. Định nghĩa này có thể muốn nói tới bất cứ mẫu ứng dụng nào sau đây:

- Một ứng dụng cung cấp các dịch vụ RESTful cho một giao diện người dùng được viết bằng các công nghệ Javascript và AJAX.

- Một nhà cung cấp Các dịch vụ Web đang thực hiện các dịch vụ SOAP cho các máy khách bên ngoài trên Internet.

- Một ứng dụng Web cổ điển được xây dựng bằng các servlet và các JSP. Tuy nhiên, định nghĩa này không bao gồm một số kiểu ứng dụng: ví dụ, ứng dụng khách-chủ Java, sử dụng máy khách Java phong phú (thick) kết nối thông qua RMI hay RMI/IIOP tới các EJB chạy ở mặt sau, không được coi là một ứng dụng web khi sử dụng định nghĩa này.

Những suy xét này cũng đưa chúng ta đến câu hỏi tiếp theo. Người dùng có sử dụng các EJB từ xa không? Các EJB là một phần hữu ích của mô hình lập trình JEE hầu như ngay từ lúc khởi đầu của nó. Tuy nhiên, lợi ích của các EJB từ xa phải cân đối lại do phải đánh đổi bằng độ phức tạp của cấu trúc liên kết ứng dụng của người dùng. Các máy chủ ứng dụng của người dùng phải xử lý cả hai, lưu lượng HTTP gửi đến các servlet, các JSP, các dịch vụ Web của họ, cũng như cả lưu lượng RMI/IIOP gửi đến từ các máy khách EJB. Thông thường việc này được thực hiện bằng hai tầng máy chủ ứng dụng (một tầng được dành riêng để xử lý lưu lượng HTTP; một tầng khác được dành riêng để xử lý lưu lượng RMI). Như là một phần của quá trình đơn giản hóa, sử dụng các ứng dụng ảo, người dùng phải từ bỏ một số các tùy chọn cấu trúc liên kết này.

 

Vì vậy, như đã thảo luận ở trên, nếu người dùng cần các EJB từ xa, hãy bám chặt lựa chọn sử dụng các hệ thống ảo, ở đây có sẵn các tùy chọn cấu trúc liên kết này cho họ sử dụng. Ứng dụng có được đóng gói theo một cách tiêu chuẩn không? Một lần nữa, đây là một câu hỏi có vẻ bề ngoài đơn giản đánh lừa. Dùng thuật ngữ “theo một cách tiêu chuẩn”, chúng ta muốn nói là ứng dụng có được đóng gói dưới dạng một tệp EAR, một tệp WAR, một tệp lưu trữ ZIP hoặc một EBA (OSGi Enterprise Bundle Archive - Lưu trữ gói doanh nghiệp OSGi) hay không?

 

Rõ ràng mặc dù tiêu chuẩn JEE là đóng gói các ứng dụng thành các tệp EAR hoặc WAR và tiêu chuẩn OSGi đã giới thiệu các kiểu lưu trữ EBA, nhưng nhiều ứng dụng vẫn không được đóng gói theo cách đó - thay vào đó, chúng được gửi đi dưới dạng cấu trúc thư mục “đã bung ra”. Mặc dù cấu trúc đó có thể làm việc với các máy chủ đơn giản như Tomcat, đóng gói theo cách không chuẩn làm rắc rối thêm khi di chuyển đến các máy chủ JEE mới, ví dụ như các máy chủ hỗ trợ các ứng dụng ảo.

Vì vậy, nếu câu trả lời của là không, thì hãy đóng gói lại ứng dụng theo một trong các định dạng tiêu chuẩn này. Tương tự như vậy, có rất nhiều chiến lược đóng gói khác trong WebSphere® Application Server (Máy chủ ứng dụng WebSphere) mà có thể người dùng muốn sử dụng; ví dụ, máy chủ đã liên kết với các thư viện chia sẻ. Một lần nữa, để đơn giản hóa mô hình, những cách đóng gói này không được sử dụng trong các ứng dụng ảo.

 

Nếu người dùng không thể tránh được sử dụng các cách tiếp cận này, thì hãy xem xét việc sử dụng các hệ thống ảo để thay thế. Ứng dụng có sử dụng các mô hình lập trình JEE tiêu chuẩn không? Đã có một thành ngữ nói rằng “Một trong những điều thú vị về các tiêu chuẩn là có quá nhiều tiêu chuẩn để chọn.”Thật không may, điều đó hoàn toàn đúng khi nói về các mô hình lập trình. Các API mới được giới thiệu với một nhịp độ nhanh và qui trình của cộng đồng Java bị ngập chìm với các JSR tồn đọng, hoặc không bao giờ được phê duyệt hoặc không bao giờ đạt được sự chấp nhận rộng rãi đủ để chính thức trở thành một phần của tiêu chuẩn JEE.

 

Một lần nữa, vấn đề là với các ứng dụng ảo, người dùng cần giữ cho mọi thứ đơn giản, vì thế phải hạn chế bộ các API được hỗ trợ ở mức có thể quản lý được. Do đó, nếu ứng dụng chỉ sử dụng các API tiêu chuẩn từ JEE5, J2EE1.4, 1.3 hoặc 1.2, OSGi, JPA, JAX-RPC, JAX-WS và JAX-RS, thì hoàn toàn yên tâm. Page 5 of 85 Mặt khác, nếu đang viết chương trình ở một mức JEE mới hơn (chẳng hạn như JEE 6) hoặc đang sử dụng một số API khó hiểu từ sâu bên trong lòng của JCP, thì ứng dụng có thể sẽ không làm việc như một ứng dụng ảo.

Tuy nhiên, cách tiếp cận của IBM là để cung cấp sự hỗ trợ cho các API mới hơn thông qua Các gói tính năng (Feature Packs). Vì vậy, nếu đang lập kế hoạch cho một mức API mới, có thể cần xem xét xây dựng một hệ thống ảo bằng cách sử dụng WebSphere Application Server V8 (Phiên bản V8 của Máy chủ ứng dụng WebSphere) và kết hợp Gói tính năng (và hỗ trợ cho API đó) khi nó trở nên có sẵn. Ứng dụng này hiện có đang chạy được trên Phiên bản 7 hay Phiên bản 8 của WebSphere Application Server không? Đây là một câu hỏi mềm, nhưng là một câu hỏi quan trọng. Có một vài câu trả lời khác nhau cho câu hỏi này mà người dùng cần xem xét.

 

Thậm chí nếu câu trả lời cho câu hỏi này là “có”, nhưng người dùng rơi vào một trong các thể loại trước đây, đã đề cập khi nói về mô hình lập trình, đóng gói theo tiêu chuẩn hoặc sử dụng các EJB từ xa, thì quyết định của họ đã được chọn rồi - ứng dụng của họ không thể là một ứng dụng ảo. Tuy nhiên, nếu trả lời “không”, có thể họ vẫn có khả năng chạy như một ứng dụng ảo. Nếu ứng dụng của người dùng tuân thủ đúng như đã trả lời các câu hỏi về mô hình lập trình và về đóng gói ở trên, thì mọi thứ có thể vẫn còn tốt. Tuy nhiên, nếu ứng dụng của người dùng đang chạy trên một phiên bản WebSphere Application Server cũ hơn nhiều hoặc trên một máy chủ ứng dụng khác, thì trước hết có thể phải hoàn thành nỗ lực di trú trước khi họ có thể di chuyển tới hoặc một ứng dụng ảo hoặc một hệ thống ảo. Ứng dụng của người dùng có yêu cầu bất kỳ các sản phẩm họ WebSphere nào như WebSphere Portal Server (Máy chủ cổng WebSphere) hoặc WebSphere Process Server (Máy chủ xử lý quy trình WebSphere) không? Như chúng ta đã mô tả ở trên, cách tiếp cận ứng dụng ảo là một cách tiếp cận được nhằm vào việc xây dựng các ứng dụng Web.

 

Nếu kiểu ứng dụng của người dùng (hoặc “tải làm việc” nếu họ muốn sử dụng thuật ngữ đó) không phải là một ứng dụng Web, thì cách tiếp cận ứng dụng ảo hiện tại không phải là một cách tiếp cận đúng dành cho họ. Lưu ý rằng đây là tuyên bố có tính thời điểm. Theo thời gian, các kiểu tải làm việc mới sẽ được thêm vào IBM Workload Deployer và Hệ thống PureApplication. Vì vậy, ở một số thời điểm, ngay cả khi người dùng có một ứng dụng quản lý qui trình nghiệp vụ, họ có thể tận dụng lợi thế của các mức tự động hóa cao hơn mà các ứng dụng ảo cung cấp cho các ứng dụng Web hiện nay. Tuy nhiên, vào lúc này, nếu yêu cầu bất kỳ sản phẩm nào trong các sản phẩm này, họ cần phải xây dựng một hệ thống ảo kết hợp các sản phẩm của Hypervisor Edition (Ấn bản Siêu giám sát) của IBM được phân phối như là một phần của danh mục trực tuyến cho Hệ thống PureApplication hoặc Workload Deployer của IBM. Ứng dụng đã sẵn sàng để tận dụng lợi thế của việc quản lý phiên làm việc với WebSphere Extreme Scale (Mở rộng quy mô rất lớn của WebSphere) chưa? Cũng như với nhiều câu hỏi trước đó, có rất nhiều thứ được gói trong câu này.

 

Về cơ bản, trước tiên người dùng phải xem xét việc sử dụng API HttpSession của mình. Nhiều ứng dụng được viết theo một cách hoàn toàn không trạng thái và không hề dùng API HttpSession tí nào - những ứng dụng đó hoàn toàn phù hợp với các ứng dụng ảo. Mặt khác, nếu họ hiện đang sử dụng HttpSessions trong ứng dụng của mình, thì phải suy nghĩ một chút về cách bạn sử dụng chúng. Trước hết, có phải tất cả các nội dung HttpSession được khai báo là java.io.Serializable hay không? Nếu không, thì người dùng có một vấn đề. Với các ứng dụng ảo, mô hình mà các chính sách mở rộng tuân theo là các cá thể máy chủ ứng dụng có thể được tạo ra động và bị phá hủy khi cần để xử lý tải làm việc mà ứng dụng đang thực hiện vào bất cứ lúc nào. Nếu người dùng giả định rằng máy chủ của họ tồn tại lâu dài và bộ nhớ của nó là một kho lưu trữ “an toàn” cho thông tin về phiên làm việc, thì họ sẽ bị bất ngờ lúng túng nếu họ cố gắng thực hiện một ứng dụng ảo.

 

Tương tự như vậy, nếu số lượng các phiên làm việc rất lớn (hàng trăm MB), thì người dùng có thể bị bất ngờ bởi thời gian cần thiết để tải một phiên làm việc qua mạng từ lưới WebSphere Extreme Scale. Mặt khác, nếu người dùng có các phiên làm việc nhỏ, đã tuần tự hóa hóa hoàn toàn, tuân thủ các cách thực hành HttpSession tốt nhất, thì họ có thể sử dụng các ứng dụng ảo.

 

Ứng dụng có sử dụng một sản phẩm bảo mật bên ngoài hay không hoặc nó có sử dụng các API bảo mật đặc biệt như các trình cắm thêm TAI (Trust Authentication Interceptors – Các trình chặn xác thực tin cậy) hoặc JAAS hay không? Cuối cùng, một trong những thứ cần xem xét là những yêu cầu bảo mật nào được đặt ra với ứng dụng, nếu ứng dụng không có các yêu cầu bảo mật hoặc đơn giản chỉ sử dụng bảo mật WebSphere và nó cũng sử dụng một trong những đăng ký người dùng được hỗ trợ (TDS, Microsoft® Active Directory), thì người dùng có thể triển khai thực hiện hệ thống của họ như một ứng dụng ảo.

Mặt khác, nếu họ sử dụng một sản phẩm bảo mật riêng biệt như Tivoli Authentication Manager (Trình quản lý xác thực Tivoli) hoặc một trong những sản phẩm đối thủ của nó hoặc bất kỳ trong số các tính năng Bảo mật WebSphere đặc biệt nào như JAAS hoặc các TAI, thì cần lập kế hoạch xây dựng một hệ thống ảo.

 

5. Chọn cách tiếp cận đúng ở đúng thời điểm

Một điều quan trọng cần xem xét là các ứng dụng có các vòng đời, và một mô hình triển khai duy nhất không thể duy trì cho toàn bộ vòng đời của ứng dụng. Ví dụ, người dùng có thể muốn triển khai một ứng dụng trong môi trường phát triển và thử nghiệm của mình như một ứng dụng ảo để có một mô hình đơn giản nhất và để chắc chắn rằng họ bắt giữ chính xác các thông số cấu hình (như chính sách JVM) trong những môi trường đó. Tuy nhiên, họ có thể muốn triển khai ứng dụng đó trong sản xuất như một hệ thống ảo để thiết lập môi trường tối ưu hóa cao nhất cho ứng dụng này. Tương tự như vậy, họ có thể có một ứng dụng hiện có đã được triển khai như một hệ thống ảo hiện nay, nhưng trong các phiên bản mới nhất của ứng dụng, họ có thể làm theo hướng thay đổi mã của nó để làm cho nó tương thích với việc triển khai như một ứng dụng ảo.

 

6. Lập kế hoạch cho tương lai

Điều tốt nhất người dùng có thể làm trong khi lập kế hoạch về ứng dụng đã hay chưa sẵn sàng thành các ứng dụng ảo chỉ đơn giản là mất thời gian để lập kế hoạch cho qui trình này. May mắn thay, IBM sẵn sàng giúp người dùng trong suốt qui trình này. Quá trình PureExperience có một vài bước để khai triển tiếp các câu hỏi đặt ra bằng cách hỏi thêm một số câu hỏi nữa đi vào từng lĩnh vực ấy. Thông qua quá trình hỏi và trả lời này, Chuyên gia kỹ thuật phía khách của IBM (IBM Client Technical Professional) có thể giúp người dùng hiểu mô hình triển khai nào đáp ứng tốt nhất cho ứng dụng cụ thể, tương tự như vậy, IBM Software Services for WebSphere (Các dịch vụ phần mềm với WebSphere của IBM) sẵn sàng trợ giúp với các dịch vụ di trú ứng dụng và các dịch vụ khác để giúp chọn dùng Hệ thống PureApplication. Hãy liên hệ với đại diện bán hàng của IBM để được trợ giúp thêm và để bắt đầu!

 

7. Thay lời kết

Những thảo luận trên đây nhằm tùy chọn triển khai nào đáp ứng tốt nhất cho ứng dụng cụ thể của người dùng khi chuẩn bị Hệ thống PureApplication của IBM. Chính người dùng đã học phân biệt giữa các cách tiếp cận ứng dụng ảo và hệ thống ảo. Một bộ các câu hỏi cũng được cung cấp để giúp người dùng quyết định cách tiếp cận nào đúng dành cho mình.

 

(Cnth theo Tạp chí thnh)