Có nhiều định nghĩa đặt ra cho CNA nhưng chỉ cần hiểu đơn giản CNA là một app thuần cloud. Dưới góc nhìn high level, nó là app được thiết kế để chạy trên môi trường cloud.

Nhìn rộng ra thì nó có thể chạy được trên nhiều môi trường cloud, thậm chí có thể được triển khai theo kiến trúc phân tán (distributed) trên nhiều môi trường cloud để tận dụng tối đa các nguồn lực mà cloud mang lại.

CNA còn được định nghĩa trong Beyond the twelve-factor app như sau:

A cloud-native application is an application that has been designed and implemented to run on a Platform-as-a-Service installation and to embrace horizontal elastic scaling.

Các ứng dụng ngày càng trở nên phức tạp với nhu cầu ngày càng cao của người dùng; Người dùng mong đợi khả năng đáp ứng nhanh chóng, các tính năng hữu ích và không có downtime. Tốc độ và sự linh hoạt của CNA đến từ một số yếu tố sau:

Table of contents

Microservices

Thiết kế các app theo kiến trúc microservices mang lại cho hệ thống rất nhiều lợi ích và cũng đang là xu hướng thời thượng vì đơn giản rất nhiều sản phẩm của các hãng lớn đã và đang theo con đường này.

Một app dưới góc nhìn tổng quát chính là sự tổng hòa của một hoặc nhiều component. CNA cũng không ngoại lệ, để app phù hợp với môi trường cloud thì kiến trúc microservice là điều không thể tránh khỏi khi thiết kế CNA.

CNA cần phải được thiết kế theo kiến trúc microservice để phù hợp với môi trường cloud. Với các cloud app được phát triển trong thời gian gần đây, kiến trúc microservice luôn là sự lựa chọn tối ưu. Đối với các legacy app, việc cần làm là tách rời các component và tái thiết kế chúng theo kiến trúc microservice.

Một số lợi ích mà microservices mang lại:

• Mỗi microservice có một vòng đời riêng, có thể phát triển độc lập và deploy thường xuyên.
• Không cần phải đợi bản phát hành hàng quý để triển khai các tính năng hoặc bản cập nhật mới. Thay vào đó có thể cập nhật một phần nhỏ của một ứng dụng phức tạp với ít nguy cơ làm gián đoạn toàn bộ hệ thống hơn.
• Mỗi microservice có thể mở rộng quy mô độc lập. Thay vì mở rộng toàn bộ ứng dụng thành một đơn vị duy nhất, chỉ cần mở rộng quy mô những dịch vụ cần thiết (CPU, Memory, Network Bandwidth).
• Cách tiếp cận chi tiết để mở rộng quy mô này cung cấp khả năng kiểm soát hệ thống tốt hơn và giúp giảm chi phí tổng thể khi mở rộng quy mô các phần của hệ thống chứ không phải tất cả mọi thứ.

Modern Design

Câu hỏi đặt ra là Thiết kế một Cloud Native App như thế nào? Kiến trúc trong ứng dụng ra sao? Những nguyên tắc, pattern và phương pháp nào cần được tuân thủ?

Một phương pháp được chấp nhận rộng rãi để xây dựng các Cloud Native App là The Twelve-Factor App. Nó mô tả một tập hợp các nguyên tắc và best practice mà các developers tuân theo để xây dựng các ứng dụng được tối ưu hóa trong modern cloud.

The Twelve-Factor App có thể được áp dụng cho các ứng dụng được viết bằng bất kỳ ngôn ngữ lập trình nào và sử dụng bất kỳ sự kết hợp nào của các dịch vụ hỗ trợ (database, queue, memory cache, etc).

Dưới đây là các yếu tố được đề cập đến:

Tuy nhiên 12 yếu tố ban đầu (từ 2011) được đề cập ở trên vẫn chưa đủ đối với thiết kế Cloud Native App ngày nay. Thêm vào đó có 3 yếu tố được bổ sung thêm:

Ngoài 15 yếu tố trên, còn có những cân nhắc quan trọng trong thiết kế CNA:

• Communication — Giao tiếp giữa các ứng dụng front-end và back-end, internal services; khả năng kiểm soát bảo mật trong giao tiếp; xem xét việc kết nối trực tiếp hay tách rời (message broker).
• Resiliency — Khả năng phục hồi của các microservice; trong kiến trúc phân tán, điều gì sẽ xảy ra khi Service B không phản hồi Service A, Service C tạm thời gián đoạn khiến cho các service khác không thể kết nối.
• Distributed Data — Theo chuẩn kiến trúc microservice, mỗi microservice sẽ được đóng gói với database của chính nó. Xảy ra TH có nhiều microservice cần truy vấn dữ liệu hoặc thực hiện một giao dịch.
• Identity — Trong mạng lưới các microservice, các microservice có thực sự “trust” nhau không? Một service làm thế nào để xác định ai đang yêu cầu truy cập và có quyền gì?

Containers

Đây là thành phần không thể thiếu trong Cloud Native App, giúp cho việc đóng gói một microservice trở nên đơn giản hơn bao giờ hết. Các thành phần của một service app như code, dependencies,… sẽ được đóng gói vào trong một container image duy nhất và lưu trữ trong container registry.

Container image có thể chạy trên bất kỳ máy chủ (cài sẵn Docker) bằng cách kéo chúng về từ container registry. Sự thuận tiện này khiến cho Docker trở thành tiêu chuẩn thực tế để đóng gói, triển khai Cloud Native App.

Container Orchestration

Trong khi các công cụ như Docker tạo ra images và chạy các containers, Chúng ta cũng cần các công cụ để quản lý chúng. Quản lý container được thực hiện bằng một giải pháp được gọi là container orchestrator. Khi hoạt động ở quy mô lớn, việc điều phối container là điều cần thiết. Hiện nay có nhiều công cụ hỗ trợ điều phối container, tuy nhiên nổi bật về orchestration thì có 3 giải pháp đó là Docker Swarm, Kubernetes và Nomad.

Đa số các Container Orchestration đều có nhiệm vụ và chức năng giống nhau:

Có thể thấy 2 yếu tố được đặt ra trong The Twelve-Factor App được áp dụng cho Container Orchestration và sự liên quan của chúng:

• Concurrency — Các service mở rộng quy mô trên một số lượng lớn các quy trình nhỏ giống hệt nhau (bản sao) thay vì mở rộng quy mô một phiên bản lớn duy nhất trên máy cấu hình mạnh.
• Disposability — App có khả năng dùng một lần, có nghĩa là chúng có thể được khởi động hoặc dừng ngay lập tức. Thời gian khởi động ngắn mang lại sự nhanh nhẹn hơn cho quá trình release và mở rộng quy mô.

Automation

Các hệ thống Cloud Native bao gồm các microservices, containers, modern system design để đạt được tốc độ và sự linh hoạt. Nhưng vấn đề tiếp theo chính là cung cấp cơ sở hạ tầng để hệ thống chạy và triển khai nhanh chóng các tính năng bản cập nhật của ứng dụng.

Trong Cloud Native đề cập đến 2 thành phần tự động hoá quan trọng đó là:

• Tự động hoá cơ sở hạ tầng
• Tự động hoá triển khai

Tự động hoá cơ sở hạ tầng

Khi triển khai Cloud Native App trên cloud, các thành phần cơ sở hạ tầng cần phải được tạo và cấu hình đầy đủ (ví dụ như storage, network, security group,…) để một ứng dụng có thể chạy được.

Đối với các nhà cung cấp public cloud (AWS, Azure, Google Cloud, etc) hay private cloud (được dựng bởi Openstack); việc tạo các tài nguyên sẽ phải tự làm bằng tay (truy cập vào UI console rồi click, config, cài cắm từng bước,…)

Tuy nhiên với giải pháp IaC (Infrastructure as Code), việc cung cấp nền tảng, cơ sở hạ tầng cho ứng dụng sẽ hoàn toàn được tự động hoá.

Các công cụ trong giải pháp IaC phổ biến như Cloudformation (dùng cho AWS service) và Terraform (dùng cho mọi cloud) cho phép viết kịch bản khai báo cơ sở hạ tầng cloud; resource name, location, storage, secret, etc được tham số hoá và tự động.

Các script cung cấp một cơ sở hạ tầng được nhất quán và có thể lặp lại trên các môi trường hệ thống, chẳng hạn như QA, staging và production. Với khả năng automate, IaC được tích hợp vào quy trình CI/CD để xây dựng hạ tầng một cách nhanh chóng. Chỉ cần start một Jenkins pipeline là infra được build lên.

Tự động hoá triển khai

Yếu tố số 5 trong The Twelve-Factor App được nhắc đến như sau:

Mỗi phiên bản release phải được phân tách qua các giai đoạn build, release, và run; mỗi version phải được đánh tag và hỗ trợ khả năng rollback khi cần.

Triển khai hệ thống CI/CD sẽ giúp thực hiện nguyên tắc này. Thực hiện cung cấp các bước triển khai riêng biệt và giúp đảm bảo code chất lượng và nhất quán sẵn có cho người dùng.

Nhiều hệ thống đã chuyển từ release hàng quý sang on-demand updates. Mục đích là để phát hiện sớm các vấn đề trong chu kỳ phát triển, bớt tốn kém hơn để sửa chữa. Khoảng thời gian giữa các lần tích hợp càng dài, các vấn đề càng trở nên tốn kém hơn để giải quyết.

Với sự nhất quán trong quá trình tích hợp, các team có thể cam kết thay đổi code thường xuyên hơn, dẫn đến chất lượng phần mềm và cộng tác tốt hơn.

Reference

• https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
• https://edwardthienhoang.wordpress.com/2020/05/17/tan-man-ve-cloud-native/