5 Nguyên tắc kiến trúc Cloud Native

Thuật ngữ “kiến trúc Cloud Native” thường được xem như là đích đến cuối cùng cho các ứng dụng di chuyển hoặc xây dựng trên Google Cloud Platform (GCP). Chính xác thì cloud native nghĩa là gì? Làm thế nào để thiết kế một hệ thống như vậy?

“Kiến ​​trúc cloud native” đồng nghĩa với việc thích nghi với nhiều yếu tố mới. Nhưng ràng buộc bởi các yêu cầu khác nhau đưa ra bởi đám mây. Dưới đây là 3 yếu tố thường được cân nhắc khi nói đến cloud native:

• Những yêu cầu chức năng của hệ thống (những gì nên làm)
• Những yêu cầu phi chức năng (nên làm như thế nào)
• Các ràng buộc (phạm vi thay đổi là gì)

Bài viết này đưa ra 5 nguyên tắc của kiến trúc cloud native giúp đảm bảo các thiết kế của bạn tận dụng được lợi ích của đám mây. Bên cạnh đó, có thể tránh được nhược điểm của các cách tiếp cận cũ trên nền tảng mới.

Các nguyên tắc kiến trúc cloud native

Nguyên lý này tập trung vào việc tối ưu hóa kiến trúc hệ thống của đám mây. Kiến trúc theo cách truyền thống có xu hướng tối ưu hóa cho cơ sở hạ tầng cố định và có chi phí cao. Ngoài ra còn đòi hỏi nỗ lực thủ công đáng kể để sửa đổi. Do đó, kiểu truyền thống tập trung vào khả năng phục hồi và hiệu suất của các thành phần cố định tương đối nhỏ.

Tuy nhiên, trên đám mây, cơ sở hạ tầng cố định không có nhiều ý nghĩa. Vì chi phí đám mây được tính dựa trên việc sử dụng. Sử dụng bao nhiêu chi trả bấy nhiêu. Cũng dễ dàng tự động scaling up down hơn. Do đó, kiến ​​trúc cloud native tập trung vào việc đạt được khả năng phục hồi và quy mô. Bất kể là scale theo chiều ngang, xử lý phân tán và tự động thay thế các thành phần hư hỏng. Cùng xem qua các nguyên tắc sau nhé.

Nguyên tắc 1: Thiết kế cho tự động hóa

Tự động hóa luôn là best practice cho các hệ thống phần mềm. Đám mây giúp việc tự động hóa cơ sở hạ tầng trở nên dễ dàng hơn. Dù khoản trả trước thường cao hơn, nhưng trong trung hạn sẽ mang lại kết quả tốt liên quan đến khả năng phục hồi và hiệu suất của hệ thống. Các quy trình tự động có thể sửa chữa, mở rộng, triển khai hệ thống nhanh hơn so với việc thực hiện bởi con người. Một số lĩnh vực phổ biến cho tự động hóa:

• Cơ sở hạ tầng

  Tự động hóa việc tạo và cập nhật cơ sở hạ. Sử dụng các công cụ như Google Cloud Deployment Manager hay Terraform

• Tích hợp liên tục / Delivery liên tục

  Tự động hóa việc xây dựng, thử nghiệm và triển khai các gói tạo hệ thống. Bằng cách sử dụng các công cụ như Google Cloud Build, Jenkins và Không chỉ tự động hóa việc triển khai, bạn còn cần tự động hóa quá trình canary testing và rollback.

• Scale up và scale down

  Trừ khi hệ thống tải không bao giờ thay đổi, thì nên tự động hóa hệ thống scaling để phản hồi khi tải tăng lên hoặc xuống. Scaling up giúp đảm bảo hệ thống được vận hành trơn tru và scaling down giúp tiết kiệm chi phí. Điều này cần thiết đối với các ứng dụng quy mô lớn. Nhưng cũng quan trọng cho các ứng dụng nhỏ hơn có tải không đều. Ví dụ như các ứng dụng nội bộ hoạt động nhiều trong các giai đoạn nhất định, nhưng một số ứng dụng khác thì không.

• Theo dõi và tự động phục hồi

  Nên tích hợp việc theo dõi và đăng nhập vào hệ thống cloud native từ ban đầu. Đăng nhập và theo dõi luồng dữ liệu có thể được sử dụng để theo dõi sức khỏe của hệ thống. Ngoài ra còn có các lợi ích vượt trội khác. Như cung cấp những hiểu biết có giá trị về việc sử dụng hệ thống và hành vi người dùng. Có bao nhiêu người đang sử dụng hệ thống, sử dụng những gì, độ trễ trung bình bao nhiêu,….Bên cạnh đó còn đưa ra thước đo về sức khỏe toàn bộ hệ thống. Ví dụ: ổ chứa sắp đầy, nhưng nó có đầy nhanh hơn bình thường không? Cuối cùng là tự động attach. Khi ổ chứa đầy, thay vì chỉ ghi lỗi, có thể tự động thay đổi kích thước ổ đĩa để cho phép hệ thống tiếp tục hoạt động.

Nguyên tắc 2: Hiểu về trạng thái hệ thống

Trạng thái lưu trữ (ví dụ: các mục trong giỏ hàng của người dùng hoặc số nhân viên của họ). Hoặc trạng thái hệ thống (ví dụ: có bao nhiêu instance đang chạy, phiên bản code nào đang chạy trong production). Đây là những việc khó khăn nhất của một kiến ​​trúc phân tán cloud native. Do đó, nên xây dựng hệ thống thể hiện rõ thời điểm, cách thức và trạng thái lưu trữ. Thiết kế các thành phần không trạng thái (stateless) bất cứ nơi nào có thể.

Các thành phần stateless dễ xây dựng gồm:

• Scale: để scale up, chỉ cần thêm các bản sao. Để scale down, điều hướng instance tự chấm dứt khi hoàn thành công việc.
• Sửa chữa: để sửa chữa instance hư hỏng của một thành phần, đơn giản chỉ cần chấm dứt và thay thế bằng instance khác.
• Thu hồi (Roll-back): Nếu triển khai không tốt, các thành phần stateless dễ dàng được thu hồi. Ta có thể chấm dứt và thay vào đó triển khai các instance của phiên bản cũ.
• Cân bằng tải (Load-balance across): khi các thành phần không có trạng thái, cân bằng tải dễ dàng hơn nhiều vì bất kì instance nào cũng có thể xử lý các yêu cầu.

Nguyên tắc 3: Các dịch vụ quản lý yêu thích

Cloud không chỉ đơn giản là hạ tầng. Đa số nhà cung cấp Cloud đưa ra các gói dịch vụ cung cấp hầu hết chức năng. Giải quyết nhẹ bớt các vấn đề quản lý phần mềm backend và hạ tầng.

Nói rộng hơn, quyết định có thuê dịch vụ quản lý hay không còn cần xem lại khả năng di động và vận hành. Liên quan đến khả năng tài chính và các kỹ năng. Hiện tại, các dịch vụ quản lý người dùng nên cân nhắc là:

• Nguồn mở được quản lý và các dịch vụ tương thích với nguồn mở: các dịch vụ được quản lý bởi nguồn mở. Ví dụ Cloud SQL hay giao diện tương thích với nguồn mở Cloud Bigtable. Đây là sự lựa chọn dễ dàng vì có nhiều lợi ích và ít rủi ro.
• Dịch vụ quản lý với chi phí tiết kiệm: một vài dịch vụ không tương thích ngay với nguồn mở hay không có sự thay thế nguồn mở ngay lập tức. Nhưng rất dễ sử dụng hơn các lựa chọn thay thế. Chẳng hạn, BigQuery thường được các tổ chức sử dụng vì dễ vận hành.
• Những vấn đề khác: có những trường hợp khó di chuyển dễ dàng ra khỏi dịch vụ, hoạt động kém hiệu quả hơn. Cần phải xem xét từng trường hợp.

Nguyên tắc 4: Thực hành phòng thủ chuyên sâu

Các kiến ​​trúc truyền thống đặt nhiều niềm tin vào bảo mật ngoại vi. Nhưng cách tiếp cận này luôn dễ bị tấn công nội bộ. Cũng như các mối đe dọa bên ngoài như lừa đảo giả mạo. Hơn nữa, áp lực ngày càng tăng để cung cấp tính linh hoạt và di động đã làm suy yếu thêm mạng ngoại vi.

Kiến trúc cloud native có nguồn gốc từ các dịch vụ trực tuyến. Do đó luôn cần phòng thủ các cuộc tấn công bên ngoài, áp dụng cách tiếp cận chuyên sâu. Bằng cách sử dụng phương thức xác thực giữa từng thành phần. Giảm thiểu sự tin tưởng giữa các thành phần đó (ngay cả khi là ‘nội bộ’). Kết quả là, không có “bên trong” và “bên ngoài”.

Nguyên tắc 5: Luôn kiến trúc hệ thống

Đặc điểm cốt lõi của hệ thống dựa trên nền tảng đám mây là nó luôn tiến triển. Và điều đó cũng đúng với mô hình kiến ​​trúc. Kiến trúc sư phải luôn tìm cách điều chỉnh, đơn giản hóa và cải thiện hệ thống. Khi nhu cầu của tổ chức thay đổi, bối cảnh hệ thống CNTT thay đổi và khả năng của chính nhà cung cấp đám mây thay đổi. Điều này đòi hỏi đầu tư liên tục, chứng minh qua các bài học trong quá khứ. Để tiến hóa, phát triển và đáp ứng, các hệ thống CNTT cần phải sống, thở và thay đổi. Các hệ thống CNTT chết đứng sẽ đưa tổ chức vào tình trạng bế tắc, không thể đáp ứng với các mối đe dọa và cơ hội mới.

Tóm lại

Trong vương quốc động vật, sự sống còn rất quan trọng. Khi môi trường thay đổi, áp lực được áp dụng cho các loài để tiến hóa và thích nghi. Tương tự, kiến trúc cloud native không thay thế các kiến ​​trúc truyền thống. Nhưng chúng thích nghi tốt hơn với các môi trường khác nhau của đám mây. Chúng ta đang làm việc trên đám mây nhiều hơn. Sẽ khó để phát triển nếu không thể thích nghi với sự phát triển đó.

Các nguyên tắc ở trên không phải là công thức tuyệt đối để tạo ra kiến trúc cloud native. Nhưng phần nào đó cung cấp các hướng dẫn về cách tận dụng tối đa đám mây. Di chuyển và thích ứng với kiến ​​trúc đám mây cho bạn cơ hội để cải tiến và điều chỉnh theo nhiều cách. Cung cấp khả năng thích ứng tốt hơn với sự thay đổi môi trường.