Il 21/06/21 16:09, D. Davide Lamanna ha scritto:
[....] due soluzioni che in realtà non differiscono granché (o forse non le ho capite):
1) Usare AWS, GCP e Azure come IaaS, garantendosi sconti quantità. Il resto dello stack lo fai da te.
è IaaS, appunto. Prendi le macchine virtuali, le accendi, ci metti sopra il sistema operativo che ti pare... e ci metti sopra gli applicativi che ti scrivi. Ti smazzoli da solo i problemi di backup, di scalabilita' (della tua applicazione), di affidabilita', etc. etc. Insomma: anziche' comprarti del ferro ed attaccarlo alla tua 220v, prendi questo (ed e' cosa buona e giusta). Domani ti stufi? Problemi zero: passi da AWS a Aruba con uno schiocco delle dita (previo cambio di indirizzo IP). SeeWeb ti fa un'offerta che non puoi rifiutare? Problemi zero... accendi + migri + cambi IP ... ed il gioco e' fatto. Vuoi provare qualcosa di interessante su GARR-Cloud? ...problemi zero. Sintesi: liberta' massima, a fronte di un impegno di "gestione" tuttosommato semplice (dentro gli uffici di un Ateneo trovi almeno 1 persona per ogni 100 dipendenti strutturati in grado di fare queste operazioni) ....e se qualcuno pensa che questo "non è 'cloud'", si sbaglia! Se si e' "moderni", si puo' --ad esempio-- utilizzare degli strumenti di "automazione" (sto pensando a Terraform) con cui si dice (+ o -): "questa e' la API key di SeeWeb, questa è la API key di Aruba; accendi tre VM 'grandi' su Aruba e due VM "medie" su SeeWeb. Mettici sopra una CentOS 8 e poi esegui questo job. Questo job è scritto con ansible e l'obiettivo è aggiornare la VM, installare i pacchetti che servono e scaricare e avviare la mia applicazione meravigliosa" Per quest'ultimo tipo di attivita', le competenze negli Atenei le trovi ma... passiamo a una/due persone al massimo, in un Ateneo che ha almeno 50K studenti (in quelli piu' piccoli, non le trovi). Tutto questo (la prima parte) è quello che ricade nel primo scenario descritto dall'autore
2) Cito testualmente: "legarsi mani e piedi a una tecnologia di una azienda specifica, sposarne la filosofia di sviluppo, e ritrovarsi in un matrimonio dal quale non si può più uscire, con rischi di vario tipo."
A cosa si riferisce? A un Public Cloud? Quindi è la stessa di cui in 1)? Oppure? Roba fatta in casa in modo tradizionale (no Cloud)? Mistero.
No. Non e' "mistero". È lo scenario nel quale un team di sviluppo decide di scrivere una applicazione (...e fin qui tutto bene....). Solo che --a differenza di quello che era lo standard fino a pochi mesi fa [*], decide di utilizzare delle librerie prendendole _direttamente_on_line_. Occhio: intendo che la chiamata alla libreria (chiamate effettuate dalla mia applicazione) viene fatta ad un qualcosa che sta "su cloud". Intendo che la mia applicazione _NON_ funzionera' se quella chiamata a quelle librerie "fallisce" (perche', ad esempio, il cloud-provider ha chiuso il servizio o c'e' un qualche problema di rete fra la mia APP ed il cloud-provider [**] La buzzword è "serverless-computing", e servizi di questo genere sono presenti sia a catalogo AWS (lambda) che Microsoft (azure functions). Ci si potrebbe chiedere perche' mai un team di sviluppo dovrebbe decidere di adottare una soluzione simile... e la risposta non mi è chiara. Se fossi io il CIO che ha la responsabilità di un team del genere.... tendenzialmente cercherei un nuovo team-leader, in quanto l'attuale evidentemente ignora il termine "vendor-lock-in". Purtroppo, esistono anche contesti meno "netti". Ad esempio: scrivo una APP, ma siccome non sono capace di gestire un cluster elasticsearch che possa gestire qualche miliardo di documenti e renderli ricercabili in tempi dell'ordine del sub-secondo.... finisco per comprare un servizio cloud (ad esempio, quello di elastic) e... i dati li infilo la. Questo scenario è meno grave rispetto al precedente: se ho l'accortezza di utilizzare servizi cloud basati su tecnologie open (come con elastic), tornare indietro (perche' ho finalmente messo in piedi un team di tre persone che è capace di tirare su quel cluster e di stargli dietro....) non è particolarmente complesso. L'aspetto delicato, a mio avviso, è che queste (nuove) dinamiche di (forte) lock-in partono dagli sviluppatori: sono loro a _chiedere_ di utilizzare tecnologie "pericolose". E per dirgli: "No! State facendo una sciocchezza!" servono competenze che --tipicamente-- _MANCANO_ sulla linea gerarchica cui tipicamente rispondono. Quindi, per chiudere, il primo concetto introdotto dall'autore... ci piace (ed e' cloud). Il secondo NON ci piace (ed e' cloud pure lui).
Io mi sarei immaginato in 2) qualcosa del tipo: costruirsi i propri sistemi distribuiti usando ferro di proprietà e tecnologie Open (OpenStack e Kubernetes), secondo gli standard CNCF e Open Infrastructure. La dicotomia sarebbe stata evidente.
L'elemento che trascuri è proprio "l'applicazione": l'infrastruttura che hai descritto puo' essere allestita al 100% con ferro "di proprieta'" e con tecnologie 100% open-source. Ma se poi lo sviluppatore ci mette sopra una applicazione che usa tecnologie di "serverless-computing".... tu sei "fritto" lo stesso... ...sono convinto, pero', che ora lo scenario e' piu' chiaro (almeno a noi tecnici!). Un caro saluto, DV [*] ...ossia scrivo la APP, ma nel farlo, uso delle "librerie" che recupero dal mercato e che finiscono nel codice della mia APP, e lo faccio perche' non voglio riscrivere la ruota ogni volta [**] ogni riferimento al down recente di Fastly [1] è puramente voluto! [1] https://www.corriere.it/tecnologia/21_giugno_08/fastly-down-cdn-37a99d86-c84... -- Damiano Verzulli e-mail: damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html