Bài viết tập trung nhìn vào sự phù hợp của nền tảng Microsoft Azure để triển khai các ứng dụng cloud-native
Chuyển sang đám mây là một khía cạnh cần xem xét. Mặc dù ngày nay, có sự nhất trí cho rằng các ứng dụng cloud-native mang lại những lợi ích ưu việt nhất giúp tăng tính linh hoạt trong kinh doanh. Nhưng cloud-native lại được liên kết với các ứng dụng Linux và công nghệ vùng chứa (container technology). Vậy nền tảng Azure của Microsoft thích hợp để triển khai cloud-native như thế nào?
Thuật ngữ ứng dụng “cloud-native” mặc dù không chính xác, nhưng được sử dụng vì cần phân biệt giữa việc di chuyển và chuyển đổi các ứng dụng hiện có sang nền tảng đám mây với việc tái kiến trúc các ứng dụng để có giá trị kinh doanh tối ưu trong môi trường đám mây. Tổ chức Cloud Native Computing Foundation (CNCF) cho biết trong định nghĩa của thuật ngữ này có viết: “Công nghệ Cloud-native trao quyền cho các tổ chức xây dựng và chạy các ứng dụng có thể mở rộng trong môi trường hiện đại, năng động như đám mây công cộng (public), đám mây riêng (private) và đám mây lai (hybrid). Các vùng chứa (container), các service mesh, các microservice, cơ sở hạ tầng không thay đổi và các giao diện lập trình ứng dụng (API) khai báo là các ví dụ minh họa cho cách tiếp cận này. Những kỹ thuật này kích hoạt các hệ thống ghép đôi lỏng, có khả năng quản lý và có thể quan sát được. Kết hợp với tự động hóa mạnh mẽ, chúng cho phép các kỹ sư phần mềm tạo ra những thay đổi có tác động lớn một cách thường xuyên và nằm trong khả năng dự đoán của họ ở mức tối thiểu.”
Khái niệm chính
Bao hàm trong định nghĩa này là một số khái niệm chính. Có lẽ quan trọng nhất là microservice, ý tưởng về việc tạo các ứng dụng từ nhiều microservice và do đó dễ dàng quản lý và cập nhật. Điều này có một số lợi thế. Thứ nhất đó là sự linh hoạt, như sửa đổi một mô-đun nhỏ nhanh hơn và an toàn hơn so với việc sửa đổi một bộ mã lớn và phức tạp. Thứ hai là khả năng mở rộng, vì mỗi dịch vụ có thể được theo dõi và thu nhỏ riêng biệt, cho phép các tài nguyên được thêm vào chính xác nơi cần chúng. Thứ ba, bằng cách xây dựng khả năng kháng lỗi trong mỗi dịch vụ, có thể được tạo ra các ứng dụng đàn hồi (resilient application).Nhưng mặt khác vẫn còn điểm hạn chế, do các ứng dụng phân tán có tính phức tạp và do chi phí quản lý nhiều cá thể thành phần.Các quyết định về kiến trúc phù hợp cho một ứng dụng bị ảnh hưởng bởi nhiều yếu tố, bao gồm cả mức độ quan trọng của doanh nghiệp và công suất làm việc dự kiến. Tin tốt là nền tảng đám mây hiện đại cho phép các ứng dụng nhỏ có khả năng phục hồi và khả năng mở rộng gần như miễn phí, ví dụ như việc bạn sử dụng các dịch vụ ứng dụng như Dịch vụ ứng dụng Azure của Microsoft hoặc Elastic Beanstalk của Amazon, thay vì phụ thuộc vào máy ảo (VM ) để lưu trữ ứng dụng trực tiếp.Làm thế nào để triển khai một microservice? Trong nhiều trường hợp, vùng chứa là đơn vị triển khai lý tưởng. Chúng nhẹ hơn nhiều so với máy ảo, tương đối biệt lập và có thể tự động hóa. Vùng chứa cung cấp một môi trường có thể dự đoán được xác định bởi nhà phát triển và được chỉ định trong mã code. Điều này cho phép sử dụng phương pháp “infrastructure as code”, và cũng cho phép cơ sở hạ tầng bất biến được tham chiếu bởi CNCF. Cơ sở hạ tầng là bất biến khi bạn không thay đổi mà chỉ thay thế nó.Container technology lần đầu tiên được phát triển dành cho Linux. Trong Windows Server 2016, Microsoft đã giới thiệu Windows Server Containers. Có hai loại vùng chứa trên Windows. Cùng với các vùng chứa tiêu chuẩn (hiệu quả tối đa), các vùng chứa Hyper-V cải thiện sự khử ghép (isolation) và bảo mật với chi phí chia sẻ tài nguyên thấp hơn. Việc triển khai một vùng chứa rất dễ dàng nhờ Docker – một công cụ khởi tạo và chạy một vùng chứa được xác định trong tệp cấu hình có tên là Dockerfile. Điều đó nói lên rằng, nếu bạn có một ứng dụng bao gồm hàng trăm hoặc hàng nghìn thực thể vùng chứa, với các yêu cầu về khả năng phục hồi, khả năng mở rộng và sử dụng hiệu quả tài nguyên, thì việc triển khai các vùng chứa đó theo cách thủ công là hoàn toàn không thể. Thay vào đó, bạn cần một công cụ để phối hợp các vùng chứa, và một discovery service để báo cho các microservice biết cách để tìm thấy nhau.Có một số công cụ tương tự như Kubernetes, Docker Swarm và Mesosphere DC/OS. Trong đó, Kubernetes, có nguồn gốc từ Google và hiện đang là một dự án mã nguồn mở được quản lý bởi CNCF, đã trở thành công cụ được lựa chọn nhiều nhất, nhưng không phải trong mọi trường hợp. Như bạn mong đợi, các nền tảng đám mây công cộng lớn đã nhanh chóng cung cấp hỗ trợ ưu tiên nhất cho cả vùng chứa và Kubernetes. Microsoft cũng không là ngoại lệ, và đám mây công cộng Azure của nó hiện cung cấp hỗ trợ tích cực cho các vùng chứa và microservice.
Microsoft có nhiều giải pháp cho các ứng dụng cloud-native trên Azure. Một là giải pháp ‘cây nhà lá vườn’ Service Fabric. Giải pháp thứ hai, thường được gọi là Azure Container Service, hỗ trợ Kubernetes và Mesosphere DC/OS. Với sự đi lên của Kubernetes, đây cũng được gọi là Dịch vụ Kubernetes Azure (AKS).Một lựa chọn khác là Pivotal Cloud Foundry, được ra đời nhờ vào mối quan hệ đối tác giữa Microsoft và Pivotal, và với sự hỗ trợ cho các ứng dụng Linux và Windows. Cloud Foundry tham gia vào quá trình chuyển đổi từ container orchestrator riêng của mình, được gọi là Diego, thành Kubernetes. Vì vậy, đây là một đường truyền khác để đến với microservice/Kubernetes trên Azure.Một dịch vụ được sử dụng chung bởi tất cả các nền tảng vùng chứa Azure là Azure Container Registry (ACR). Hình ảnh vùng chứa trong ACR có thể được triển khai bằng Kubernetes, Service Fabric, Docker Swarm, DC/OS, Azure App Service, v.v. ACR hỗ trợ Docker Registry 2 CLI (Command Line Interface – Giao diện dòng lệnh).Một tính năng chính của ACR là Tasks, cho phép bạn kích hoạt hình ảnh vùng chứa tự động được xây dựng để đáp ứng với các sự kiện như gửi mã tới kho lưu trữ GitHub hoặc cập nhật hình ảnh cơ sở mà các vùng chứa khác phụ thuộc vào. Ở chế độ xem trước hiện có các tác vụ nhiều bước, cho phép bạn thêm các bước như kiểm tra và xác thực hình ảnh trước khi triển khai.ACR hiện cũng có hỗ trợ xem trước cho Open Container Initiative, một bộ tiêu chuẩn chung cho hình ảnh vùng chứa.
Cả hai Service Fabric và AKS có một tương lai mạnh mẽ. Service Fabric được đặt sâu vào cơ sở hạ tầng Azure. Nó được sử dụng trong Azure Active Directory, dịch vụ thư mục cho Office 365 và các ứng dụng khác bao gồm Cosmos DB, NoSQL của Microsoft, trình quản lý cơ sở dữ liệu đa mô hình. Tương tự, Kubernetes cũng là tiêu chuẩn công nghiệp không chính thức (de facto industry standard) và việc sử dụng nó chắc chắn phát triển thêm trong tương lai.Microsoft mô tả Azure Service Fabric như là một “nền tảng hệ thống phân tán giúp dễ dàng đóng gói, triển khai và quản lý các dịch vụ và vùng chứa có thể mở rộng và đáng tin cậy”. Điều này bao gồm một orchestrator (còn gọi là Service Fabric) và các dịch vụ discovery container-to-container.Service Fabric Mesh, một dịch vụ được quản lý hoàn toàn cho các ứng dụng microservice đang đươc̣ triển khai ở chế độ xem trước. Các nền tảng Microservice sử dụng các cụm (cluster) để triển khai các vùng chứa. Service Fabric Mesh tóm tắt việc quản lý cụm sao để bạn chỉ cần chỉ định các tài nguyên, giới hạn tài nguyên và các yêu cầu về tính khả dụng. Dịch vụ Fabric Mesh hỗ trợ cả vùng chứa Windows và Linux.Tại hội nghị Ignite vào tháng 9, Microsoft đã công bố một số cải tiến cho Mesh, bao gồm khả năng gắn kết các tệp Azure (lưu trữ tệp Azure-hosted) và lưu trữ có khả năng phục hồi cao được gọi là Service Fabric Volume Disk.Quản lý ứng dụng Kubernetes
Trong thế giới Kubernetes, Helm là một giải pháp để quản lý các ứng dụng Kubernetes sử dụng Biểu đồ, trong đó Biểu đồ là một dạng đóng gói để mô tả các tài nguyên của Kubernetes. Biểu đồ giúp dễ dàng triển khai, phát hành và phục hồi các ứng dụng Kubernetes.
Tại Ignite, Microsoft đã công bố hỗ trợ cho các kho lưu trữ Helm, hiện đang ở chế độ xem trước. Bảng xếp hạng Helm có thể được lưu trữ trong ACR.Công ty cũng đã công bố hỗ trợ Kubernetes trên Azure Stack, đóng gói một tập hợp con các dịch vụ Azure của Microsoft để cài đặt tại chỗ tại chỗ.Vì vậy, nếu bạn đã có quyết định đối với Azure, bạn có nên triển khai ứng dụng cloud-native của mình lên Service Fabric hoặc Kubernetes không?
Đôi khi quyết định này phụ thuộc vào kỹ năng mà bạn có. Kubernetes là một tiêu chuẩn của ngành, trong khi Fabric Service là duy nhất đối với Azure, vì vậy Kubernetes có nhiều khả năng được biết đến nhiều và rõ hơn.Mô hình ứng dụng là một yếu tố khác. Kubernetes có thể hỗ trợ các vùng chứa Windows, nhưng nó là định hướng Linux. Nếu một ứng dụng được viết cho Java và Linux, thì Kubernetes sẽ phù hợp hơn nếu nó được xây dựng với .Net Framework và Windows.
Fabric Service, theo một nghĩa nào đó, là nền tảng gốc của Azure. Nó là sự phù hợp tự nhiên đối với các vùng chứa Windows Server, mặc dù cũng hỗ trợ Linux. Nếu ứng dụng của bạn được viết bằng .Net và sử dụng nhiều dịch vụ Azure, thì Service Fabric là một sự phù hợp.Tổng kết
Service Fabric Mesh chưa sẵn sàng để được đưa sản xuất, nhưng nó là một nỗ lực thú vị để trừu tượng hóa sự phức tạp của việc quản lý các ứng dụng dựa trên microservice quy mô cao, đồng thời giữ lại các lợi ích của chúng. Tuy nhiên, lưu ý rằng cộng đồng Kubernetes cũng tham gia vào các nỗ lực để giảm bớt gánh nặng quản lý và cấu hình và tiến gần hơn đến một lý tưởng “chỉ chạy mã”.
Giám đốc điều hành CNCF Dan Kohn nói với Computer Weekly: “Một trong những chủ đề nhất quán của các nhà lãnh đạo trong cộng đồng là cách triển khai ứng dụng hiện tại trên Kubernetes – bạn xây dựng vùng chứa này và sau đó bạn viết một số YAML – không phải là trừu tượng chính xác lớp mà hầu hết các nhà phát triển nên giải quyết. Nhưng không có sự đồng thuận về giải pháp tốt hơn.”Đây là sân chơi của Service Fabric Mesh, và cho thấy rằng mặc dù Kubernetes là một tiêu chuẩn chung, chúng ta vẫn có lý do chính đáng để sử dụng các phương pháp tiếp cận khác. Nguồn bài viết : https://www.computerweekly.com
