ClouderaNOW Scopri gli agenti AI, il cloud Bursting e i Data fabric per l'AI | 8 aprile

Registrati ora
  • Cloudera Cloudera
  • | Azienda

    Vibecoding e responsabilità sul cloud con David Linthicum

    Cloudera Author Profile Picture
    The AI Forecast, "La vulnerabilità del Vibecoding: come un'AI non controllata può uccidere il ROI del cloud," con David Linthicum

    Nell'episodio 65 di The AI Forecast, "La vulnerabilità del Vibecoding: come un'AI non controllata può uccidere il ROI del cloud", David Linthicum si unisce al conduttore Paul Muller per rivelare i costi nascosti degli ambienti ibridi e multi-cloud e spiegare perché la governance e la resilienza del cloud sono diventate priorità per il consiglio di amministrazione.

    Poiché le interruzioni cloud di alto profilo espongono dipendenze nascoste e singoli punti di guasto, i leader IT devono ripensare la resilienza, la gestione dei dati e la responsabilità negli ambienti cloud ibridi.  

    Ecco cosa è emerso con maggiore evidenza dalla conversazione tra Paul e David:

    Il principale elemento distintivo: affidabilità rispetto a resilienza

    Paul: Resilienza è una parola buffa, perché penso che spesso le persone equiparino la resilienza all'affidabilità, mentre c'è una grande differenza, vero?  

    David: È così. La resilienza è la tua capacità di non lasciare che questi disastri fermino il tuo processo e la tua attività. In altre parole, quali sono il piano A, il piano B e il piano C? Quanto sarà resiliente e tollerante ai guasti? L'affidabilità riguarda fondamentalmente un componente: quanto bene si manterrà e, se dovesse cadere fuori posto, come recuperarlo. La resilienza è tua responsabilità, l'affidabilità no. In genere, se il servizio è fornito da un provider di servizi cloud, la responsabilità è sua, ma tu ne risentirai comunque. Sarai tu a farne le spese. Non riceverai alcun rimborso da questi provider di servizi cloud in caso di interruzione del servizio.  

    Paul: La resilienza è un artefatto architettonico, non una conseguenza di un componente, vero? È il modo in cui si progetta il sistema. Tutto risale all'architettura aziendale.  

    David: È tutta una questione di architettura, e si sviluppa a livello applicativo e aziendale. È necessario costruire e pianificare la resilienza. Non accadrà automaticamente e non è contenuta nei cloud. È qui che la gente è rimasta sorpresa. Credevano di essere completamente immuni a qualsiasi problema, ma ora si rendono conto di essere fallibili come tutti gli altri. Parte della costruzione di un sistema di AI, di un'architettura aziendale o di qualsiasi tipo di pianificazione architettonica riguarda la resilienza. È importante tanto quanto la sicurezza, la governance e tutte le altre questioni che dobbiamo affrontare, se non di più. Deve essere resa operativa, in modo da poter dimostrare con delle metriche che non impedirà all'azienda di lavorare se accade il peggio. In buona sostanza, è necessario spendere soldi e tempo per capirlo.  

    Senza resilienza, non sarai in grado di riprenderti da questo tipo di situazioni.

    Responsabilità e osservabilità in un mondo ibrido

    Paul: Ora molte persone parlano di cloud ibridi, ma sembra, per certi versi, che si tratti di una combinazione dei pregi e dei difetti sia del mondo on premise che di quello cloud. Come possiamo costruire una chiara responsabilità e osservabilità in quello che alla fine sarà un mondo ibrido?  

    David: Se costruiamo soluzioni ibride e multi-cloud, dobbiamo gestire la complessità che fa parte delle soluzioni, e la resilienza sarà un piano di controllo comune che attraversa tutto questo. Molti pensano: "Bene, adesso costruisco questo sistema in modo ibrido, in modo da poter effettuare un failover sui miei sistemi on premise o persino su un altro cloud." Va benissimo e funziona, ma costerà parecchio. Credo che la capacità di comprendere quali siano questi costi e queste risorse, e come gestirli, diventi il principale punto di contesa.  

    Il multi-cloud è ottimo perché consente di utilizzare la migliore tecnologia per costruire sistemi più efficienti, ma la resilienza e l'affidabilità saranno aspetti problematici all'interno di queste architetture. Dico sempre che si può avere resilienza ed efficienza, ma non entrambe. O costruiamo l'architettura per la resilienza, o dovremo affrontare interruzioni tre o quattro volte all'anno che costeranno miliardi all'azienda.  

    Aumento dei costi del cloud e tendenze del ritorno all'on premise

    Paul: Per quanto riguarda cose come interruzioni catastrofiche, superamento dei costi e responsabilità complesse, non sorprende che molte aziende stiano pensando di "rimpatriare" i carichi di lavoro. Qual è la situazione attuale e quali sono alcune delle difficoltà che le persone incontrano quando cercano di riportare alcuni di questi carichi di lavoro on-premise?  

    David: Il problema principale è il costo. Ci sono due livelli. Innanzitutto, circa mezzo milione di dollari è già stato speso in applicazioni e nella migrazione di tutto quanto sul cloud, e ora si dovrebbe spendere una cifra simile per riportare tutto a casa. In secondo luogo, bisogna presentarsi al consiglio di amministrazione e spiegare questa decisione e il percorso da seguire. Si tratta di una conversazione difficile, perché significa riconoscere che il passaggio al cloud, che originariamente ci si aspettava fosse più prezioso e affidabile, non ha dato i risultati previsti. Qualcuno dovrà umiliarsi e spiegare che l'organizzazione deve tornare a un ambiente in cui abbia un maggiore controllo sull'hardware.

    Di solito rivolgersi a provider di colocation e di servizi gestiti è molto più efficiente, ma stanno risentendo dei costi del cloud. E ora che stanno valutando i carichi di lavoro di AI, stanno cercando di accelerare ancora di più questo passaggio perché non possono permettersi il cloud. Anche se il cloud sarà la soluzione più semplice per l'AI, resta la strada di minor resistenza per costruire questi sistemi. Ottieni un intero ecosistema pronto all’uso su richiesta, ma per la maggior parte delle aziende è troppo costoso. Se torniamo lì per ragioni economiche, allora dobbiamo mettere in campo le risorse necessarie per farlo in modo efficace.  

    Paul: Quanti altri sviluppatori, in quante aziende, hanno messo in piedi un piccolo progetto parallelo in un'app di vibe coding che ha generato enormi carichi di lavoro di calcolo o di archiviazione, con conseguenti sforamenti di budget?

    David: Stai programmando dicendo al sistema di AI qual è la tua interpretazione e cosa deve codificare. Il problema è che non coglie le sfumature. Non capisce come gestire le efficienze e finisci per spendere più soldi. E quindi quel genere di cose, la codifica delle vibrazioni, sai, è divertente pensarci, ma il punto è che dobbiamo ottenere un certo controllo umano su queste cose. E più vedo questi sistemi di codifica che escono e, come sa, la maggior parte dei miei clienti li sta provando, e falliscono perché non sono in grado di raggiungere l'efficienza di cui hanno bisogno.

    Segui la conversazione completa con David Linthicum su The AI Forecast su Spotify, Apple Podcasts e YouTube.

     

    Your form submission has failed.

    This may have been caused by one of the following:

    • Your request timed out
    • A plugin/browser extension blocked the submission. If you have an ad blocking plugin please disable it and close this message to reload the page.