On 29/05/21 16:39, Antonio Iacono wrote:
Tu dici che S3, Blob e le centinaia di servizi dei GAM non servono.
Io la penso come tale jiggawatts [1] ...
Caro Antonio, le affermazioni che riporti e su cui dici di concordare, sono una sequela di panzane. Il cloud NON è closed source, il cloud NON è il nuovo mainframe, il cloud NON è opaco nell'implementazione delle sue funzionalità. Tutte queste caratteristiche sono caratteristiche proprie dei Public Cloud dei GAM. Ma il cloud non inizia e finisce con il Public Cloud dei GAM! Esistono Public Cloud che NON sono dei GAM e sono sviluppati con OpenStack e Kubernetes. Ma il cloud non inizia e finisce neanche con il Public Cloud! Esistono dei Private Cloud che sono di chi li implementa e sono sviluppati con OpenStack e Kubernetes. Dire che il cloud è closed source e in mano ai GAM, equivale a dire che la Office Automation è closed source e in mano a Microsoft, ignorando Libre Office. Molti fraintendimenti di questo thread sono a mio avviso dovuti a questo. Se vuoi una descrizione compatta di cloud te la do io: un sistema operativo sta alla singola macchina, come il cloud sta ad N macchine. Il sistema operativo fornisce all'utente delle astrazioni in forma di servizi. Un sistema cloud fa la stessa cosa con N macchine. Ma i servizi che si possono realizzare e fornire con il cloud non sono pari ad N moltiplicato per i servizi di una singola macchina: sono piuttosto N elevato ad una potenza positiva grande a piacere (!) moltiplicato per i servizi di una singola macchina. Un cloud fatto bene è strumento di automazione per l'IT, è uso efficiente delle risorse IT, è gestione efficace delle risorse IT, è federazione di risorse IT, è trasparenza, è potenza, è partecipazione. D.
"The cloud is the new time-share mainframe. Programming in the 1960s to 80s was like this too. You'd develop some program in isolation, unable to properly run it. You "submit" it to the system, and it would be scheduled to run along with other workloads. You'd get a printout of the results back hours later, or even tomorrow. Rinse and repeat. This work loop is incredibly inefficient, and was replaced by development that happened entirely locally on a workstation. This dramatically tightened the edit-compile-debug loop, down to seconds or at most minutes. Productivity skyrocketed, and most enterprises shifted the majority of their workload away from mainframes. Now, in the 2020s, mainframes are back! They're just called "the cloud" now, but not much of their essential nature has changed other than the vendor name. The cloud, just like mainframes: - Does not provide all-local workstations. The only full-fidelity platform is the shared server. - Is closed source. Only Amazon provides AWS. Only Microsoft provides Azure. Only Google provides GCP. You can't peer into their source code, it is all proprietary and even secret. - Has a poor debugging experience. Shared platforms can't generally allow "invasive" debugging for security reasons. Their sheer size and complexity will mean that your visibility will always be limited. You'll never been able to get a stack trace that crosses into the internal calls of the platform services like S3 or Lambda. Contrast this with typical debugging where you can even trace into the OS kernel if you so choose. - Are generally based on the "print the logs out" feedback mechanism, with all the usual issues of mainframes such as hours-long delays."
Antonio
[1] https://news.ycombinator.com/item?id=26857859 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- Ing. D. Davide Lamanna - CTO mobile: 340 4830930 voip: 06 916504256 fax: 06 233225276 Via Flaminia, 48 - 00196 Roma www.binarioetico.it