700 aziende compromesse.
Google, Adidas, Cisco, LVMH tra le vittime.
E tutto è iniziato da… una telefonata.

Nell’agosto 2025 il mondo della cybersecurity è stato scosso da una delle più gravi violazioni della supply chain SaaS mai registrate: il Salesforce Breach 2025, noto come Salesloft Drift Campaign.

Gli hacker hanno sfruttato token OAuth rubati dall’integrazione Drift per ottenere accessi non autorizzati a Salesforce, innescando un attacco su scala globale.

Un’operazione che non ha sfruttato malware sofisticati, ma social engineering. Una voce dall’altra parte del telefono è bastata per aprire la porta.

In questo articolo analizziamo cos’è successo, le tecniche usate e cosa possiamo imparare per proteggere le aziende da incidenti simili.

Social engineering: il lato umano degli attacchi informatici

Spesso pensiamo che la sicurezza sia solo una questione di tecnologia, firewall o certificazioni ISO. Ma la verità è un’altra: il punto più vulnerabile resta l’essere umano.

Il vishing (voice phishing) sfrutta leve psicologiche come:

• Urgenza → “Devi agire subito o perdi l’accesso.”
• Autorità → “Sono dell’ufficio IT, è solo un controllo.”
• Fiducia → “Ti parlo come un collega, dammi solo un minuto.”

Nel caso Salesforce, i cybercriminali hanno convinto i dipendenti a concedere accessi critici. Una semplice telefonata è bastata per trasformare una vulnerabilità umana in un disastro globale.

Il lato tecnico: OAuth token e supply chain compromessa

Se l’elemento umano è stato la porta d’ingresso, il resto è stato puro attacco informatico.

Dopo il contatto telefonico, gli aggressori hanno sfruttato token OAuth – credenziali che permettono l’accesso senza inserire username e password – per muoversi liberamente negli ambienti Salesforce.

Con queste “chiavi universali” hanno potuto:

• Accedere a dati sensibili;
• Esfiltrare informazioni riservate;
• Propagare l’attacco lungo la supply chain colpendo centinaia di partner.

Come si è svolto l’attacco

L’operazione, attribuita in parte al gruppo ShinyHunters, ha combinato vishing e abuso del protocollo OAuth, trasformando una semplice telefonata in un’azione di esfiltrazione dati su scala globale.

Ripercorriamo insieme lo svolgimento dell’attacco: 

1. Contatto vishing iniziale

L’attacco è iniziato con una telefonata. Fingendosi supporto IT, a volte addirittura di essere Salesforce, gli autori delle minacce hanno contattato i dipendenti dell’azienda con il pretesto di dover risolvere un “ticket di supporto” o un altro problema urgente.

Con un tono autorevole, hanno creato urgenza (“c’è un problema sul tuo account, serve un controllo immediato”) e hanno convinto le vittime a collaborare. L’obiettivo era semplice: creare fiducia e preparare la vittima a seguire le istruzioni.

2. Consenso a un’app OAuth malevola

Una volta guadagnata fiducia, la vittima veniva guidata alla sezione Connected Apps di Salesforce. Qui inseriva un codice di “connessione” che in realtà autorizzava un’app fraudolenta – una versione manipolata del Salesforce Data Loader.

Inconsapevolmente, l’utente concedeva un token OAuth con privilegi elevati, aprendo agli aggressori l’accesso ai dati aziendali.

3. Esfiltrazione e movimento laterale

Con il token OAuth, gli aggressori hanno potuto:

• Scaricare dati sensibili dal CRM (anagrafiche clienti, ticket di supporto, pipeline di vendita);
• Mascherare le richieste come API legittime, rendendo l’attività invisibile ai sistemi di sicurezza;
• Raccogliere anche credenziali MFA e login di altri servizi SaaS (Okta, Office 365, Slack), muovendosi lateralmente verso mailbox, file storage e collaboration tool.

Questa fase ha trasformato un attacco localizzato in un vero supply chain attack con centinaia di vittime.

4. Estorsione e minaccia di data leak

Una volta in possesso dei dati, i criminali hanno contattato le aziende chiedendo riscatti in criptovaluta. In caso di rifiuto, hanno minacciato di pubblicare le informazioni sul dark web o su marketplace illegali.

Molte vittime hanno subito un doppio impatto: violazione dei dati e danno reputazionale.

5. Attacco alla supply chain OAuth (Salesloft Drift Campaign)

Parallelamente, gli aggressori hanno sfruttato l’integrazione Salesloft–Drift con Salesforce per acquisire token OAuth già compromessi. Questo ha permesso di scalare l’attacco a oltre 700 aziende, tra cui brand globali come Google, Adidas, Cisco e LVMH.

Perché assistiamo a così tante violazioni simili?

Il Salesforce Breach 2025 non è un caso isolato: rientra in una serie di attacchi che hanno colpito aziende come Chanel, Google, Air France e KLM, sfruttando lo stesso modello. Ma perché queste campagne sono così frequenti ed efficaci?

1. I fornitori terzi sono il nuovo punto d’ingresso

Gli aggressori sanno che i sistemi core delle grandi aziende (ERP, pagamenti, infrastruttura interna) sono ben difesi. Molto più vulnerabili sono invece i fornitori SaaS esterni e le piattaforme CRM.

Compromettendo un’unica integrazione (come Drift o Salesloft), i criminali possono accedere contemporaneamente ai dati di decine o centinaia di aziende. È la logica del supply chain attack: colpisci un nodo e si aprono molte porte.

2. L’ingegneria sociale e OAuth sono armi silenziose

Il mix di vishing e abuso di OAuth/Connected Apps è devastante.

• Il vishing funziona perché sfrutta il lato umano: fiducia, urgenza, autorità;
• OAuth rende l’attacco invisibile, perché gli accessi concessi appaiono come legittimi.

Questa combinazione permette di aggirare i controlli tradizionali basati su credenziali o endpoint, mantenendo accessi persistenti difficili da rilevare.

3. Permessi eccessivi amplificano l’esplosione

In molte aziende, le app connesse a Salesforce hanno privilegi troppo ampi: possono leggere grandi quantità di dati o accedere a moduli non strettamente necessari.

Quando un token OAuth di questo tipo viene compromesso, l’impatto è enorme: gli aggressori ottengono dati sensibili di clienti, pipeline commerciali e ticket di supporto in un’unica mossa.

Il problema è accentuato da una governance debole: spesso non esiste un inventario aggiornato delle app collegate né un monitoraggio attivo dei loro permessi.

4. I dati rubati alimentano nuovi attacchi

I record CRM hanno un valore enorme: possono essere rivenduti, usati per campagne di phishing mirato o sfruttati per nuovi cicli di vishing ancora più convincenti.

Questo crea un effetto moltiplicatore: ogni breach non solo danneggia le vittime dirette, ma genera opportunità per future campagne globali di social engineering e cyber estorsione.

Costruire resilienza: tecnologia, processi, persone

Il Salesforce Breach 2025 non è stato causato da una vulnerabilità tecnica sconosciuta, ma dall’abuso di meccanismi legittimi (OAuth) combinati con ingegneria sociale. Questa dinamica ci lascia alcune lezioni fondamentali per rafforzare la resilienza delle aziende.

1. La tecnologia da sola non basta

Firewall, antivirus e sistemi EDR sono indispensabili, ma non sufficienti. Se un dipendente fornisce consapevolmente (anche se ingannato) le proprie credenziali o approva un’app malevola, nessun software può impedirlo.

La sicurezza deve essere multilivello: strumenti, processi e cultura.

2. I processi sono la prima linea di difesa

Ogni organizzazione dovrebbe avere procedure chiare e verificate per:

• Gestire richieste urgenti ricevute via telefono o email;
• Verificare l’identità di chi si presenta come IT o supporto esterno;
• Autorizzare nuove applicazioni SaaS e Connected Apps.

Un processo ben definito riduce il rischio che una decisione affrettata di un singolo diventi una falla sistemica.

3. Le persone sono il vero firewall

Il Salesforce breach dimostra che la formazione non è un “nice to have”, ma un pilastro di sicurezza. Un dipendente consapevole riconosce segnali di vishing (tono di urgenza, pressioni, richieste insolite) e sa dire “no”.

Programmi di security awareness e simulazioni regolari trasformano il personale nel primo vero human firewall dell’azienda.

4. La governance delle app SaaS è critica

Un altro insegnamento chiave è l’importanza di gestire in modo stretto le app connesse e i permessi OAuth.

• Inventario aggiornato delle integrazioni attive;
• Policy “least privilege” per limitare i dati accessibili;
• Monitoraggio costante dei log e delle API.

Così si riduce drasticamente la superficie d’attacco.

5. La resilienza è continua, non un traguardo

La cybersecurity non è mai “finita”: ogni integrazione nuova, ogni dipendente assunto, ogni cambiamento nei processi può introdurre nuove vulnerabilità.

Il caso Salesforce insegna che la vera difesa è la resilienza organizzativa, che si costruisce nel tempo con:

• Aggiornamenti costanti;
• Formazione continua;
• Revisione periodica delle policy.

Conclusione

Il Salesforce Breach 2025 resterà nella storia della cybersecurity non per un malware innovativo, ma per la sua semplicità: è bastata una telefonata ben orchestrata per colpire oltre 700+ aziende globali.

La lezione è chiara: la cybersecurity non è solo tecnologia. Firewall, MFA e sistemi avanzati sono indispensabili, ma senza processi solidi e persone consapevoli diventano difese fragili.
Questo incidente dimostra che il fattore umano è al tempo stesso l’anello più debole e la risorsa più potente nella protezione aziendale.

Per difendersi serve un approccio integrato fatto di:

• Tecnologia → monitoraggio, alert, controlli granulari su OAuth;
• Processi → policy di verifica per richieste anomale e gestione sicura delle app SaaS;
• Persone → programmi di cybersecurity awareness che trasformino i dipendenti in un vero firewall umano.

Il Salesforce breach non è un caso isolato, ma un campanello d’allarme: ogni organizzazione, grande o piccola, è un potenziale target. La differenza sta nella preparazione.

Vuoi approfondire dal vivo questo tema?

Partecipa alla Commit University di settembre!

Speaker: Diego Sarnataro, Founder & CEO di 10punto10
Dove: Firenze, sede Commit Software
Quando: 25 settembre 2025
Ingresso gratuito + aperitivo incluso – Iscriviti qui

Un’occasione per scoprire da vicino come difendere la tua azienda da attacchi di social engineering, con esempi concreti, casi reali e strategie applicabili da subito.

L'articolo Salesforce Breach 2025 proviene da commit software.

European Accessibility Act: cosa prevede davvero 

L’European Accessibility Act (Direttiva UE 2019/882), recepito in Italia con il D.lgs. 82/2022, è una normativa europea che mira a garantire che prodotti e servizi digitali siano accessibili anche alle persone con disabilità. Il suo obiettivo è armonizzare le regole tra i paesi dell’UE e migliorare la partecipazione di tutti alla società e al mercato unico, anche grazie alle tecnologie. 

A partire dal 28 giugno 2025, il regolamento sarà pienamente applicabile per una serie di prodotti e servizi destinati al pubblico, tra cui: 

• Siti web e applicazioni mobili di imprese private (soprattutto nel settore commerciale) 

• Servizi bancari 

• E-commerce 

• Terminali self-service (come ATM, biglietterie automatiche, chioschi informativi) 

• Servizi di trasporto (prenotazione e check-in digitali) 

• Lettori di e-book e relativi software 

• Servizi di comunicazione elettronica (come le app di messaggistica) 

Non riguarda solo il settore pubblico, ma anche le imprese private, purché i loro prodotti e servizi rientrino in quelli elencati. La legge impone che tali strumenti siano utilizzabili da chiunque, indipendentemente da disabilità visive, uditive, motorie o cognitive. 

In caso di violazione, le autorità competenti possono imporre sanzioni, fino al ritiro dei prodotti dal mercato. 

È importante sottolineare che le norme europee non sostituiscono le leggi nazionali già esistenti, ma si aggiungono a esse. Per questo motivo, l’accessibilità non è un obbligo nuovo, ma un rafforzamento di responsabilità già esistenti. 

Oltre la superficie normativa 

L’attenzione crescente verso l’accessibilità digitale non nasce soltanto da obblighi legati al nuovo regolamento europeo. L’European Accessibility Act rappresenta infatti solo uno degli elementi del più vasto quadro normativo che regolamenta l’accessibilità. In Italia, ad esempio, già da anni sono in vigore norme come la legge 67/2006 e il d.lgs. 216/2003, che consentono a qualsiasi persona discriminata nell’accesso a servizi digitali — pubblici o privati — di intraprendere azioni legali. Non si tratta solo di risarcimenti: il giudice può ordinare la rimozione delle barriere digitali entro un termine, con sanzioni giornaliere in caso di inadempienza. 

È quindi fuorviante credere che solo chi rientra esplicitamente nei destinatari dell’Act europeo debba preoccuparsi di accessibilità. Ogni organizzazione, indipendentemente dalla natura giuridica o dal volume d’affari, dovrebbe interrogarsi sul grado di accessibilità dei propri canali digitali — non solo per dovere legale, ma anche per una questione di responsabilità sociale e sostenibilità. 

Accessibilità come prodotto da banco? Meglio evitare 

Parallelamente alla crescente attenzione normativa, si assiste a un proliferare di offerte commerciali che promettono soluzioni rapide per la conformità. In molti casi, queste promesse si rivelano illusioni: strumenti automatizzati che forniscono “analisi” superficiali, “audit” espressi da 48 ore, o addirittura plugin miracolosi che “aggiustano” l’accessibilità senza intervenire realmente sul codice sorgente. 

La realtà è più complessa. Nessun software automatizzato è in grado di individuare, da solo, tutte le problematiche di accessibilità. Le linee guida WCAG (Web Content Accessibility Guidelines) lo affermano chiaramente: molte valutazioni richiedono un’interpretazione umana, un contesto, un test concreto del percorso utente. Gli strumenti possono coprire circa il 30% dei criteri previsti — il resto richiede esperienza, attenzione, tempo. 

Affidarsi a valutazioni “a peso” (ad esempio, per numero di pagine) significa ignorare che l’accessibilità non è una sommatoria di errori minori, ma un equilibrio tra usabilità, percorribilità, chiarezza. Un menu inaccessibile tramite tastiera può bloccare completamente l’accesso a un sito, ben più di decine di immagini senza alternativa testuale. 

Percentuali e promesse: metriche che ingannano 

L’uso di percentuali per descrivere il livello di accessibilità di un sito web è spesso fuorviante. Affermazioni come “il sito è accessibile all’82,5%” sono prive di reale significato se non accompagnate da una valutazione qualitativa dei problemi rilevati. Inoltre, basarsi su metriche automatiche significa valutare solo una porzione minima dei requisiti previsti e, soprattutto, non distinguere tra errori bloccanti e marginali. 

Un errore nella descrizione di un’immagine decorativa non ha lo stesso impatto di un errore che impedisce a una persona cieca di concludere un acquisto online. Tuttavia, entrambi vengono registrati come “errori”, senza contesto né ponderazione. 

Non solo vetrine: l’accessibilità è anche interna 

Una delle convinzioni più radicate — e sbagliate — è che l’accessibilità riguardi esclusivamente i prodotti rivolti al pubblico. In realtà, le normative attuali coprono anche gli strumenti e i documenti utilizzati internamente. Un software gestionale inaccessibile può compromettere l’autonomia di un dipendente con disabilità, esponendo l’organizzazione a rischi legali e reputazionali. 

Lo stesso vale per i documenti digitali: la norma tecnica europea EN 301 549 li include esplicitamente tra gli elementi da rendere accessibili. Non si tratta solo di PDF pubblicati online, ma anche di documenti interni, generati da software aziendali o redatti manualmente. E anche in questo caso, gli strumenti automatici possono offrire un supporto iniziale, ma la verifica reale va fatta da persone competenti. 

La falsa sicurezza della “parziale conformità” 

Una prassi ormai comune è quella di dichiarare la “parziale conformità” ai criteri di accessibilità, come se fosse un traguardo. In realtà, la normativa europea prevede che tale stato rappresenti un punto di partenza verso la piena conformità, non un obiettivo soddisfacente. 

Dichiarare pubblicamente la non conformità a decine di criteri WCAG non significa essere “a posto con la legge”, ma piuttosto esporsi a una responsabilità ben precisa: quella di adottare misure correttive in tempi ragionevoli. Non farlo significa restare vulnerabili, sia dal punto di vista tecnico che legale. 

Soluzioni “magiche”? Meglio diffidare 

Tra le proposte più insidiose ci sono gli overlay di accessibilità: strumenti che promettono di rendere un sito accessibile senza modificare il codice sorgente. In realtà, si tratta spesso di tecnologie invasive, che interferiscono con i lettori di schermo o sovrascrivono stili senza migliorare l’esperienza reale degli utenti. 

Negli Stati Uniti, diverse aziende che hanno promosso questi prodotti sono già state sanzionate per pubblicità ingannevole. In Europa, il rischio è di importare lo stesso modello, con l’illusione che l’accessibilità possa essere delegata a un componente aggiuntivo. In realtà, l’unico approccio sostenibile è quello che integra l’accessibilità nei processi di sviluppo, fin dall’inizio. 

Conclusioni: l’accessibilità è un processo, non un prodotto 

La rincorsa alla conformità rapida, economica e superficiale sta minando il significato autentico dell’accessibilità digitale. Le soluzioni facili non garantiscono né l’adempimento normativo né, tanto meno, l’effettiva accessibilità per le persone con disabilità. 

Includere l’accessibilità nella progettazione, nello sviluppo e nella gestione dei servizi digitali non è un’opzione, ma una necessità. Proprio come per la sicurezza informatica o la privacy, serve una cultura condivisa, una strategia a lungo termine e investimenti mirati. Perché in fondo, garantire l’accessibilità non è solo un obbligo: è un gesto concreto di inclusione. 

L'articolo Accessibilità digitale: oltre la velocità, serve consapevolezza proviene da commit software.

Negli ultimi anni, il ruolo dello sviluppatore ha iniziato a cambiare rapidamente. L’intelligenza artificiale generativa non ha reso superfluo il lavoro umano, ma lo ha trasformato. Oggi, chi scrive codice con efficacia non è necessariamente chi conosce ogni singola funzione a memoria, ma chi sa usare gli strumenti nel modo più fluido possibile.
È da qui che nasce il concetto di vibe coding.

Cos’è il vibe coding?

Il vibe coding non è una metodologia codificata, ma un’attitudine: saper entrare nel flusso di lavoro tra prompt, codice generato e refactor. Non è solo questione di automatizzare, ma di saper guidare il processo. Non si tratta più solo di scrivere codice, ma di orchestrare sistemi complessi con l’AI come partner operativo.

Chi lavora così ha un obiettivo chiaro: ottenere risultati nel modo più efficace possibile. Non si blocca davanti a un errore, non perde ore su un dettaglio tecnico irrilevante. Piuttosto, interagisce continuamente con l’AI per esplorare soluzioni, testarli, e adattarli al contesto. Prompt, refine, iterate. È un ciclo continuo, veloce e orientato al risultato.

Come l’AI cambia la seniority nello sviluppo software

Questo approccio cambia anche il concetto di seniority. Non basta più “sapere tutto”. Serve saper cercare, filtrare, validare. Serve intuizione, senso critico, capacità di riconoscere cosa è utile davvero. In questo senso, il vibe coding valorizza chi ha esperienza, ma la mette al servizio della velocità e dell’adattabilità, non del controllo assoluto.

L’AI non sostituirà gli sviluppatori. Ma chi non sa lavorare con l’AI, rischia di essere sostituito da chi lo sa fare. Per questo è importante investire oggi in una nuova forma mentis: più aperta, meno lineare, più orientata alla collaborazione tra umano e macchina.
Non è solo un cambio di strumenti. È un cambio di cultura.

Perché sviluppare una nuova mentalità è fondamentale

Per rimanere competitivi, gli sviluppatori devono investire in una nuova forma mentis: più aperta, meno lineare, più orientata alla collaborazione tra umano e macchina. Nei team che adottano questo approccio, l’AI non è un assistente occasionale: è parte del processo. Gli sviluppatori non scrivono ogni riga, ma decidono quali sono quelle che contano. Danno contesto, correggono la direzione, impostano il design del sistema.
È un lavoro diverso, più alto livello, più strategico.

Il futuro dello sviluppo software: più strategico e collaborativo

Il vibe coding non sostituisce la conoscenza tecnica. Ma cambia il modo in cui questa conoscenza viene applicata. Chi padroneggia questo nuovo equilibrio può costruire più in fretta, validare prima, sbagliare meglio. E soprattutto, imparare di continuo.

Il futuro del software non sarà scritto solo da chi scrive codice, ma da chi sa costruire un processo produttivo in cui umano e AI collaborano senza attriti. E chi riesce a farlo, oggi, ha un vantaggio competitivo reale.

Fonte: Articolo di Alexio Cassani

Vuoi vedere il vibe coding in azione?

Partecipa all’evento “Dal vibe coding all’AI-assisted coding”
15 maggio, ore 18:30 – presso Commit Software
Con Alexio Cassani esploreremo i migliori tool di AI generativa per sviluppatori, con demo pratiche e casi reali.

Posti limitati – Iscriviti subito e scopri come l’AI sta cambiando il modo di programmare.

L'articolo AI e sviluppo software: come il vibe coding cambia il ruolo degli sviluppatori proviene da commit software.

Il 27 marzo 2025 è stato un giorno importante, non solo per l’Albania ma anche per la nostra realtà fiorentina: Davide Rogai, nostro CSO & CMO, è stato eletto Presidente di Confindustria Albania per il quadriennio 2025–2029. 

Una nomina che ci riempie di orgoglio perché, se oggi siamo presenti a Tirana, il merito è anche – e soprattutto – della sua visione, della fiducia che ha sempre riposto nel potenziale di questo Paese e di quel legame profondo che ha saputo costruire e coltivare fin dal 2014.

Tutto è iniziato con una missione di tre giorni

Tutto è cominciato nel 2014, quando Davide è volato a Tirana per la prima volta. Tre giorni, pochi contatti, tante incognite, ma un’idea chiara: creare un ponte tra Firenze e l’Albania, dando vita ad un polo operativo dedicato allo sviluppo software e capace di valorizzare i giovani talenti locali. 

Da quell’intuizione, e da quel primo viaggio, è nata la sede albanese di Commit Software, oggi Growing Tree Shpk, di cui Davide è diventato amministratore unico l’anno successivo. È qui che ha preso forma il primo team di sviluppatori Commit al di fuori dell’Italia: cinque giovani, tre uomini e due donne, selezionati dopo un percorso formativo su misura.

Tirana, una seconda casa

Quel piccolo team è cresciuto negli anni, così come il nostro impegno nella formazione con workshop, collaborazioni con le università, percorsi di mentoring. Con il tempo siamo diventati un punto di riferimento per gli sviluppatori albanesi, senza mai perdere di vista ciò che per noi conta di più: il valore umano del lavoro. 

A Tirana, i nostri colleghi non sono semplicemente “risorse”, ma persone con cui abbiamo costruito relazioni solide ed autentiche, investendo nel loro percorso di crescita, sia personale che professionale. Alcuni di loro sono persino venuti in Italia e si sono stabiliti in Toscana, rafforzando ancora di più quel legame che, ormai, va oltre ogni confine. Per noi, Tirana per noi non è solo un luogo di lavoro ma una vera e propria seconda casa. E da un anno, lo è diventata anche Scutari.

Crescere insieme, oltre i confini

Grazie all’esperienza diretta sul campo, Davide ha vissuto in prima persona la straordinaria trasformazione economica e culturale dell’Albania. Un Paese che oggi offre grandi opportunità, specialmente nel settore tecnologico e digitale, dove si respira un’energia positiva e un desiderio autentico di crescita. Ma è anche un contesto che pone sfide, in particolare sul fronte delle competenze trasversali e della formazione pratica.

Ed è proprio lì che abbiamo deciso di fare la nostra parte, offrendo strumenti concreti per colmare il divario tra sapere teorico e mondo del lavoro. Abbiamo incontrato talento, entusiasmo e una forte voglia di costruire. E, in cambio, abbiamo sempre dato quello che promettevamo.

In Albania, mantenere la parola, la besa, è sacro. Noi lo abbiamo fatto, giorno dopo giorno, e questo ha fatto la differenza. È così che ci siamo guadagnati la fiducia di un popolo che, troppo spesso, è rimasto deluso da chi è arrivato dall’Italia solo per prendere, senza costruire.

Con il tempo, il rapporto con i colleghi albanesi è diventato qualcosa che va oltre il lavoro: una vera squadra, una famiglia, un legame fondato sul rispetto reciproco e sulla fiducia. 

Un polo d’eccellenza tra Scutari e Tirana

Nel 2024, con l’ingresso in Dilaxia, digital company con sede a Bologna e uffici a Scutari, abbiamo unito le forze dando vita a Dilaxia Nova: una realtà che integra le competenze di due aziende complementari ed entrambe orientate verso l’innovazione. Oggi contiamo su un team di oltre 50 esperti, specializzati nello sviluppo software su misura e nel monitoraggio continuo, 24/7.

Un altro tassello importante in un progetto che guarda sempre più lontano.

Una storia di comunità, un impegno per il futuro

Nel suo primo intervento come Presidente di Confindustria Albania, Davide ha voluto condividere un aneddoto personale: l’esondazione che ha colpito il suo quartiere a Sesto Fiorentino e la straordinaria mobilitazione dei giovani per ripristinare l’oratorio distrutto. 

Una metafora potente che parla di comunità, impegno e futuro condiviso. Gli stessi valori che continueranno a guidare il lavoro di Davide in Albania, al servizio di una nuova generazione di imprenditori italiani in un Paese in piena trasformazione.

Un augurio da tutto il team

A nome di tutto il team di Commit, non possiamo che augurare a Davide buon lavoro per questa nuova, importante avventura. Siamo certi che la sua esperienza, visione ed energia, porteranno un valore aggiunto a tutta la comunità imprenditoriale italo-albanese.

L'articolo Davide Rogai è stato eletto Presidente di Confindustria Albania proviene da commit software.

Dal lancio di GitHub Copilot nel 2021, l’obiettivo è stato chiaro: semplificare il lavoro degli sviluppatori con un assistente AI in grado di supportarli nella scrittura di codice migliore. Il nome stesso riflette la convinzione che l’intelligenza artificiale non debba sostituire lo sviluppatore, ma affiancarlo. Come ogni valido copilota, può operare in autonomia, ad esempio fornendo feedback sulle pull request, risolvendo vulnerabilità di sicurezza o suggerendo strategie per l’implementazione di una funzionalità.

Oggi GitHub Copilot si evolve con un’intelligenza ancora più agentica, introducendo la modalità agente e rendendo Copilot Edits disponibile per tutti gli utenti di VS Code. Inoltre, viene aggiunto Gemini 2.0 Flash al selettore di modelli e presentata un’anteprima del nuovo agente autonomo di Copilot, nome in codice Project Padawan. Dai completamenti di codice alla chat, dalle modifiche multi-file alla gestione dello spazio di lavoro, Copilot continua a mettere gli sviluppatori al centro del processo creativo, alleggerendo i compiti ripetitivi per lasciare più spazio alle attività che contano davvero.

Modalità agente disponibile in anteprima 

La nuova modalità agente di GitHub Copilot è in grado di iterare sul proprio codice, individuare errori e correggerli automaticamente. Può anche suggerire comandi da terminale e chiedere di eseguirli, analizzando gli errori di runtime con capacità di auto-riparazione.

In questa modalità, Copilot non si limita a iterare sul proprio output, ma anche sul risultato di tale output, continuando a iterare fino a quando tutte le sottoattività necessarie per completare il prompt non saranno state eseguite. Copilot ora non si limita a completare l’attività richiesta, ma può dedurre attività aggiuntive non specificate, ma comunque essenziali per il corretto funzionamento della richiesta principale. Inoltre, è in grado di rilevare i propri errori, eliminando la necessità di copiare e incollare tra terminale e chat.

Un esempio concreto di utilizzo di GitHub Copilot in modalità agente potrebbe essere la creazione di un’app web per monitorare l’allenamento per una maratona. Per avviare la modalità agente, è necessario scaricare VS Code Insiders e abilitare l’impostazione relativa a GitHub Copilot Chat.

Nel pannello Modifiche Copilot, basta passare dalla modalità “Modifica” a “Agente” accanto al selettore modello.

La modalità agente cambierà il modo in cui gli sviluppatori lavorano all’interno del loro editor. Per questo motivo, verrà estesa a tutti gli IDE supportati da Copilot. Si riconosce che la versione Insiders attuale non è perfetta, ma si accoglie con favore il feedback degli utenti mentre vengono apportati miglioramenti sia a VS Code che alla tecnologia agentica nei prossimi mesi.

Copilot Edits, ora disponibile in VS Code 

Annunciato al GitHub Universe nell’ottobre scorso, Copilot Edits unisce il meglio di Chat e Inline Chat, offrendo un flusso conversazionale e la possibilità di apportare modifiche inline su un set di file gestiti. Il feedback degli utenti fornito in passato ha giocato un ruolo cruciale nel rendere disponibile questa funzionalità come versione stabile (GA) in VS Code.

Con Copilot Edits, è possibile specificare un set di file da modificare e, successivamente, utilizzare il linguaggio naturale per comunicare a GitHub Copilot le proprie necessità. Copilot Edits applica modifiche in linea direttamente nell’area di lavoro, su più file simultaneamente, grazie a un’interfaccia utente progettata per un’iterazione rapida. In questo modo, gli sviluppatori possono rimanere concentrati sul codice, rivedendo le modifiche suggerite, accettando quelle valide e facendo iterazioni con richieste di follow-up.

Dietro le quinte, Copilot Edits sfrutta un’architettura a doppio modello per migliorare l’efficienza e l’accuratezza dell’editing. Un modello linguistico di base considera l’intero contesto della sessione di editing per generare i suggerimenti di modifica iniziali. È possibile scegliere tra vari modelli linguistici, come GPT-4o, o1, o3-mini di OpenAI, Claude 3.5 Sonnet di Anthropic e, ora, Gemini 2.0 Flash di Google. Per ottimizzare l’esperienza, è stato sviluppato un endpoint di decodifica speculativa, progettato per applicare rapidamente le modifiche ai file. Le modifiche suggerite dal modello linguistico vengono inviate all’endpoint di decodifica speculativa, che propone tali modifiche in linea nell’editor.

Copilot Edits funziona perché permette all’utente di essere sempre al comando, dall’impostazione del contesto giusto all’accettazione delle modifiche. L’esperienza è iterativa: se il modello commette un errore, è possibile rivedere le modifiche su più file, accettare quelle corrette e ripetere il processo finché non si arriva alla soluzione ottimale. Una volta accettate le modifiche, è possibile eseguire il codice per verificarle e, se necessario, annullare le modifiche in Copilot Edits per tornare a uno stato di lavoro precedente. Copilot Edits si trova nella barra laterale secondaria (di default a destra), permettendo di interagire con altre viste nella barra laterale primaria, come Explorer, Debug o Source Control, mentre si esaminano le modifiche proposte. Ad esempio, è possibile eseguire test unitari nella vista Testing a sinistra mentre si utilizza Copilot Edits a destra, per verificare se le modifiche proposte superano i test.

L’utilizzo vocale con Copilot Edits risulta naturale, facendo sembrare l’interazione fluida e colloquiale, come se si stesse collaborando con un collega esperto, seguendo lo stesso tipo di flusso iterativo tipico della programmazione in coppia.

Il prossimo passo sulla roadmap prevede il miglioramento delle prestazioni dell’endpoint di decodifica speculativa per applicare le modifiche, supportare le transizioni in Copilot Edits da Copilot Chat preservando il contesto, suggerire file per il set di lavoro e consentire l’annullamento dei blocchi di modifiche suggerite. Per provare questi miglioramenti in anticipo, è possibile utilizzare la versione Insiders di VS Code e la versione pre-release dell’estensione GitHub Copilot Chat. Per contribuire a migliorare la funzionalità, è possibile segnalare eventuali problemi nel repository.

Oltre alla disponibilità generale in VS Code, Copilot Edits è ora disponibile in anteprima anche per Visual Studio 2022.

Fonte: Thomas Dohmke.

L'articolo GitHub Copilot: Introduzione alla modalità agente proviene da commit software.

Introduzione: Il Ruolo dell’AI nella Cybersecurity

Nel panorama odierno della sicurezza informatica, l’intelligenza artificiale (AI) si presenta come una promettente alleata per rafforzare le difese contro le minacce sempre più sofisticate. Tuttavia, insieme alle aspettative elevate, emergono anche sfide e malintesi su ciò che l’AI può realmente offrire. Questo articolo esplora due aree chiave in cui l’AI si intreccia con la cybersecurity, analizzando sia le potenzialità che i limiti di queste applicazioni.

Automazione dei Penetration Test con Gemelli Digitali

La prima frontiera è rappresentata dall’utilizzo dell’AI per automatizzare i penetration test attraverso l’impiego di gemelli digitali. Questi ambienti simulati replicano sistemi reali e consentono di modellare tattiche, tecniche e procedure (TTPs) tipiche degli attaccanti.

Vantaggi:

• Efficienza: L’AI accelera l’identificazione dei percorsi di attacco, permettendo alle organizzazioni di agire tempestivamente.
• Copertura estesa: I gemelli digitali offrono un ambiente sicuro in cui testare attacchi su larga scala senza compromettere i sistemi reali.

Limiti:

• Complessità delle simulazioni: Creare un gemello digitale accurato richiede risorse significative e una profonda comprensione dei sistemi da replicare.
• Accuratezza: Le simulazioni possono non riflettere appieno le dinamiche del mondo reale, portando a risultati fuorvianti.

Nonostante queste sfide, l’integrazione dell’AI nei penetration test rappresenta un passo avanti per anticipare le mosse degli attaccanti e rafforzare le strategie di difesa.

Network Detection and Response: L’AI per il Rilevamento delle Minacce

La seconda applicazione dell’AI nella cybersecurity si concentra sui sistemi di Network Detection and Response (NDR). Qui, il machine learning analizza enormi quantità di dati di rete in tempo reale, identificando anomalie che potrebbero indicare attività malevole.

Vantaggi:

• Rilevamento in tempo reale: L’AI riduce i tempi di reazione alle minacce, migliorando la protezione.
• Adattabilità: Gli algoritmi di machine learning possono evolversi per riconoscere nuovi schemi di attacco.

Illusioni:

• Falsi positivi: La sensibilità degli algoritmi può generare un alto numero di alert, creando confusione.
• Dipendenza dai dati: La qualità del rilevamento dipende dalla disponibilità di dati completi e accurati.

Illusioni e Speranze: Una Visione Critica

In entrambe le applicazioni emergono illusioni comuni legate all’AI, come l’idea che possa eliminare completamente il rischio o funzionare in modo autonomo senza supervisione umana. Allo stesso tempo, ci sono speranze realistiche, come la capacità dell’AI di migliorare significativamente la velocità e la precisione delle risposte agli attacchi.

Conclusione

L’intelligenza artificiale è destinata a rivoluzionare la cybersecurity, ma è essenziale bilanciare l’entusiasmo con un’analisi critica delle sue reali potenzialità. Solo comprendendo i suoi limiti e sfruttando al massimo i suoi punti di forza, le organizzazioni potranno sviluppare strategie di difesa più efficaci e resilienti.

Ti aspettiamo alla Commit University di giovedì 23 gennaio dove esploreremo questo argomento con Fabrizio Baiardi ed Emanuele Briganti.

Clicca qui per registrarti!

L'articolo Cybersecurity & AI: Illusioni e Speranze proviene da commit software.

In questo articolo verrà esplorato il concetto di Platform Engineering, analizzandone le interpretazioni e implementazioni all’interno delle organizzazioni. L’obiettivo è rispondere alla domanda: “Le Internal Developer Platforms dovrebbero limitarsi alla fornitura self-service di infrastrutture e al deployment delle applicazioni?”

Le organizzazioni affrontano il Platform Engineering in modi differenti:

• Alcune sviluppano strumenti self-service per la gestione dell’infrastruttura, offrendo maggiore autonomia ai team di sviluppo.
• Altre si concentrano sull’esperienza degli sviluppatori, semplificando le fasi di coding e deployment.
• Alcune adottano un approccio centrato su marketplace, creando repository di componenti riutilizzabili come container, dati e API.

Sebbene le attuali pratiche di Platform Engineering affrontino con efficacia molti aspetti legati alla semplificazione delle attività, vi sono altre aree che richiedono maggiore attenzione. Ambiti come dati, machine learning, API, sicurezza e privacy risultano fondamentali per migliorare il ciclo di vita dei prodotti software. È necessario chiedersi se questi team possano trarre vantaggio dalle pratiche di Platform Engineering attualmente in uso.

Ampliando il focus oltre un singolo aspetto, si può garantire un’esperienza più completa e migliorata per tutti gli utenti.

Il Platform Engineering dovrebbe includere l’intera catena del valore end-to-end per offrire prodotti e applicazioni agli utenti finali in modo efficace. Spesso, viene associato esclusivamente alla semplificazione dell’infrastruttura e delle pratiche DevOps, con l’obiettivo primario di fornire una piattaforma self-service per gli sviluppatori. Tuttavia, mantenere questa visione limitata rischia di creare nuove barriere tra Platform Engineers e sviluppatori, simili a quelle che in passato dividevano i team IT Operations dagli sviluppatori. Inoltre, è indispensabile considerare anche ingegneri che si occupano di dati, ML, API e altre discipline.

L’espansione delle pratiche di Platform Engineering e dei relativi strumenti per abbracciare l’intero spettro delle applicazioni digitali può rappresentare un’evoluzione significativa, includendo aspetti non tradizionalmente associati a una piattaforma.

Ad esempio, possono essere considerati parte di una piattaforma:

• un Design System riutilizzabile da più team;
• un repository di librerie;
• un catalogo di metadati;
• accordi di lavoro tra team;
• un insieme di linee guida per garantire conformità legale e normativa;
• standard che le applicazioni devono rispettare.

Questa espansione potrebbe essere definita Platform Engineering ++. Gli elementi centrali includerebbero infrastruttura e DevOps, ai quali si aggiungerebbero Data/ML Engineering e la composabilità del software (API, eventi, micro frontend, librerie e tutti gli aspetti di un’applicazione software che possono essere riutilizzabili ed evoluti con un approccio Inner Source).

Questa proposta mira a offrire un approccio più completo ed efficace per lo sviluppo e la gestione delle applicazioni. Nei paragrafi successivi verranno fornite ulteriori motivazioni a supporto di questa visione.

Introduzione alle Piattaforme: una metafora

Come una biblioteca dove le persone portano libri da condividere e prendono in prestito libri da leggere, le piattaforme rappresentano uno spazio in cui condividere risorse. Nel mondo digitale, le piattaforme fungono da biblioteche virtuali, consentendo agli utenti di accedere e condividere una vasta gamma di risorse.

Una biblioteca può essere vista come una piattaforma in cui le risorse (Assets) vengono fornite sotto forma di libri, video, articoli e altro. La biblioteca offre funzionalità (Capabilities) come collezioni catalogate, sale lettura, caffetterie, e consente agli utenti di sfruttare queste funzionalità tramite un assistente di ricerca, un sito web o un servizio in abbonamento. I bibliotecari svolgono un ruolo fondamentale nel mantenere tutto organizzato e funzionante, offrendo un’esperienza self-service a un pubblico che può includere privati, scuole e altri gruppi.

Gli utenti della biblioteca non sono solo lettori, ma anche potenziali autori. Possono trarre ispirazione, raccogliere dati e formulare tesi basandosi sui materiali presenti in biblioteca, utilizzandoli per creare nuove opere.

Internal Developer Platforms

In questa analogia, i bibliotecari possono essere paragonati ai Platform Engineers. Il loro obiettivo principale è garantire che gli utenti della piattaforma ricevano servizi di alta qualità e vivano un’esperienza soddisfacente durante l’interazione con essa. Nella metafora, i libri rappresentano risorse e strumenti, come:

• Un cluster Kubernetes completo di software e configurazioni necessarie.
• Una CRD di Crossplane per creare una risorsa infrastrutturale.
• Un topic Kafka per lo streaming di dati.
• Un prodotto di dati disponibile per il consumo.
• Una libreria software per la registrazione dei log nel formato corretto, inclusa la traceId.
• Una libreria di componenti web per la composizione in un micro frontend.
• Un’API per avviare pagamenti tramite un provider di pagamento digitale.
• Un’applicazione completa accessibile agli utenti finali.

Le strutture di una biblioteca possono essere paragonate, ad esempio, a:

• Un catalogo di servizi che elenca tutte le risorse consumabili e componibili.
• Un’interfaccia self-service per creare nuovi elementi software (infrastruttura, applicazioni o altro).
• Un’interfaccia a riga di comando per visualizzare log in tempo reale in produzione.
• Un sistema di monitoraggio per visualizzare metriche di microservizi.
• Un insieme di scorecard per raccogliere informazioni sulle metriche dei team.

La biblioteca, che può essere definita come Internal Platform (o Internal Developer Platform, come verrà approfondito nel prossimo paragrafo), è il luogo virtuale in cui avviene tutta la magia tecnologica. I Platform Engineers gestiscono questa piattaforma, garantendo un’esperienza eccezionale agli utenti interni. La loro visione è orientata al prodotto, con un focus su un’esperienza utente fluida e intuitiva.

A seconda dei modelli di utilizzo degli utenti della piattaforma e delle specifiche esigenze organizzative, i Platform Engineers perfezionano la piattaforma per fornire i servizi necessari.

Una piattaforma può essere considerata un luogo virtuale in cui le risorse, che in questa analisi vengono anche definite Items, sono organizzate e distribuite in modo sistematico. Ottimizzando il tempo e le risorse, diventa possibile rendere accessibili un maggior numero di elementi.

Sfruttando efficacemente questi elementi (nella metafora, i libri), le organizzazioni possono creare soluzioni innovative, ottimizzare le operazioni e ottenere un vantaggio competitivo.

All’interno delle capacità offerte dalla Internal Platform, i fornitori di funzionalità (Capability Providers) mettono a disposizione una gamma di risorse fondamentali (Items), come infrastrutture, toolchain DevOps, servizi SaaS e strumenti. Questi elementi sono organizzati e costantemente gestiti dai Platform Engineers.

Ogni capacità rappresenta un Item della piattaforma e si caratterizza per:

• Definizione: descrive input, output, comportamenti configurabili, metriche e documentazione.
• Ciclo di vita: un Item attraversa un ciclo che include sviluppo, testing, deployment, operatività e dismissione.
• Consumo e composizione: gli Items possono essere consumati e composti per creare applicazioni più complesse, trasformandosi a loro volta in altri Items pronti per essere riutilizzati.

I Product Teams possono interagire con questi Items attraverso interfacce utente, linee di comando e API. Agenti basati sull’intelligenza artificiale possono supportare i team semplificando l’utilizzo degli Items, che sono organizzati in cataloghi corredati della relativa documentazione.

Grazie a questa collaborazione, vengono create nuove applicazioni. Queste applicazioni possono successivamente essere trasformate in Raw Assets, risorse grezze riutilizzabili da altri team. Questo processo migliora l’esperienza degli sviluppatori all’interno dell’organizzazione (DevX).

Questo ciclo può essere visto come una sorta di economia circolare nello sviluppo software, dove le risorse vengono continuamente riutilizzate e riconvertite. Ciò conduce a un processo di sviluppo più efficiente e sostenibile, massimizzando il valore delle risorse disponibili e riducendo gli sprechi.

Ciclo di Vita degli Items della Piattaforma

Gli Items della piattaforma si presentano in diverse forme, ma condividono alcune caratteristiche comuni:

• Sono descritti da un file di testo semplice (esistono diversi formati emergenti e, in futuro, si auspica l’adozione di uno standard).
• Possono essere messi in relazione tra loro.
• Seguono un ciclo di vita che comprende creazione, distribuzione, esecuzione, gestione operativa e catalogazione, per essere consumati dai team di prodotto e applicazioni.

Gli utenti possono interagire con il sistema tramite un’interfaccia utente (UI), una riga di comando (CLI), un software che automatizza alcune operazioni o un agente AI basato su modelli linguistici di grandi dimensioni (LLM).

Immaginando di avere accesso a una piattaforma interna completa, contenente tutte le descrizioni dei comportamenti e delle relazioni necessarie per eseguire un’applicazione, quanto sarebbe vantaggioso disporre di un compagno AI?

Un assistente AI potrebbe semplificare notevolmente le attività, come trovare gli Items, configurarli, distribuirli e gestirli in produzione, il tutto tramite conversazioni intuitive. Un tale strumento potrebbe ottimizzare il flusso di lavoro e aumentare significativamente la produttività complessiva.

Questa idea può essere definita Conversational DevX e sarà l’argomento principale del prossimo articolo.

Internal Developer Platform, Platform of Platforms o Internal Platform?

Non è chiaro se sia più corretto definire una Internal Developer Platform come un insieme di piattaforme diverse o come una singola piattaforma. Questo argomento rimane aperto e si invitano al confronto e alla condivisione di idee.

I nomi sono importanti, ma in questo articolo si vuole mettere l’accento sul contenuto. Si auspica che, con il contributo del gruppo tag-app-delivery (link), si possa arrivare a una nomenclatura standard.

Come menzionato nell’introduzione, la Platform Engineering va oltre l’infrastruttura e non rappresenta un’evoluzione del DevOps, bensì un metodo per ridurre il carico cognitivo delle persone che creano, distribuiscono e gestiscono elementi software come applicazioni, dati, API e modelli di machine learning.

La tendenza osservata suggerisce che ogni tipo di elemento software abbia la propria piattaforma. Tuttavia, le esperienze utente tra queste piattaforme stanno diventando sempre più simili, il che lascia intravedere una possibile convergenza verso una singola piattaforma o una “platform of platforms”.

Un Item nella Internal Platform può appartenere a diverse categorie:

• Risorse di Infrastruttura: includono i componenti hardware e software sottostanti che supportano applicazioni e servizi, come server fisici, macchine virtuali, container, piattaforme cloud, archivi dati, database e runtime per machine learning.
• Risorse della Piattaforma DevOps o per Sviluppatori: strumenti per definire ed eseguire toolchain, oltre a strumenti per gestire e osservare workload, dati, API, eventi e modelli AI durante il runtime.
• Risorse di Dati, Eventi e API: i dati rappresentano un asset fondamentale per molte organizzazioni. Possono essere strutturati, non strutturati o semi-strutturati, provenire da diverse fonti, essere statici o in movimento, aggiornarsi tramite policy ed emettere eventi.
• Risorse di ML e AI: modelli di machine learning che possono essere definiti, addestrati, distribuiti e migliorati per fare previsioni e analisi.
• Risorse Componibili: elementi orchestrati o coreografati. A seconda del tipo di risorsa, si possono usare pattern differenti, come Sagas o la composizione di Micro Frontend. Gli Items Componibili sono strumenti che consentono di creare nuove combinazioni di risorse.
• Risorse DevX: considerate come un prodotto (marketplace interno e catalogo software). Ogni elemento della piattaforma può essere un asset prezioso per altri. Fornire un marketplace per questi elementi e gestirne il ciclo di vita (creazione, pubblicazione, curatela, consumo, revisione) è fondamentale per creare un’economia circolare del software.
• Risorse per la Collaborazione tra Team: i team lavorano insieme all’interno delle piattaforme utilizzando vari Items per facilitare la comunicazione e organizzare i flussi di lavoro. Questi includono strumenti come backlog, issue tracker e documentazione. La comprensione della piattaforma stessa è essenziale per una collaborazione efficace.

Questo approccio olistico consente non solo di ottimizzare lo sviluppo, ma anche di garantire che ogni elemento della piattaforma contribuisca al miglioramento complessivo dell’organizzazione.

Ampliamo il diagramma con diverse Piattaforme all’interno della Piattaforma Interna.

La Piattaforma Interna acquisisce “asset grezzi” come macchine virtuali (VM), cluster Kubernetes come servizio, e strumenti Platform as a Service per il runtime.
Gli strumenti DevOps sono essenziali per la gestione delle risorse e del ciclo di vita del codice, rappresentando un pilastro fondamentale insieme ai servizi di osservabilità, sicurezza e gestione delle identità. I data store come database NoSQL e SQL, flussi di dati e storage di oggetti sono ampiamente utilizzati nello sviluppo delle applicazioni.

Inoltre, i modelli LLM (Large Language Models) sono frequentemente utilizzati come servizio tramite API o integrati nel runtime per migliorare le applicazioni sviluppate dai team. Le applicazioni SaaS, come Salesforce, Dynamics 365 e SAP, fungono da hub centrali per varie informazioni su clienti e prodotti, giocando un ruolo cruciale nello sviluppo di applicazioni cloud-native.

Tutte le capacità sono gestite con un approccio Infrastructure as Code (IaC) e i manifesti IaC sono gestiti con il ciclo di vita: code, ship, run, operate e organizzazione della collaborazione tra team.

Lo stesso ciclo di vita delle risorse è condiviso tra diversi tipi di piattaforme: sviluppatori, infrastruttura, orchestrazione delle applicazioni (API, Eventi, Flussi), machine learning e dati. Tutte queste sono Piattaforme all’interno della Piattaforma Interna, che sono interconnesse e possono condividere risorse come un cluster di database o una politica di sicurezza.

I descrittori di questi articoli sono manifesti che possono essere raccolti nel concetto di Application as Code (AaC): con lo stesso approccio che descrive lo stato desiderato dell’infrastruttura, si descrive lo stato desiderato degli articoli di tutte le piattaforme che compongono l’applicazione cloud-native.

All’interno del Marketplace Interno sono definiti: il blueprint riutilizzabile per tutti gli articoli della piattaforma, il catalogo software che può essere riutilizzato e tutti gli altri articoli provenienti da ciascun team che possono essere utilizzati da altri team come blocchi di costruzione. Grazie a questo Marketplace, è possibile abilitare una strategia di Platform Composability.

La Piattaforma Interna offre diverse interfacce, tra cui un’interfaccia utente (UI) e un’interfaccia a riga di comando (CLI). Inoltre, gli utenti possono interagire con la piattaforma tramite API. L’AI funge da compagno. I manifesti IaC e AaC sono forniti come contesto al modello LLM e l’AI semplifica i compiti per gli utenti della piattaforma. Questi compiti includono la scoperta delle risorse, la risoluzione dei problemi con i microservizi e le risorse, e la creazione di nuove risorse.

Platform Engineering++ è una disciplina di ingegneria del software che si concentra sulle Piattaforme Interne con un approccio olistico.

Conclusioni

Adottando il paradigma del Platform Engineering++, si ritiene che il ritorno sugli investimenti (ROI) dell’iniziativa Platform Engineering crescerà significativamente. Questo avverrà perché la piattaforma diventa la base per le applicazioni aziendali, eliminando gli ostacoli tra i vari team. Di conseguenza, tutti i team avranno una visione unificata delle applicazioni end-to-end costruite su di essa.

Riferimenti

In questo blog, quando si parla di “Piattaforma”, si intende specificamente “Internal Developer Platform” o “Internal Platform”, in quanto queste piattaforme non sono esclusive per gli sviluppatori, ma comprendono anche ingegneri dei dati, machine learning, cloud e altre discipline. È importante distinguere queste Internal Platforms dalle Business Platforms, come Uber, Airbnb o Netflix. Le Internal Platforms supportano le organizzazioni nella costruzione e nell’operatività delle loro Business Platforms. Ad esempio, Spotify ha creato Backstage come un Internal Developer Portal e ha integrato strumenti aggiuntivi per sviluppare la sua Internal Platform per gestire la piattaforma dei consumatori di Spotify.

Si segnala che esistono già documenti che definiscono alcuni aspetti trattati in questo post:

• il CNCF Platform White Paper (link)
• il Platform Glossary (link)
• il Platform Engineering Maturity Model (link)
• l’iniziativa Platform of Platform (link).

Articolo scritto da Giulio Roggero.

L'articolo Platform Engineering nel 2024: tendenze di settore e nuove prospettive proviene da commit software.

Negli ultimi anni, i progressi nell’intelligenza artificiale (IA) e nel machine learning hanno aperto la strada a nuove tecniche di gestione delle informazioni e alla loro integrazione con modelli di linguaggio avanzati. Tra queste tecnologie emergenti, la Hybrid RAG (Retrieval-Augmented Generation) sta guadagnando sempre più attenzione per la sua capacità di combinare in modo efficiente il recupero delle informazioni e la generazione del linguaggio naturale.

Cos’è la Hybrid RAG?

La RAG (Retrieval-Augmented Generation) è una tecnologia che unisce il meglio dei due mondi: i modelli di generazione del linguaggio naturale (come GPT) e i sistemi di recupero delle informazioni basati su grandi basi di dati o documenti strutturati. L’obiettivo è utilizzare documenti esistenti per migliorare le risposte fornite da un modello linguistico generativo, rendendole più precise e fondate su fatti.

Il termine “ibrido” si riferisce all’integrazione di due meccanismi distinti:

1. Recupero delle informazioni (retrieval): Viene utilizzato un motore di ricerca interno o esterno che può estrarre documenti rilevanti da una vasta base di conoscenza, come testi, database o pagine web.
2. Generazione del linguaggio naturale (generation): Il modello linguistico utilizza questi documenti recuperati per generare risposte coerenti, chiare e pertinenti.

L’idea centrale della Hybrid RAG è dunque la capacità di combinare la precisione dei dati recuperati da fonti esterne con la flessibilità e la creatività dei modelli di generazione, creando risposte ricche, contestualizzate e basate sui fatti.

Come funziona la Hybrid RAG?

Il processo di funzionamento di una Hybrid RAG si articola principalmente in tre fasi:

1. Domanda e Preprocessing: Quando un utente pone una domanda o una richiesta, il sistema pre-processa il testo per determinare il contesto e la necessità informativa.
2. Fase di Recupero: Il sistema interroga una fonte di dati, che può essere un database locale o una risorsa esterna come un motore di ricerca, per trovare documenti pertinenti. Questi documenti non vengono usati direttamente per rispondere alla domanda, ma forniscono un contesto e dei fatti che alimentano la fase successiva.
3. Fase di Generazione: Il modello generativo riceve i documenti recuperati e li utilizza per produrre una risposta. Questo approccio permette di generare contenuti più dettagliati e accurati rispetto a un sistema puramente generativo, che potrebbe altrimenti basarsi solo su informazioni pre-addestrate, rischiando di essere meno aggiornato o meno specifico.

Vantaggi della Hybrid RAG

L’integrazione di questi due approcci porta a numerosi vantaggi:

• Accuratezza e affidabilità: Utilizzando informazioni recuperate in tempo reale da fonti attendibili, il sistema può produrre risposte più precise e meno inclini a errori o “allucinazioni” (un problema comune nei modelli generativi che possono produrre risposte fantasiose o errate).
• Aggiornamento continuo: Mentre i modelli di linguaggio generativi possono essere limitati alle informazioni con cui sono stati addestrati, la componente di recupero consente di accedere a dati sempre aggiornati, migliorando la capacità di rispondere con contenuti attuali.
• Adattabilità ai contesti complessi: La RAG ibrida è particolarmente utile in ambiti come il servizio clienti, la ricerca scientifica o il diritto, dove le risposte devono essere fondate su normative, articoli o documenti specifici. In questi casi, l’accesso a documenti aggiornati e precisi è cruciale.
• Riduzione dell’ambiguità: Il sistema può spiegare meglio le risposte fornendo riferimenti a documenti originali, aumentando la fiducia degli utenti nella qualità della risposta.

Applicazioni pratiche

La Hybrid RAG trova applicazione in diversi ambiti:

1. Assistenza clienti avanzata: Le aziende possono utilizzare la RAG ibrida per rispondere in modo efficace alle domande dei clienti, basandosi su database aziendali interni, manuali tecnici o documenti di supporto, fornendo risposte personalizzate e accurate.
2. Settore legale e medico: In ambiti dove è fondamentale l’accesso a informazioni precise e sempre aggiornate, come leggi, regolamenti o studi clinici, la RAG ibrida consente di fornire risposte basate su fatti verificabili, riducendo il rischio di errore.
3. Ricerca e sviluppo: I ricercatori possono sfruttare questa tecnologia per ottenere risposte contestualizzate da articoli scientifici, brevettuali o report aziendali, accelerando il processo di innovazione.
4. Automazione delle decisioni aziendali: In contesti aziendali, le decisioni possono essere supportate da documenti finanziari, report di mercato o linee guida specifiche. La RAG ibrida può essere utilizzata per automatizzare la consulenza e l’assistenza ai dirigenti in questi processi.

Sfide e limiti

Nonostante i vantaggi, ci sono alcune sfide nella costruzione e implementazione di sistemi RAG ibridi:

• Scelta delle fonti di recupero: La qualità delle risposte dipende dalla qualità delle fonti di recupero. Se il sistema recupera documenti non pertinenti o poco affidabili, la generazione del linguaggio potrebbe risentirne.
• Integrazione complessa: La combinazione di due tecnologie avanzate (recupero e generazione) richiede una forte integrazione e ottimizzazione per garantire che il sistema funzioni senza rallentamenti o errori.
• Gestione delle ambiguità: In alcuni casi, i documenti recuperati potrebbero fornire informazioni contrastanti, il che può rendere difficile la generazione di una risposta chiara e coerente.

Conclusioni

La Hybrid RAG rappresenta una delle innovazioni più promettenti nell’ambito dell’intelligenza artificiale per la gestione e il recupero delle informazioni. Combinando la potenza dei modelli di generazione del linguaggio naturale con il recupero in tempo reale di documenti specifici, offre un approccio robusto e flessibile per fornire risposte precise, contestualizzate e basate sui fatti. Sebbene ci siano sfide da affrontare, il suo potenziale per trasformare vari settori è innegabile, rendendola una tecnologia fondamentale per il futuro della gestione delle informazioni.

L'articolo Hybrid RAG: Una rivoluzione nella gestione e recupero delle informazioni proviene da commit software.

AWS Forecast offre alle aziende una soluzione di previsione della domanda basata su machine learning, capace di migliorare significativamente l’accuratezza delle previsioni rispetto ai metodi tradizionali. Grazie all’uso di diversi algoritmi, tra cui quelli statistici e modelli avanzati di deep learning, AWS Forecast può adattarsi a una vasta gamma di scenari di previsione. Il servizio automatizza buona parte del processo di machine learning, riducendo il bisogno di esperienza tecnica, e consente di creare previsioni personalizzate, tenendo conto di variabili multiple come dati storici, fattori esterni (ad esempio condizioni meteo o eventi economici), e stagionalità.

Una delle funzionalità più innovative di AWS Forecast è la capacità di eseguire analisi “what-if”. Questa funzione permette alle aziende di simulare diversi scenari ipotetici e valutarne l’impatto sulle previsioni future. Per esempio, è possibile testare come cambiamenti nei prezzi, nelle strategie di marketing o nell’offerta dei prodotti possano influenzare la domanda futura. L’analisi “what-if” diventa così uno strumento prezioso per la pianificazione strategica, consentendo alle organizzazioni di prendere decisioni più informate e reattive rispetto alle condizioni di mercato in continua evoluzione.

Isolamento con l’algoritmo DeepAR in SageMaker

AWS SageMaker offre maggiore flessibilità e controllo rispetto a AWS Forecast, rendendolo la scelta ideale per le aziende che hanno esigenze più complesse e specifiche. Mentre AWS Forecast è un servizio completamente gestito che automatizza gran parte del processo di creazione di modelli predittivi, SageMaker consente agli sviluppatori e data scientist di costruire, addestrare e distribuire modelli di machine learning personalizzati da zero. Questo approccio permette una maggiore personalizzazione del modello, inclusa la scelta di algoritmi specifici, l’ottimizzazione iperparametrica avanzata e, volendo, l’integrazione di modelli proprietari.

Uno degli algoritmi più rilevanti, e già incluso nei builtin di SageMaker,  per la previsione della domanda è DeepAR, un modello basato su reti neurali ricorrenti. Questo algoritmo consente di fare previsioni accurate su serie temporali multiple, sfruttando la capacità delle RNN di catturare dipendenze sequenziali a lungo termine, risulta particolarmente efficace in scenari dove le serie temporali sono caratterizzate da una forte stagionalità o da trend complessi.

DeepAR è un’opzione potente per coloro che desiderano utilizzare un modello di deep learning all’interno di AWS SageMaker per ottimizzare ulteriormente le loro previsioni.

Con SageMaker, si possono scegliere esattamente quali dati e quali tecniche utilizzare, senza essere limitate a una gamma predefinita di algoritmi. Inoltre, permette di integrare algoritmi open-source o creare soluzioni che sfruttano framework di deep learning come TensorFlow o PyTorch, aumentando la capacità di sviluppare modelli altamente sofisticati come reti neurali convoluzionali (CNN) o transformer.

Per tutti quelli che richiedono prestazioni predittive avanzate e vogliono sperimentare con algoritmi personalizzati, SageMaker rappresenta una soluzione molto più potente rispetto al servizio gestito di Forecast, che è ottimizzato principalmente per un utilizzo semplice e rapido ma meno personalizzabile.

Articolo scritto da Walter Dal Mut.

Vi aspettiamo al giovedì 26 settembre per parlarne dal vivo insieme a Walter Dal Mut – Solutions Architect presso Corley AWS Advanced Partner. Clicca qui per registrarti!

Non perderti, ogni mese, gli approfondimenti sulle ultime novità in campo digital! Se vuoi sapere di più, visita la sezione “Blog“ sulla nostra pagina!

L'articolo AWS Forecast e AWS SageMaker con DeepAR proviene da commit software.

Quando si parla di NOC (Network Operations Center), i livelli di supporto e la reperibilità sono elementi fondamentali per garantire un servizio efficace e di alta qualità. Essi non solo determinano la velocità e l’efficienza con cui i problemi vengono individuati e risolti, ma influiscono direttamente sull’operatività aziendale e sulla qualità del servizio offerto. 

L’importanza di un supporto multi-livello

Con l’aumento della complessità e del volume dell’azienda, diventa evidente che un solo livello di assistenza non è sufficiente per rispondere a tutte le esigenze dei clienti. Di conseguenza, molte aziende optano per una struttura di supporto su più livelli (multi-tier), che garantisce una gestione efficace delle diverse problematiche.

Nel contesto del NOC, i livelli di supporto variano in base alle esigenze operative e al tipo di servizi monitorati. I principali livelli di supporto includono:

1. Supporto di primo livello: gestione delle richieste base

Il primo livello di supporto rappresenta la prima linea di assistenza e si occupa delle richieste più semplici, fornendo risposte rapide a domande comuni o amministrative. Questo livello è cruciale perché spesso è il primo punto di contatto per i clienti. Un buon supporto di primo livello deve essere sempre disponibile, con una reperibilità garantita e in grado di risolvere la maggior parte delle problematiche di routine in tempi rapidi, evitando di aggravare situazioni che potrebbero facilmente degenerare se non affrontate tempestivamente.

Un elemento chiave per aumentare la disponibilità del servizio è il multilinguismo, che lo rende accessibile a una platea più ampia di utenti. La capacità di fornire assistenza in più lingue consente al team di rispondere rapidamente a domande comuni o a richieste in modo culturalmente e linguisticamente adeguato. Questo approccio non solo migliora l’esperienza utente, ma favorisce anche la fidelizzazione dei clienti, offrendo un supporto più inclusivo e personalizzato.

2. Supporto di secondo livello: risoluzione di problemi complessi

Quando un problema non può essere risolto dal primo livello, entra in gioco il supporto di secondo livello, costituito da tecnici più esperti. L’importanza di avere esperti prontamente disponibili non può essere sottovalutata, soprattutto in settori critici dove ogni minuto di inattività o di inefficienza può comportare perdite finanziarie significative. Il valore aggiunto di questo livello risiede nella capacità di risolvere problemi tecnici o operativi più complessi che richiedono un livello di competenza superiore. La rapidità d’intervento è cruciale e la reperibilità di questo livello di supporto può fare la differenza tra una risoluzione rapida e una costosa interruzione dei servizi.

3. Supporto di terzo livello: interventi specialistici e consulenza strategica

Il supporto di terzo livello si occupa delle questioni più complesse che richiedono una conoscenza specialistica approfondita e talvolta anche consulenze strategiche. Questo tipo di supporto è essenziale per garantire una risposta puntuale in caso di problemi che possono influire significativamente sulle operazioni aziendali a lungo termine. Gli esperti coinvolti in questo livello hanno spesso una visione strategica e possono consigliare soluzioni che non solo risolvono il problema, ma ottimizzano anche i processi aziendali, prevenendo future criticità.

La reperibilità nel NOC

Oltre alla struttura dei livelli di supporto, la reperibilità è un elemento chiave nel NOC. In un mondo sempre più globalizzato e attivo 24/7, la capacità di un team di supporto di essere disponibile in qualsiasi momento è essenziale per garantire la continuità operativa. La mancanza di reperibilità può tradursi in costosi tempi di inattività, con un impatto negativo sull’esperienza del cliente e sulle performance aziendali.

Monitoraggio 24/7

Un NOC operativo 24/7 consente di prevenire problemi, rispondere rapidamente a criticità e mantenere elevati standard di servizio. Questo aspetto è particolarmente importante in settori come l’e-commerce e il customer service, dove l’operatività continua è fondamentale per la soddisfazione del cliente.

Conclusioni

L’adozione di una struttura multi-livello, la reperibilità e la disponibilità di un monitoraggio continuo all’interno del NOC consentono di gestire problematiche di diversa complessità, garantendo che i problemi vengano affrontati in tempo reale, riducendo i rischi di interruzione dei servizi. Un NOC ben organizzato e sempre reperibile è la chiave per mantenere un alto livello di efficienza ed affidabilità in un contesto aziendale sempre più complesso e dinamico.

Per scoprire come un NOC dedicato, multilingua e operativo 24/7 può fare la differenza, visita il nostro blog e approfondisci i vantaggi che offre ICTW.

L'articolo L’importanza dei livelli di supporto e della reperibilità nel NOC proviene da commit software.