Lãnh đạo tư tưởng

Dự Báo Đổi Thay Của Đám Mây

mm
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google

Một Mẫu Tôi Đã Thấy Trước

Tôi đã làm việc chuyên nghiệp khi đám mây trở thành một thứ gì đó. Từ góc độ đó, tôi đã thấy sự áp dụng ban đầu: sự phấn khích, sự linh hoạt, cảm giác rằng mọi thứ sẽ di chuyển nhanh hơn. Điều này dẫn đến sự áp dụng rộng rãi, nơi mọi workload đều là một ứng cử viên và mọi nhà cung cấp đều có một câu chuyện về đám mây.

Sự áp dụng, tuy nhiên, chỉ là nửa đầu của những gì tôi đã chứng kiến. Sau đó, tôi đã thấy phía bên kia của nó: sự quay trở lại. Các công ty di chuyển các workload cụ thể trở lại, đặt câu hỏi liệu mọi ứng dụng thực sự cần sự linh hoạt của đám mây. Sự di chuyển này xảy ra vì một lý do. Với sự thay đổi kinh tế và sự trưởng thành của workload, những giả định mà làm cho đám mây trở thành lựa chọn rõ ràng cho mọi thứ đã ngừng giữ vững khi các tổ chức bắt đầu kiểm tra chúng ở quy mô lớn.

Sau khi sống qua toàn bộ quá trình một lần, tôi nhận ra hình dạng của nó khi nó bắt đầu hình thành lại. Bây giờ, khi tôi giúp các công ty phân loại những gì AI thực sự nên làm trong môi trường của họ, mẫu áp dụng/sự quay trở lại đang bắt đầu trông quen thuộc.

Sự Sửa Đổi Của Đám Mây

Để hiểu tại sao sự tương đồng này quan trọng, nó giúp bắt đầu với những gì thực sự đã xảy ra với đám mây, trên chính nó. Sự di chuyển đến đám mây là hợp lý. Nó loại bỏ sự ma sát, mang lại cho các tổ chức sự linh hoạt và tốc độ, và có ý nghĩa cho các workload không chắc chắn hoặc thay đổi nhanh. Nó là hợp lý vì loại công việc nó được xây dựng cho. Các đội DevOps đã đi đầu với đám mây vì đám mây được xây dựng cho công việc lặp đi lặp lại, biến đổi hoặc khó dự đoán.

Tuy nhiên, thứ họ đang xây dựng không đứng yên. Đám mây không thay đổi, nhưng các workload đã thay đổi. Khi các quy trình trưởng thành và trở nên có thể dự đoán, các tổ chức đã quen với chi phí xung quanh việc lấy lại dữ liệu của mình. Phí egress, chi phí lưu trữ, phí chuyển đổi: những chi phí dễ dàng bỏ qua khi sự linh hoạt đáng giá, và khó bỏ qua khi các workload ổn định. Vào năm 2024, sau nhiều năm tính phí cho egress dữ liệu, AWS, Azure và Google Cloud đã miễn phí những phí này cho khách hàng di chuyển ra khỏi nền tảng của họ, như DataCenterDynamics đã báo cáo.

Khi những chi phí đó trở nên rõ ràng, toán học ngừng hoạt động cho một phần ngày càng lớn của danh mục đầu tư. Kinh tế học đã làm cho đám mây trở thành một chiến lược tốt với một số điểm yếu đã trở nên không khả thi về mặt kinh tế cho một tập hợp ngày càng lớn các workload định hướng AI. Các công ty đã sắc nét hơn bút chì của họ và hỏi liệu mọi ứng dụng thực sự cần những gì đám mây đang cung cấp. Khi họ thực sự chạy số, câu trả lời, cho nhiều workload, là không.

Các câu trả lời tích lũy đó trở thành một sự sửa đổi mà ngành công nghiệp đã dán nhãn sai. Sự sửa đổi đó được gọi là “sự quay trở lại của đám mây”, và nó thường được mô tả không chính xác. Thực tế, nó là sự trưởng thành của workload: các công ty trưởng thành học cách phù hợp với từng workload với mô hình cơ sở hạ tầng phù hợp với nó. Dữ liệu hỗ trợ việc đọc có chọn lọc hơn là toàn bộ. IDC đã tìm thấy rằng khoảng 80% tổ chức dự kiến sẽ có một số sự quay trở lại trong 12 tháng tới, ngay cả khi ít hơn 10% đã quay trở lại toàn bộ workload, theo báo cáo trên CIO.com.

Đọc đúng, kết luận không phải là đám mây là một sai lầm. Đám mây vẫn có giá trị, nhưng nó đã ngừng trở thành phổ quát. Trạng thái trưởng thành là hỗn hợp: đám mây nơi nó đã kiếm được vị trí của mình, cơ sở hạ tầng riêng hoặc chuyên dụng ở mọi nơi khác.

Cùng Một Đường Cong Sửa Đổi, Công Nghệ Khác

Đó là một đường cong hoàn thành và được dán nhãn bây giờ. Cùng một hình dạng đang bắt đầu hình thành lại với AI. Mỗi nhà cung cấp, mỗi hội nghị, mỗi cuộc gọi bán hàng hiện tại đều là về AI. Sự bão hòa là giống hệt với những gì tôi đã chứng kiến xảy ra với đám mây. Chi tiêu dưới sự ồn ào là thực: Gartner dự báo chi tiêu cho AI sinh tổng hợp trên toàn thế giới sẽ đạt 644 tỷ đô la vào năm 2025, tăng 76,4% so với năm trước.

Sự bão hòa giống hệt này ngụ ý sự sửa đổi sắp tới. Tôi tin rằng một sự sửa đổi tương tự đang đến, không phải vì AI là xấu, mà vì cùng một động lực đã tạo ra sự quay trở lại của đám mây áp dụng ở đây. Nó đang đến vì các tổ chức đang đẩy mạnh vào các workflow được thúc đẩy bởi AI mà không luôn biết, trong môi trường của riêng họ, câu chuyện kết thúc như thế nào. Khoảng cách áp dụng-so với sự trưởng thành là có thể đo lường được: McKinsey tìm thấy rằng 88% tổ chức hiện báo cáo sử dụng AI thường xuyên trong ít nhất một chức năng, nhưng đa số vẫn đang thử nghiệm và chỉ khoảng 39% báo cáo tác động EBIT ở cấp độ doanh nghiệp.

Đẩy quá mạnh mà không có chiến lược và sự tính toán là không phải là một có thể. Sự sửa đổi đó đến. Nó luôn đến. Bạn đẩy quá mạnh mà không có chiến lược, và cuối cùng kinh tế và thực tế hoạt động sẽ buộc phải tính toán.

Đã có một tên cho mẫu sửa đổi, và nó không phải của tôi. Sự quay trở lại của AI, hành động di chuyển các nhiệm vụ cụ thể ra khỏi hệ thống AI xác suất và trở lại vào workflow quyết định khi những nhiệm vụ đó trở nên ổn định và có thể lặp lại, không phải là một khái niệm tôi đã tạo ra. Đó là một mẫu tôi đang chứng kiến diễn ra. Tôi không đơn độc trong việc chứng kiến nó: Gartner dự báo rằng hơn 40% dự án AI sẽ bị hủy bỏ vào cuối năm 2027, trích dẫn chi phí tăng cao, giá trị kinh doanh không rõ ràng và kiểm soát rủi ro không đầy đủ.

AI Sửa Đổi Trông Như Thế Nào

Để dự đoán sự sửa đổi, nó giúp có định nghĩa sạch cho hai loại workflow liên quan.

Một workflow quyết định là dựa trên quy tắc, có thể dự đoán và lặp lại. Cùng một đầu vào và cùng một quy tắc tạo ra cùng một đầu ra, mỗi lần. Nó nhanh, nó cố định. Nó làm chính xác những gì nó được thiết kế để làm, không nhiều hơn, không ít hơn. Một workflow xác suất sử dụng AI hoặc lý luận dựa trên mô hình để diễn giải ngữ cảnh và tạo ra một câu trả lời có thể. Nó hữu ích khi các quy trình liên quan đến sự mơ hồ, thông tin không cấu trúc hoặc các quyết định phán xét nơi các quy tắc cố định bị phá vỡ và suy luận mang tải.

Với các định nghĩa được thiết lập, câu hỏi về thời gian trả lời chính nó. Các workflow xác suất thường là công cụ phù hợp vào giai đoạn đầu khi các quy trình không được hiểu đầy đủ. Chúng trở nên vấn đề khi các công ty tiếp tục sử dụng chúng khi các quy trình đã được làm rõ.

Một workflow cụ thể làm cho sự khác biệt giữa giai đoạn đầu và giai đoạn sau trở nên cụ thể. Một phần của workflow đó thực sự cần AI. Xác định tài khoản đúng từ một bản ghi âm cuộc gọi, ví dụ, cần suy luận mà một hệ thống quyết định không thể làm. Các phần khác, đính kèm một tệp vào một bản ghi hoặc đăng một thông báo, là các nhiệm vụ quyết định. Một quy tắc cố định, một cuộc gọi API trực tiếp, là cùng một đầu ra mỗi lần. Tôi có tội trong việc này chính mình: tôi đang xây dựng một tự động hóa nội bộ mà nối các bản ghi âm cuộc gọi, định tuyến thông tin vào CRM của chúng tôi, chỉ định các mục hành động và đẩy cập nhật đến Slack.

Sự cám dỗ là chạy tất cả qua AI, và sự cám dỗ đó mang theo một gánh nặng thực sự và lặp lại. Trong khi có sự cám dỗ để chạy toàn bộ qua các cuộc gọi AI, mỗi cuộc gọi AI giới thiệu độ trễ và mang theo chi phí sử dụng và cơ sở hạ tầng. Các hệ thống AI yêu cầu giám sát, quản lý lời nhắc và rào cản, vì mô hình cơ bản đang được phát triển liên tục (và không thể dự đoán) bởi chủ sở hữu của nó. Bạn không bao giờ biết khi nào nó sẽ bắt đầu hoạt động khác; đầu ra có thể thay đổi theo những cách tạo ra vấn đề quản trị ở quy mô lớn, nhanh chóng.

Được chơi đủ xa, gánh nặng đó trở thành lãng phí thuần túy. Hãy nghĩ về một công ty sử dụng AI để phân tích 50.000 vé hỗ trợ. AI xác định năm đường dẫn giải quyết phổ biến nhất. Lúc đầu, AI xử lý định tuyến xác suất: đọc từng vé và đưa ra một phán quyết. Theo thời gian, công ty xác nhận những mẫu đó. Các đường dẫn giải quyết bây giờ đã biết. Chuyển chúng thành các nhánh workflow quyết định không loại bỏ AI khỏi quy trình, nhưng nó loại bỏ việc thực hành thừa của việc trả tiền cho AI để tái khám phá các câu trả lời đã biết.

Đó là thuế xác suất: chi phí thêm, độ trễ và gánh nặng quản trị của việc chạy AI như thời gian chạy cho công việc không còn yêu cầu suy luận xác suất.

Các Mô Hình Hoạt Động Trưởng Thành Trông Như Thế Nào

Nếu chạy công việc đã giải quyết trên AI là một thuế, thì động thái trưởng thành là chia công việc theo loại. Sự trưởng thành của đám mây đã tạo ra cơ sở hạ tầng hỗn hợp, đám mây nơi nó đã kiếm được vị trí của mình, cơ sở hạ tầng chuyên dụng ở mọi nơi khác. Tôi dự đoán sự trưởng thành của AI sẽ tạo ra các hoạt động hỗn hợp với cùng một logic.

Đó là sự chia tách tạo ra một quy tắc hoạt động rõ ràng. Các hệ thống xác suất là có giá trị nơi sự mơ hồ thực sự tồn tại. Con người là mơ hồ. Thông tin không cấu trúc là mơ hồ. Các quy trình không được hiểu đầy đủ là mơ hồ. Suy luận là công cụ phù hợp cho tất cả những điều đó. Phần còn lại của quy tắc cũng quan trọng như nhau: các hệ thống quyết định là nơi quy mô, chi phí, tốc độ và quản trị quan trọng. Lớp xác suất khám phá và diễn giải. Lớp quyết định thực hiện.

Trên thực tế, hai tín hiệu cho bạn biết một workload nhất định thuộc về phía nào:

  1. Nếu bạn tìm thấy nhóm của mình dựa vào AI cho một thứ gì đó đã trở nên ổn định, có thể lặp lại và được hiểu rõ, đó là một ứng cử viên cho sự quay trở lại, vì bạn đang trả thuế xác suất cho công việc quyết định.
  2. Nếu bạn tìm thấy mã quyết định của mình đang được lấp đầy với các trình xử lý ngoại lệ và các yếu tố biến đổi, đó là một dấu hiệu cho thấy bạn có thể thực sự cần AI. Bộ quy tắc đang cố gắng xấp xỉ suy luận.

Trong thực tế, ranh giới đó được vẽ như một ngưỡng tin cậy. Một ngưỡng tin cậy cụ thể, cam kết với một quyết định khi mô hình trên 90% chắc chắn, hoặc thất bại một cách tinh tế dưới nó, thường là nơi ranh giới đó được vẽ trong thực tế.

Điều đó làm lại khuôn khổ những gì chiến thắng với AI thực sự yêu cầu. Các công ty thành công nhất trong việc áp dụng AI sẽ không phải là những công ty sử dụng nó nhiều nhất, mà là những công ty biết khi nào sử dụng nó và khi nào bổ sung nó.

Jon Howe là một nhà lãnh đạo kỹ thuật năng động và hấp dẫn với hơn 20 năm kinh nghiệm giúp các tổ chức hiện đại hóa cơ sở hạ tầng thông qua tự động hóa, điều phối và chiến lược ưu tiên đám mây.

Với tư cách là Kiến trúc sư Giải pháp Chính tại Myriad360, ông làm việc chặt chẽ với các doanh nghiệp để tối ưu hóa hoạt động, giảm ma sát và cho phép các mô hình giao hàng được thúc đẩy bởi DevOps.Thăm Jon trên LinkedIn.