4 kinh nghiệm để tránh bị khóa nhà cung cấp cloud
Nếu không có kế hoạch phù hợp, tổ chức có thể cảm thấy bị mắc kẹt trong mối quan hệ với nhà cung cấp hạ tầng cloud. Hãy làm theo những lời khuyên sau để tránh vấn đề bị khóa nhà cung cấp (vendor lock-in).
Đám mây là một nguồn tài nguyên tuyệt vời nhưng đôi khi các nhà cung cấp dịch vụ, các bên triển khai hoặc thậm chí là kiến trúc không cung cấp được những gì bạn cần. Thực hiện trước các bước sẽ đảm bảo bạn không bị khóa vào nền tảng đám mây nào.
Mỗi nhà cung cấp dịch vụ đám mây lớn đều có những điểm khác biệt và bạn cần tìm ra nhà cung cấp phù hợp dựa trên mục tiêu kinh doanh của mình. Oliver Presland, phó chủ tịch tại Ensono, một nhà cung cấp dịch vụ hybrid IT, cho biết: “Nhưng nếu những mục tiêu đó thay đổi hoặc các ứng dụng khác sẽ phù hợp hơn với một nhà cung cấp khác, thì hẳn bạn muốn mình có thể chuyển các tải xử lý và tận dụng những gì tốt nhất hiện có”.
Để giảm thiểu tình trạng khóa nhà cung cấp, trước tiên bạn cần đặt câu hỏi xem ứng dụng của bạn có thuộc về đám mây hay không. Sau đó, hãy đảm bảo ứng dụng của bạn có thể di chuyển được nếu bạn cần chuyển sang nhà cung cấp khác.
Hãy làm theo các biện pháp hữu ích nhất này để đảm bảo kết quả tốt nhất có thể cho ứng dụng và mục tiêu kinh doanh của bạn. Tuy nhiên, hãy nhớ rằng việc khóa nhà cung cấp không phải lúc nào cũng xấu nếu nó “cung cấp khả năng duy nhất cho phép bạn tạo sự khác biệt với các đối thủ cạnh tranh”, Presland nói.
Đánh giá ứng dụng trước khi di chuyển
Trước khi bạn di chuyển một ứng dụng lên đám mây, hãy hỏi xem tải xử lý đó có thuộc về nơi đó ngay từ đầu hay không. Yugal Joshi, hiệu trưởng của Everest Group cho biết, việc đặt câu hỏi liệu có nên di chuyển một ứng dụng hay không là phù hợp hơn khi các doanh nghiệp chưa quyết định về tương lai đám mây của họ. Chiến lược thoát khỏi đám mây không hề rẻ. Thực hiện phân tích kỹ lưỡng về lợi ích nhận được và tổng chi phí để giảm bớt sự hối tiếc sau này.
Để chuyển sang đám mây, bạn cần tập trung vào mức độ ưu tiên, tính khả thi và trường hợp kinh doanh. Trong quá trình này, bạn có thể phát hiện ra tải xử lý phức tạp, có gánh nặng pháp lý hoặc không có ý nghĩa kinh tế khi chuyển sang đám mây.
Tìm hiểu lý do tại sao một số doanh nghiệp chọn thoát khỏi đám mây.
Erik Costlow, giám đốc nghiên cứu và sản phẩm cấp cao của Azul, một nền tảng phát triển Java, cho biết bạn cũng cần xem xét chi phí của những gì ứng dụng kết nối tới. Ví dụ: Costlow đã làm việc với một doanh nghiệp muốn di chuyển 300 ứng dụng lên đám mây. Việc di chuyển 5 trong số đó đã làm tiêu tốn ngân sách cả năm vì công ty không lường trước được yêu cầu lưu trữ sẽ lớn đến mức nào.
Trong một số trường hợp, chi phí tăng lên có thể chấp nhận được. Kevin Beasley, CIO tại VAI, nhà cung cấp giải pháp ERP, cho biết một số lợi ích hàng đầu so với các chi phí này bao gồm hiệu quả CNTT, cập nhật nhanh hơn và khả năng mở rộng được cải thiện.
Tăng tính di động của ứng dụng
Bạn nên xem xét các cách để đảm bảo tính di động của ứng dụng . Tính di động có nghĩa là giảm thiểu số lượng thay đổi cần thực hiện để di chuyển ứng dụng từ môi trường của nhà cung cấp đám mây này sang môi trường khác. Để giảm thiểu những thay đổi đó, hãy sử dụng các dịch vụ chung cho nhiều đám mây.
Presland khuyến nghị các công ty xem xét thiết kế, các phần phụ thuộc và công nghệ của từng tải xử lý. Sau đó, hãy xem xét điều này ảnh hưởng như thế nào đến khả năng di chuyển của nó lên đám mây và giữa các đám mây trong tương lai. Phân tích này có thể giúp bạn cân nhắc chi phí của các biện pháp cụ thể so với lợi ích của việc truy cập vào các dịch vụ dành riêng cho đám mây.
Tìm hiểu tại sao tính di động của dữ liệu lại quan trọng.
Joshi khuyến nghị các doanh nghiệp nên hỏi tại sao ngay từ đầu họ lại tìm kiếm tính di động. Đánh giá tần suất các ứng dụng mà trước đó đã được chuyển khỏi nền tảng. Nếu họ không phải làm điều này thì họ sẽ bớt lo lắng hơn về tính di động. Joshi cho biết: “Có rất ít trường hợp doanh nghiệp di chuyển tải xử lý quan trọng giữa các đám mây”.
Tim Hinrichs, người đồng sáng lập dự án Open Policy Agent và CTO của Styra, khuyến nghị cấu hình các tài nguyên non-Kubernetes bằng công cụ theo kiểu bất khả tri với đám mây (cloud-agnostic) để tăng tính di động. Ví dụ: Terraform hoàn thiện hạ tầng theo cách tương tự trên các nền tảng đám mây khác nhau. Các công cụ cloud-agnostic có thể đảm bảo rằng các biện pháp kiểm soát hoạt động, tuân thủ và bảo mật sẽ không thay đổi, ngay cả khi dịch vụ đám mây của tổ chức của bạn có thay đổi. Các API cloud-agnostic được nhiều đám mây sử dụng, như với Amazon S3 , cũng có thể hữu ích.
Theo kinh nghiệm của ông, việc xây dựng tính di động có thể làm chậm quá trình áp dụng đám mây và khiến nó trở nên đắt đỏ hơn. Việc lập kế hoạch theo kịch bản có thể giúp doanh nghiệp đưa ra đánh giá thực tế về những gì doanh nghiệp có thể bị mất trong một kịch bản bị khóa. Điều này có thể ưu tiên tải xử lý nào họ muốn xây dựng hoặc di chuyển phải có tính di động cao hơn các tải xử lý khác.
Khám phá với việc sử dụng container
Quá trình container hóa, sử dụng lớp trừu tượng, có thể dẫn đến tính di động vì nó có thể chạy trên nhiều lớp nền tảng đám mây khác nhau. Có thể hợp lý khi sử dụng mô hình container cho các ứng dụng sẽ được hưởng lợi từ việc phân chia thành các chức năng kinh doanh có thể được cập nhật hoặc mở rộng quy mô một cách độc lập.
Tuy nhiên, các ứng dụng khác có thể không được hưởng lợi từ sự thay đổi kiến trúc triển khai này. Chúng có thể chạy trên phần mềm không tương thích với container. Presland khuyến nghị triển khai PoC (proof of concept) khi xem xét chuyển đổi sang container.
Cooper Lutz, kiến trúc sư trưởng về giải pháp kỹ thuật số tại AHEAD, một công ty tư vấn, cho biết công nghệ điều phối container cơ bản có thể có các yếu tố khóa riêng. Tuy nhiên, điều này đòi hỏi nỗ lực thấp hơn để thay thế lớp điều phối container thay vì viết lại một ứng dụng nguyên khối, được liên kết chặt chẽ để thoát khỏi tình trạng khóa phần cứng.
Eli Zilbershtein, giám đốc kỹ thuật cấp cao tại Bảo hiểm Hippo, cũng khuyên bạn nên xây dựng một lớp trừu tượng giữa các ứng dụng và dịch vụ đám mây của bạn. Ví dụ: Hippo sử dụng Loggly để quản lý log. Vì các ứng dụng của công ty sử dụng thư viện nội bộ để gửi log nên việc chuyển sang nhà cung cấp log khác sẽ rất đơn giản. Nhờ lớp trừu tượng này, việc thực hiện chuyển đổi như vậy sẽ chỉ yêu cầu một thay đổi duy nhất trong thư viện ghi log thay vì thay đổi mã ứng dụng.
Xem xét sự phụ thuộc của dữ liệu và quy trình làm việc
Xem xét dữ liệu mà ứng dụng dựa vào. Nitha Puthran, phó chủ tịch cấp cao về đám mây và hạ tầng tại Persistent Systems, một nhà cung cấp kỹ thuật số, cho biết: “Dữ liệu có thể đắt hơn và khó di chuyển hơn ứng dụng”. Các doanh nghiệp cần quyết định xem có nên luôn có dữ liệu trên nhiều đám mây hay không, di chuyển dữ liệu khi được yêu cầu hay để dữ liệu ở nguyên vị trí và truy cập dữ liệu từ xa.
Ngoài ra, hãy nhớ ghi lại các phụ thuộc của quy trình làm việc. Thực thi quy ước gắn thẻ và metadata, đồng thời hiểu và ghi lại các phần phụ thuộc của tải xử lý trước khi di chuyển.
Nguồn Tech Target
