Những tiêu chí lựa chọn cloud hay on-premise

Vì vậy, quyết định không nên xuất phát từ câu hỏi đơn giản như “cloud có rẻ hơn không?” hay “on-premise có an toàn hơn không?”. Doanh nghiệp cần đặt từng phương án vào cùng một tập yêu cầu về chi phí, kiểm soát, bảo mật, hiệu năng, khả năng mở rộng và năng lực vận hành. Một lợi thế của cloud có thể trở thành bất lợi với workload khác; điều tương tự cũng đúng với on-premise.

Trước tiên cần xác định đặc điểm của workload

Workload là cơ sở để đánh giá các tiêu chí còn lại. Hai doanh nghiệp có cùng quy mô nhưng có thể đưa ra quyết định khác nhau nếu tải hệ thống, yêu cầu dữ liệu và mức độ quan trọng của ứng dụng khác nhau.

Các thông tin cần xác định gồm:

·         Mức CPU, RAM, dung lượng lưu trữ và băng thông thực tế

·         Tải trung bình và tải cực đại

·         Mức biến động tài nguyên theo giờ, ngày hoặc mùa vụ

·         Tốc độ tăng trưởng dữ liệu

·         Yêu cầu độ trễ

·         Mức độ quan trọng của hệ thống đối với hoạt động kinh doanh

·         RTO, tức thời gian tối đa có thể chấp nhận để khôi phục dịch vụ

·         RPO, tức lượng dữ liệu tối đa doanh nghiệp có thể chấp nhận mất khi xảy ra sự cố

·         Yêu cầu lưu trữ, xử lý và truyền dữ liệu

·         Các ràng buộc về pháp lý, hợp đồng hoặc vị trí dữ liệu

Workload ổn định, có mức sử dụng cao và dự báo được trong nhiều năm có thể khai thác hiệu quả hạ tầng đã đầu tư. Ngược lại, workload tăng giảm mạnh khiến doanh nghiệp phải mua dư công suất nếu sử dụng on-premise để đáp ứng thời điểm tải cực đại.

Cloud giải quyết vấn đề này bằng khả năng cấp phát tài nguyên linh hoạt. Tuy nhiên, khả năng mở rộng không đồng nghĩa chi phí tự động tối ưu. Tài nguyên chạy liên tục nhưng không được quản trị, máy ảo cấu hình quá lớn, lưu trữ dư thừa hoặc lưu lượng dữ liệu phát sinh nhiều đều có thể làm chi phí cloud tăng.

Do đó, workload phải được đo trước khi lựa chọn kiến trúc, thay vì chọn kiến trúc trước rồi mới tìm cách điều chỉnh workload cho phù hợp.

So sánh tổng chi phí sở hữu thay vì chỉ nhìn giá máy chủ hoặc hóa đơn cloud

Chi phí là một trong những tiêu chí quan trọng nhất nhưng cũng dễ bị so sánh sai nhất. Cloud thường gắn với chi phí vận hành theo mức sử dụng, còn on-premise đòi hỏi đầu tư ban đầu lớn hơn. Hai khoản này không thể so sánh chỉ bằng giá thuê máy ảo và giá mua một máy chủ.

Chi phí on-premise cần tính những gì?

Tổng chi phí sở hữu của on-premise có thể bao gồm:

TCO on-premise = chi phí đầu tư ban đầu chi phí vận hành nhân sự bảo trì điện và làm mát cơ sở vật chất dự phòng nâng cấp − giá trị còn lại

Ngoài máy chủ, doanh nghiệp có thể phải tính:

·         Thiết bị lưu trữ

·         Thiết bị mạng

·         License phần mềm

·         UPS và nguồn điện dự phòng

·         Không gian trung tâm dữ liệu

·         Hệ thống làm mát

·         Thiết bị dự phòng

·         Hợp đồng bảo trì

·         Nhân sự hệ thống, mạng và bảo mật

·         Chi phí thay thế phần cứng theo chu kỳ

·         Hạ tầng phục vụ sao lưu và phục hồi thảm họa

Một máy chủ có giá mua thấp chưa chắc tạo TCO thấp nếu phần lớn tài nguyên của nó không được sử dụng.

Chi phí cloud cần tính những gì?

TCO cloud không chỉ gồm chi phí compute. Doanh nghiệp cần tính:

TCO cloud = compute storage network dịch vụ nền tảng backup observability support bảo mật vận hành

Đặc biệt cần kiểm tra:

·         Tài nguyên chạy 24/7

·         Dung lượng lưu trữ và số lượng bản sao

·         Snapshot và backup

·         Lưu lượng dữ liệu ra ngoài

·         Load balancer, database và các managed service

·         Log và monitoring

·         Môi trường development, staging và production

·         Tài nguyên không còn sử dụng nhưng chưa được xóa

Cloud có lợi thế rõ hơn khi tài nguyên cần thay đổi nhanh, workload có tính thời vụ hoặc doanh nghiệp muốn tránh mua công suất trước nhiều năm. On-premise có thể cạnh tranh về chi phí với workload ổn định, sử dụng tài nguyên ở mức cao và khai thác hạ tầng đủ lâu để phân bổ chi phí đầu tư.

Vì vậy, nên tính TCO cho cùng một khoảng thời gian, chẳng hạn ba hoặc năm năm, với cùng mức tải, cùng yêu cầu dự phòng, cùng RTO/RPO và cùng mức dịch vụ. So sánh khác phạm vi sẽ tạo ra kết luận sai.

Mức độ kiểm soát và tùy biến cần thiết đến đâu?

On-premise trao cho doanh nghiệp quyền kiểm soát trực tiếp đối với phần cứng, mạng, hệ điều hành, cấu hình vật lý và quy trình vận hành. Đây là lợi thế khi hệ thống có yêu cầu đặc thù mà nền tảng cloud tiêu chuẩn khó đáp ứng.

On-premise phù hợp hơn khi doanh nghiệp cần:

·         Kiểm soát sâu cấu hình phần cứng

·         Sử dụng thiết bị chuyên dụng

·         Thiết kế mạng vật lý đặc thù

·         Tích hợp chặt với hệ thống legacy

·         Kiểm soát trực tiếp quá trình thay đổi hạ tầng

·         Duy trì môi trường không phụ thuộc kết nối Internet hoặc nhà cung cấp bên ngoài

Đổi lại, quyền kiểm soát đi kèm trách nhiệm. Doanh nghiệp phải tự quản lý vòng đời phần cứng, firmware, hypervisor, hệ điều hành, mạng, sao lưu, dự phòng và nhiều lớp bảo mật.

Với cloud, một phần hạ tầng vật lý được nhà cung cấp quản lý. Doanh nghiệp không cần kiểm soát từng máy chủ để sử dụng tài nguyên nhưng phải chấp nhận phạm vi cấu hình mà dịch vụ cung cấp hỗ trợ.

Mức độ đánh đổi phụ thuộc loại dịch vụ. IaaS cho phép doanh nghiệp kiểm soát nhiều hơn đối với máy ảo và hệ điều hành; các dịch vụ managed database, container platform hoặc serverless chuyển thêm trách nhiệm vận hành cho nhà cung cấp nhưng đồng thời làm giảm quyền can thiệp vào lớp hạ tầng bên dưới.

Doanh nghiệp vì vậy nên xác định rõ phần nào thực sự cần kiểm soát, thay vì coi quyền sở hữu toàn bộ hạ tầng là mục tiêu mặc định.

Một yếu tố khác là vendor lock-in. Việc sử dụng máy ảo và công nghệ phổ biến thường dễ di chuyển hơn ứng dụng phụ thuộc sâu vào database, API hoặc dịch vụ độc quyền của một cloud provider. Nếu khả năng chuyển đổi nhà cung cấp là yêu cầu quan trọng, chi phí migration và mức độ phụ thuộc công nghệ cần được đánh giá ngay từ giai đoạn thiết kế.

Bảo mật, tuân thủ và chủ quyền dữ liệu phải được đánh giá theo trách nhiệm cụ thể

Không thể kết luận cloud luôn an toàn hơn hoặc on-premise luôn bảo mật hơn. Mức độ an toàn phụ thuộc vào kiến trúc, cách cấu hình, khả năng giám sát, quy trình vận hành và năng lực của đội ngũ chịu trách nhiệm.

Với on-premise, doanh nghiệp chịu trách nhiệm gần như toàn bộ chuỗi bảo mật: từ vật lý, mạng, phần cứng và hypervisor đến hệ điều hành, ứng dụng, danh tính và dữ liệu.

Trong môi trường cloud, trách nhiệm được chia sẻ giữa nhà cung cấp và khách hàng. Nhà cung cấp bảo vệ các lớp thuộc hạ tầng dịch vụ mà họ vận hành; khách hàng vẫn phải bảo vệ những thành phần nằm trong phạm vi kiểm soát của mình như tài khoản, quyền truy cập, cấu hình, ứng dụng và dữ liệu. Phạm vi cụ thể thay đổi theo IaaS, PaaS và SaaS.

Doanh nghiệp cần kiểm tra tối thiểu:

·         Dữ liệu có được phép lưu trữ tại khu vực đã chọn hay không

·         Có yêu cầu data residency hoặc data sovereignty hay không

·         Dữ liệu phải được mã hóa ở trạng thái lưu trữ và truyền tải như thế nào

·         Ai được phép truy cập dữ liệu

·         Cơ chế quản lý khóa mã hóa có đáp ứng yêu cầu hay không

·         Hệ thống có hỗ trợ logging và audit trail cần thiết hay không

·         Cơ chế backup và phục hồi có đáp ứng RPO/RTO hay không

·         Nhà cung cấp có đáp ứng các chứng nhận hoặc tiêu chuẩn mà doanh nghiệp bắt buộc phải tuân thủ hay không

·         Hợp đồng có quy định phù hợp về xử lý, lưu giữ và xóa dữ liệu hay không

On-premise tạo điều kiện kiểm soát vật lý trực tiếp, nhưng quyền kiểm soát này chỉ có giá trị khi doanh nghiệp đủ năng lực duy trì patching, giám sát, phân quyền, backup, kiểm thử phục hồi và ứng phó sự cố.

Cloud loại bỏ một phần công việc vận hành hạ tầng, nhưng cấu hình sai quyền truy cập, quản trị danh tính yếu hoặc để tài nguyên công khai ngoài ý muốn vẫn có thể tạo rủi ro lớn.

Tiêu chí đúng vì vậy không phải là “dữ liệu nhạy cảm thì bắt buộc on-premise”, mà là mô hình nào đáp ứng được yêu cầu kiểm soát, bằng chứng tuân thủ và mức rủi ro mà tổ chức chấp nhận.

Khả năng mở rộng, hiệu năng và tính sẵn sàng ảnh hưởng trực tiếp đến lựa chọn

Khả năng mở rộng là lợi thế cốt lõi của cloud khi nhu cầu tài nguyên thay đổi nhanh. Tài nguyên điện toán và lưu trữ có thể được cấp phát mà không cần chờ doanh nghiệp mua, lắp đặt và đưa phần cứng mới vào vận hành.

Đặc điểm này có giá trị đối với:

·         Ứng dụng có lưu lượng tăng đột biến

·         Dịch vụ có tính mùa vụ

·         Sản phẩm mới chưa dự báo chính xác nhu cầu

·         Môi trường thử nghiệm cần tạo và xóa thường xuyên

·         Doanh nghiệp đang tăng trưởng nhanh

On-premise cũng có thể mở rộng, nhưng doanh nghiệp phải lập kế hoạch capacity. Khi công suất không đủ, việc bổ sung máy chủ, lưu trữ hoặc thiết bị mạng cần thời gian mua sắm và triển khai. Nếu mua theo tải cực đại, phần công suất dư lại trở thành chi phí cố định trong thời gian tải thấp.

Tuy nhiên, khả năng mở rộng không phải tiêu chí duy nhất.

Khi nào hiệu năng có thể nghiêng về on-premise?

On-premise có thể phù hợp hơn với workload cần:

·         Độ trễ rất thấp đến hệ thống nội bộ

·         Truy cập lượng dữ liệu lớn tại chỗ

·         Kết nối trực tiếp với máy móc hoặc thiết bị sản xuất

·         Phần cứng chuyên dụng

·         Hiệu năng ổn định và có thể dự báo trên tài nguyên dành riêng

Nếu dữ liệu và ứng dụng phụ thuộc lẫn nhau nhưng được đặt ở hai môi trường khác nhau, độ trễ và chi phí truyền dữ liệu có thể triệt tiêu một phần lợi ích của cloud.

Tính sẵn sàng phải được đánh giá bằng SLA nội bộ

Doanh nghiệp không nên chọn nền tảng chỉ vì một nhà cung cấp công bố mức uptime cao. Trước tiên cần xác định mức gián đoạn mà hoạt động kinh doanh chấp nhận được.

Các chỉ số quan trọng gồm:

·         Availability

·         RTO

·         RPO

·         Thời gian phát hiện sự cố

·         Thời gian chuyển đổi sang hệ thống dự phòng

Ví dụ, yêu cầu RTO vài phút đòi hỏi kiến trúc khác đáng kể so với hệ thống có thể ngừng vài giờ. Điều này đúng với cả cloud lẫn on-premise.

Cloud cung cấp các building block để triển khai nhiều vùng hoặc nhiều khu vực khả dụng, nhưng doanh nghiệp vẫn phải thiết kế ứng dụng để tận dụng chúng. On-premise có thể đạt độ sẵn sàng cao nếu xây dựng hạ tầng dự phòng tương ứng, song chi phí và độ phức tạp sẽ tăng.

Năng lực vận hành và tốc độ triển khai thường quyết định hiệu quả thực tế

Một kiến trúc phù hợp về mặt kỹ thuật vẫn có thể thất bại nếu doanh nghiệp không đủ năng lực vận hành.

On-premise đòi hỏi khả năng quản lý nhiều lớp hạ tầng. Doanh nghiệp cần nhân sự hoặc đối tác có năng lực về:

·         Máy chủ và lưu trữ

·         Mạng

·         Ảo hóa

·         Backup

·         Giám sát

·         Quản lý bản vá

·         Bảo mật

·         Capacity planning

·         Khôi phục sau sự cố

Cloud giảm bớt một phần công việc liên quan đến phần cứng, nhưng không loại bỏ nhu cầu vận hành. Đội ngũ phải hiểu IAM, kiến trúc mạng cloud, quản trị chi phí, Infrastructure as Code, logging, bảo mật cấu hình và cơ chế hoạt động của từng dịch vụ được sử dụng.

Cloud thường tạo lợi thế khi tốc độ cấp phát môi trường là yêu cầu kinh doanh. Một môi trường mới có thể được triển khai từ cấu hình tự động thay vì chờ chu trình mua sắm phần cứng. Điều này đặc biệt hữu ích với đội phát triển cần tạo môi trường thử nghiệm thường xuyên.

Ngược lại, nếu doanh nghiệp đã sở hữu hạ tầng còn nhiều công suất, có đội vận hành ổn định và ứng dụng ít thay đổi, việc di chuyển chỉ vì cloud có khả năng provisioning nhanh có thể không tạo đủ giá trị để bù cho chi phí migration và thay đổi quy trình.

Quyết định cần tính cả chi phí chuyển đổi, bao gồm:

·         Đánh giá và phân loại ứng dụng

·         Chuyển dữ liệu

·         Refactor hoặc thay đổi kiến trúc

·         Kiểm thử

·         Đào tạo nhân sự

·         Vận hành song song trong giai đoạn chuyển đổi

·         Downtime hoặc rủi ro phát sinh khi migration

Chi phí migration là chi phí một lần nhưng có thể đủ lớn để làm thay đổi bài toán TCO trong khoảng thời gian đánh giá.

Cách lựa chọn cloud hay on-premise theo ma trận tiêu chí

Doanh nghiệp có thể tránh quyết định theo cảm tính bằng cách chấm điểm từng phương án trên cùng một ma trận.

Trước tiên, xác định trọng số của từng tiêu chí theo mức ảnh hưởng đến doanh nghiệp. Một mô hình có thể sử dụng:

Điểm phương án = Σ (trọng số tiêu chí × điểm đáp ứng tiêu chí)

Các tiêu chí nên bao gồm:

Không nên sử dụng cùng trọng số cho mọi doanh nghiệp. Một tổ chức tài chính có thể đặt bảo mật và tuân thủ cao hơn tốc độ provisioning; một sản phẩm số mới có thể đặt khả năng mở rộng và tốc độ triển khai cao hơn việc sở hữu hạ tầng.

Ngoài ra, lựa chọn không nhất thiết phải là 100% cloud hoặc 100% on-premise. Hybrid phù hợp khi các workload có yêu cầu khác nhau. Chẳng hạn, hệ thống cần kết nối trực tiếp thiết bị tại nhà máy có thể tiếp tục chạy tại chỗ, trong khi môi trường phát triển hoặc workload có tải biến động được triển khai trên cloud.

Hybrid chỉ có giá trị khi nó giải quyết một ràng buộc thực tế. Nếu triển khai hai môi trường mà không có lý do rõ ràng, doanh nghiệp phải quản lý đồng thời hai mô hình vận hành, hai lớp kết nối, nhiều chính sách bảo mật và quy trình giám sát phức tạp hơn.

Doanh nghiệp nên lựa chọn cloud hay on-premise dựa trên workload cụ thể thay vì một nhận định chung cho toàn bộ hệ thống. Cloud thường có lợi thế khi nhu cầu biến động, cần mở rộng nhanh, muốn giảm đầu tư hạ tầng ban đầu hoặc cần rút ngắn thời gian cấp phát tài nguyên. On-premise thường có lợi thế khi workload ổn định, yêu cầu kiểm soát sâu, phụ thuộc hệ thống tại chỗ hoặc có những ràng buộc kỹ thuật và tuân thủ mà cloud không đáp ứng phù hợp.

Một quyết định có cơ sở cần ít nhất ba phép kiểm tra: so sánh TCO trên cùng khoảng thời gian, đối chiếu từng phương án với yêu cầu bảo mật–RTO–RPO–độ trễ, và đánh giá khả năng vận hành thực tế của đội ngũ. Nếu các workload có yêu cầu khác biệt đáng kể, hybrid có thể phù hợp hơn việc ép toàn bộ hệ thống vào một mô hình duy nhất.