CHUYỂN NHÀ “LÊN MÂY”
(Tiếp theo loạt bài trên Havard Business Review – Lê Quang – NTC Cloud lược dịch)
Trong khi từng doanh nghiệp phải tự mình quyết định về việc có di chuyển lên mây hay không, dựa trên các yêu cầu của mô hình kinh doanh, thì bài viết này sẽ giới thiệu 1 framework cho việc quyết định này.
Khám phá: Bước đầu tiên là cần phải biết những gì công ty bạn đang có. Với những công ty lớn, cơ cấu phức tạp, đây không phải là 1 việc dễ dàng. Thậm chí những công ty nhỏ hơn cũng chịu sự phiền phức của những ứng dụng và server thuộc quyền quản lý. Nhưng đây là bước đầu tiên và cần thiết.
Phân loại: theo Bernard Golden (CEO của Navica) cho rằng khi bạn đã biết rõ mọi thứ, bạn cần phải sắp xếp các ứng dụng của mình vào trong những danh mục sau:
1. Hệ thống cũ với giá trị thấp:
Những hệ thống này cần phải bị loại bỏ không chần chừ. Tuy nhiên, việc này sẽ đòi hỏi CEO, CIO phải gây ảnh hưởng để tìm hiểu các ứng dụng “con cưng” nằm ngoài tầm kiểm soát của những End-user. Các CIO ngày nay có các mô hình rất tốt cần được tham chiếu, chẳng hạn như GE, Motorola Solutions, AstraZeneca, Telefonica, ect.
2. Các dịch vụ cần thiết nhưng không khác biệt:
Các dịch vụ như email, office productivity, quản lý đội ngũ sales và các ứng dụng tiện ích doanh nghiệp cần phải được tích hợp vào SaaS. Việc này góp phần làm tăng tính sáng tạo trong doanh nghiệp – Ví dụ – các tính năng mới giúp tăng năng suất của nhân viên như: phân tích dữ liệu social, mở rộng khả năng làm việc linh động và tăng cường khả năng phân tích – và để các CIO tập trung công sức của nhân viên mình vào khả năng cạnh tranh khác biệt.
Patrick Benson, CIO của ClubCorp – nhà quản lý 200 sân golf, các câu lạc bộ thể thao, kinh doanh – hiện đang dựa vào chiến lựợc cloud trên SaaS và các dịch vụ quản lý bất cứ khi nào có thể. “Khi có 1 sự lựa chọn đơn giản hơn là viết 1 ứng dụng, việc di chuyển qua SaaS không đơn giản như việc bạn ngưng sử dụng 1 ứng dụng và bắt đầu dùng 1 cái mới” – trích lời một Giám đốc IT.
Việc đầu tiên là bạn cần phải rõ ràng với người sử dụng hệ thống rằng: dịch vụ được chọn sẽ định nghĩa quy trình. Điều này có thể cần 1 số thương lượng giữa các bên. Bạn phải đưa ra được và định tuyến các bộ dữ liệu và chắc chắn rằng bạn có thể kiểm tra việc truy xuất vào hệ thống. Cuối cùng, các user của hệ thống phải được đào tạo lại về quy trình mới.
3. Sự cần thiết và đổi ứng các ứng dụng:
Đây là nhóm những việc khó khăn nhất cần phải giải quyết. Các hệ thống đặc biệt, tự phát triển và được customize quá nhiều thì rất không thích hợp với SaaS, nhưng chúng có thể là PaaS hoặc IaaS.
Việc quyết định xem việc vận dụng chúng như thế nào đòi hỏi phải sắp xếp thông qua nhiều lần cân nhắc, chẳng hạn như độ phức tạp của code cơ sở (code base), sự phụ thuộc vào danh mục, vấn đề độ trễ của network, việc yêu cầu có thống nhất hay sẽ thay đổi liên tục, các yêu cầu lưu trữ dữ liệu tại đất nước bạn đang vận hành hệ thống, các vấn đề về bảo mật, tính riêng tư và các quy định.
Có 4 lựa chọn căn bản cho cách tiếp cận những hệ thống này:
• Lift and Shift:
Trong mô hình này, các ứng dụng hiện hành được đưa lên hạ tầng cloud mà không cần phải viết lại. Đây là 1 sự lựa chọn tốt cho các công ty mà đã chạm đỉnh về phí cho hạ tầng và ứng dụng khi dữ liệu bị giới hạn trong logic của ứng dụng.
Motorola Solutions, công ty đã cho outsoure rất nhiều về quản lý hạn tầng và ứng dụng, đã sử dụng phương pháp này và cho kết quả là các danh mục của công ty đều tăng độ tin cậy và tính sẵn sàng, tiết kiệm chi phí nhanh chóng.
Các công cụ ảo hoá, ví dụ như VMware, thì rất dễ “lift & shift” và có thể được host lại y nguyên trên các nền tảng được hỗ trợ.
Tuy nhiên, nếu chi phí cho hạ tầng của bạn đã tốt rồi, mô hình hình “lift & shift” sẽ không giúp bạn thu lợi nhiều, cũng như ứng dụng của bạn sẽ không thể hưởng lợi từ những ưu điểm chính của hạ tầng cloud, chẳng hạn như độ mở rộng – scalability. Và đây không phải là lựa chọn tốt cho các ứng dụng tiêu thụ nhiều resource, chúng sẽ tốn rất nhiều chi phí trong môi trường cloud và cũng có thể sẽ ảnh hưởng bởi những vấn đề hiệu năng và độ trễ.
• Containers:
Cung cấp 1 wrapper bọc xung quanh những code hiện tại để có thể mang đi từ môi trường này sang môi trường khác. Container được nhiều người biết tới và sử dụng rộng rãi nhất đó là Docker tiêu chuẩn mở. Các Container cung cấp khả năng tiếp cận nhiều nhiều lợi ích của cloud hơn mô hình “lift & shift” nhưng KHÔNG tính tới gánh nặng phải viết lại ứng dụng.
Container cũng hữu ích trong quy trình phát triển phần mềm mới, cung cấp khả năng giúp bạn phát triển, test chạy thử trong các môi trường khác nhau. Nhưng chiếm nhiều diện tích lưu trữ trên cloud, container hiện vẫn còn đang ở bước phát triển. Đây là 1 công cụ tuyệt vời và làm cho nhiều CIO rất phấn khởi, chưa phải lúc áp dụng cho tất cả ứng dụng.
Bạn nên dùng thử với các ứng dụng có độ phức tạp vừa phải (không phải ứng dụng xương sống hoặc nhạy cảm nhé) để có thể ít nhiều kinh nghiệm.
• Rewrite:
Viết lại ứng dụng (hoặc refactor, thay đổi code nhưng không đổi chức năng) để đạt được khả năng full cloud-native (app viết dành cho cloud) khi mô hình kinh doanh đòi hỏi ứng dụng cần làm gì đó nhiều hơn. Ví dụ như trong các dịch vụ có sự thay đổi nhanh chóng và có thể công ty sẽ được lợi từ việc chu kỳ release thu hẹp lại hoặc dành cho các ứng dụng mobile. Việc viết lại ứng dụng làm tăng hiệu suất của developer trong dài hơi và có thể dễ dàng hơn trong việc cho ra lò các version mới, cũng như các ứng dụng dựa trên các thành phần nhỏ hoặc micro services. Việc này cũng làm tăng hiệu năng và tính chủ động, và thường là xảy ra nếu chi phí thấp.
Tất nhiên, những công ty lớn thích những thứ như vậy và viết lại app thường sẽ tốn tiền và thời gian, vì thế doanh nghiệp phải thật sự hiểu ứng dụng của mình có giải quyết được các yêu cầu kinh doanh không và các rủi ro trong đó. Sẽ là khởi đầu tốt nếu chúng ta bắt đầu với những ứng dụng, nơi mà bạn chắc chắn sẽ nhìn thấy lợi ích to lớn trong việc kinh doanh và giảm thiểu rủi ro về dữ liệu của ứng dụng. Các hệ thống không được thiết kế kĩ càng cũng có thể là bước đệm tốt để thử, vì chúng sẽ tốn nhiều tài nguyên cloud vô ích, vì thế sẽ phát sinh ra nhiều chi phí tài nguyên cloud và thậm chí có thể dẫn tới nhiều vấn đề về hiệu năng và độ ổn đị nh của hệ thống.
• Leave it alone:
Một số hệ thống cũ phức tạp – có thể gọi là tốt, ít nhất là đến bây giờ. Nếu hệ thống vẫn đáp ứng nhu cầu và hoạt động ổn định, thì có lẽ không có lý do gì phải chuyển hướng lên cloud làm gì. Mặt khác, nếu như chỉ có vài người hiểu được hệ thống, thì đâu đó vẫn còn những mối nguy tiềm tàng.
Các CIO vẫn đang cân nhắc về mặt lợi và hại của việc duy trì những hệ thống này, quản lý các chi phí và sự phức tạp liên quan đến data center, và việc chuyển hướng các khoảng đầu tư từ CAPEX sang OPEX. Đây sẽ vẫn là các bước đi trong những khoảng từ 5 đến 10 năm nữa.
Các năng lực tiềm tàng mới: nền kinh tế liên tục chuyển mình, các tổ chức/ công ty trong các ngành công nghiệp cần phải phát triển các khả năng mới cho doanh nghiệp của mình để có thể tận dụng được những cơ hội mới và đẩy lùi các mối nguy. Việc sử dụng các ứng dụng cloud based đang được coi là khôn ngoan, trong đó coi SaaS như là lựa chọn hàng đầu (bạn xem thử có dịch vụ hiện hành nào đáp ứng được nhu cầu của mình không), và với các ứng dụng được viết phù hợp với xu thế cloud (cloud native apps).
Tham khảo thêm các phần khác của loạt bài viết:
[pt_view id=”ee31276qem”]
[pt_view id=”ee31276qem”]