Trong loạt bài blog được chia sẻ trước đây, các tác giả đã mô tả cách thiết lập mục tiêu chiến lược cùng các hoạt động triển khai cụ thể, hoặc các công cụ để hoàn thành mục tiêu. Tiếp đến, ta cùng xem xét một số công cụ mà Cloud Native sử dụng, bao gồm container packaging, dynamic management và microservices-oriented architecture.

Nhưng trước khi bắt đầu, ta cùng nhìn lại một số vấn đề mà doanh nghiệp cần giải quyết. 

IaaS, PaaS hay Trung tâm dữ liệu (Data Centre) riêng?

Trước khi bàn về phần mềm và công cụ, ta cần tìm hiểu chúng đang được vận hành ở đâu? Cloud Native có phải tồn tại ở trên đám mây (cloud) không? Chiến lược Cloud Native có bắt buộc phải sử dụng infrastructure-as-a-service (IaaS) hoặc platform-as-a-service (PaaS) với các máy vật lý (physical machines) được sở hữu và quản lý bởi các nhà cung cấp dịch vụ đám mây như Microsoft, Google hoặc AWS?  Hay người dùng có thể tự thiết kế các máy chủ và cơ sở hạ tầng riêng?

Các chiến lược Cloud Native thường tập trung khai thác các lợi ích về khả năng giảm thiểu rủi ro của IaaS hoặc PaaS:

• Sở hữu tốc độ nhanh khi truy cập các nguồn tài nguyên ảo, mang tính linh hoạt, có khả năng mở rộng hoặc lựa chọn tài nguyên theo ý muốn, giảm thiểu rủi ro trong quy hoạch cơ sở hạ tầng;
• Giảm chi phí đầu ra và đầu vào của dự án. Việc chuyển đổi từ CAPEX (mua hàng loạt máy trước) sang OPEX (thuê máy trong ngắn hạn nếu cần) giúp giảm thiểu rủi ro trong chiến lược dự án, qua việc giảm thiểu chi phí ngầm và dễ dàng thực hiện các chỉnh sửa hoặc thay đổi lên toàn bộ hệ thống, chiến lược;
• Cho phép truy cập vào các dịch vụ được quản lý và lưu trữ trên nền tảng đám mây, như cơ sở dữ liệu dưới dạng dịch vụ (database-as-a-service), cân bằng tải (load balancers) và tường lửa (firewalls), cũng như các dịch vụ chuyên sâu như phân tích dữ liệu hoặc học máy (machine learning), giúp hỗ trợ quá trình phát triển các sản phẩm phức tạp một cách nhanh chóng và tiện lợi. Từ đó, ta có thể nhanh chóng nắm bắt cơ hội, đồng thời giảm rủi ro khi thử nghiệm.

Với những lợi thế này, các tổ chức lớn như Google, Facebook,… đã tận dụng khai thác tại trung tâm dữ liệu của riêng họ. Tuy nhiên, quá trình này thường gặp nhiều khó khăn, tốn thời gian, chi phí và ẩn chứa nhiều rủi ro. Với phần lớn doanh nghiệp, việc mua các tiện ích dịch vụ như IaaS/PaaS từ một nhà cung cấp đám mây sẽ hiệu quả hơn. Nếu các doanh nghiệp có nhân lực để xây dựng đám mây riêng như Google hoặc AWS, liệu đó còn là cách tốt nhất?

Các hệ thống Cloud Native không nhất thiết phải chạy trên nền tảng đám mây, nhưng việc vận hành Cloud Native đòi hỏi những điều kiện phức tạp mà chỉ các nhà cung cấp dịch vụ đám mây mới có thể đáp ứng được, và rất khó để xây dựng trong nội bộ một tổ chức. Trên thực tế, có thể nói trừ Facebook, hầu hết doanh nghiệp đều đang sử dụng dịch vụ nền tảng đám mây.

Container: Giải pháp được ưa chuộng

Trong phạm vi hiện tại của Cloud Native, các ứng dụng được cung cấp, triển khai và vận hành trong cùng một bộ chứa (container). Container dùng để chỉ cách gói gọn tất cả quy trình và thư viện cần thiết để chạy một ứng dụng cụ thể trong một gói (package) duy nhất, đồng thời đặt một giao diện lên đó để giúp di chuyển. Công cụ cơ bản và phổ biến nhất để tạo ứng dụng trong container là Docker.

Container thịnh hành với ba lợi ích chính như:

Định dạng packaging tiêu chuẩn: Docker phát minh ra định dạng packaging đơn giản, giúp gói gọn ứng dụng cùng với tất cả các tính năng phụ thuộc ứng dụng vào một khối duy nhất, đồng bộ trên mọi hệ điều hành. Định dạng thông dụng này khuyến khích doanh nghiệp và startup phát triển các công cụ mới để tạo, quét và thao tác trên các ứng dụng được bộ chứa hóa (containerised application). Định dạng Docker hiện nay là thước đo thực tế cho việc đóng gói các containerised application. Các gói Docker hoặc “Images” đang được dùng trên hầu hết các hệ điều hành, và sở hữu hàng loạt công cụ xây dựng, triển khai và vận hành từ nhiều nhà cung cấp khác nhau. Người dùng sẽ sử dụng mã nguồn mở để định dạng và triển khai “Images”. Những container images trên có tính “bất biến” – tức là một khi chúng được chạy, người dùng không thể thay đổi hoặc chắp vá. Dưới góc độ bảo mật, đây là một ưu điểm rất đáng ghi nhận.

Cô lập ứng dụng nhẹ mà không cần máy ảo (VM): Người dùng sử dụng “container engine” như Docker’s Engine hoặc CoreOS’s rkt để chạy một containerised application package (hay còn gọi là images) trên một máy. Tuy nhiên, một engine không chỉ được sử dụng cho việc giải nén hay chạy các quy trình package. Trong lúc một container engine đang chạy application image, engine này đồng thời sẽ giới hạn những gì ứng dụng có thể thấy và thực hiện trên máy. Container engine có thể đảm bảo các ứng dụng sẽ không tác động tiêu cực lên nhau như lỗi ghi đè các thư viện quan trọng hoặc cạnh tranh các nguồn tài nguyên. Một ứng dụng container đang chạy sẽ hoạt động gần giống như một ứng dụng chạy trong một máy ảo VM cơ bản, nhưng thực chất không phải vậy – quá trình cô lập được ứng dụng bởi quy trình container engine, nhưng được thực hiện trực tiếp bởi nhân hệ điều hành máy chủ (host kernel). Một container image sau khi chạy sẽ trở thành “container” và mang tính tạm thời – khác với VM, container chỉ tồn tại khi được vận hành. Khác với các máy ảo có dung lượng nặng, một container có thể mở và đóng cực kỳ nhanh chỉ trong vài giây. Tiềm năng để tạo và hủy nhanh các container được gọi là fast instantiation và đây cũng là nền tảng cơ bản cho quá trình quản lý động (dynamic management);

Giao diện điều khiển ứng dụng tiêu chuẩn: Một tiện ích không kém phần quan trọng là container engine cung cấp giao diện tiêu chuẩn để điều khiển các container đang vận hành. Điều này có nghĩa, các công cụ của bên thứ ba có thể khởi động và dừng các containerised applications hoặc thay đổi tài nguyên liên quan đến ứng dụng. Khái niệm về giao diện điều khiển chung cho bất kỳ ứng dụng nào chạy trên bất kỳ hệ điều hành nào là cực kỳ cơ bản, và cũng rất quan trọng đối với quản lý động – dynamic management.

Khi kết hợp với nhau, 3 cải tiến này đã thay đổi các định kiến về cách các trung tâm dữ liệu đang được vận hành và về tốc độ triển khai các ứng dụng mới.

Các lựa chọn thay thế cho Containers

Các khái niệm về đóng gói ứng dụng được chuẩn hóa (standardised application packaging), cô lập (isolation) và kiểm soát đã được làm rõ. Bên cạnh đó, một số phương pháp tiếp cận thay thế đang được phát triển để cung cấp một số tính năng tương tự, như là:

• Các sản phẩm phi máy chủ hoặc đóng vai trò như dịch vụ (FaaS), ví dụ như AWS Lambda (dịch vụ đám mây chạy các đoạn mã theo yêu cầu xác định của người dùng);
• Unikernels và ilk (các gói ứng dụng với khả năng tự cung cấp, bao gồm hệ điều hành bắt buộc tối thiểu);
• Các ứng dụng bên trong máy ảo VM mới sở hữu dung lượng nhẹ hơn.

Ngoài ra, một số loại container khác nhau của Docker, hay các phương pháp khác giúp tận dụng lợi ích của container chắc chắn sẽ ngày càng được phát triển trong thời gian tới. Tuy nhiên, điều quan trọng hơn hết đối với các doanh nghiệp là nắm được được lợi thế của việc đóng gói chung, giao diện điều khiển và cô lập ứng dụng, để thậm chí 5 năm sau, người dùng vẫn có thể sử dụng công cụ khác không phải container mà vẫn tận dụng được các tính năng này.

Ở một khía cạnh khác, để tránh nhầm lẫn, dù giao diện quản lý Docker Image luôn đồng nhất trên hệ điều hành, nội dung của image không nhất thiết phải mang tính di động. Nội dung của container image là một tập hợp các tập tin thực thi. Ví dụ, một Linux image sẽ chỉ bao gồm các tệp thực thi được biên dịch để chạy trên Linux. Windows image sẽ chỉ bao gồm các exes và dlls được biên dịch để chạy trên Windows. Do đó, người dùng không thể chạy container image của Linux trên Windows hoặc container image của Windows trên Linux, trừ khi người dùng đã cài đặt tập thực thi của loại này trên loại kia. Tuy nhiên, khi các container đang chạy trên hệ điều hành máy chủ thích hợp, người dùng có thể kiểm soát container với cùng một định dạng lệnh gọi API. 

Công cụ container không phải là một môi trường như ngôn ngữ lập trình Java. Một container vận hành theo những lập trình tự nhiên trên máy chủ lưu trữ, vì vậy các tệp thực thi phải được xây dựng cho hệ điều hành đó.

Container có thể sử dụng tốt như một máy ảo VM không?

Để làm rõ quan điểm ở đây, VM có những lợi thế vượt trội rõ rệt hơn hẳn container. Tuy nhiên, có thể kể đến một số nhược điểm của VM như:

• “Cồng kềnh” hơn các container;
• Tiêu thụ nhiều tài nguyên máy chủ để chạy, và mất nhiều thời gian hơn để bắt đầu và dừng lại, so với một container.

Xét về ưu điểm, máy ảo VM vẫn là một công nghệ hoàn thiện và chỉn chu hơn hẳn, với nhiều năm được nghiên cứu tìm hiểu để phát triển. Ngoài ra, các container tuy được cô lập với các quy trình nhưng không hoàn toàn – đặc biệt là đối với các antagonistic applications. Phương pháp tiếp cận bằng VM dung lượng nặng ở trường hợp này có thể là một lựa chọn an toàn hơn.

Tại sao mọi người lại “phát sốt” với container?

Lý do khiến mọi người yêu thích container không chỉ nằm ở định dạng packaging ổn hay phù hợp với việc triển khai tự động, các container còn cung cấp cho người dùng khả năng cô lập ứng dụng nhẹ và một API kiểm soát ứng dụng (application control API). Kết hợp với quản lý động – dynamic management – container có thể mang lại khả năng tự động hóa, khả năng phục hồi và tối ưu hoá tài nguyên sử dụng, vừa thân thiện vừa tiết kiệm chi phí.

Về VTI Cloud

VTI Cloud là Đối tác cấp cao (Advanced Consulting Partner) của AWS, với đội ngũ hơn 50+ kỹ sư về giải pháp được chứng nhận bởi AWS. Với mong muốn hỗ trợ khách hàng trong hành trình chuyển đổi số và dịch chuyển lên đám mây AWS, VTI Cloud tự hào là đơn vị tiên phong trong việc tư vấn giải pháp, phát triển phần mềm và triển khai hạ tầng AWS cho khách hàng tại Việt Nam và Nhật Bản.

Xây dựng các kiến trúc an toàn, hiệu suất cao, linh hoạt, và tối ưu chi phí cho khách hàng là nhiệm vụ hàng đầu của VTI Cloud trong sứ mệnh công nghệ hóa doanh nghiệp.

Liên hệ với chúng tôi: Tại đây

Nguồn: Anne Currie từ blog.container-solutions.com