Il 02/11/22 17:19, Giorgio Ventre ha scritto:

[...] Mi permetto solo due commenti:

1) il caso in esame è davvero molto particolare perché si tratta di storage per servizi A/V, quindi con un impatto forte sulla connettività richiesta.

Concordo sul fatto che l'ambito specifico (storage dei contenuti audio/video prodotti continuamente da PoliTO nell'ambito della propria didattica) sia "particolare". Tuttavia, per esperienza personale... _NON_ è raro osservare PP.AA. che si rivolgono ai cloud-provider per ospitare servizi storage-centrici quali, ad esempio, il proprio "file-server" (con profili d'uso forse ancora piu' esigenti rispetto al caso di PoliTO). A mio parere, il grande merito del lavoro di Enrico Venuto è quello di aver messo nero su bianco --seppur per un caso specifico-- un modello di calcolo dei costi che, a questo punto, altre PP.AA. potrebbero far proprio e migliorarlo/adattarlo al proprio caso specifico.

2) nel computo dei costi della soluzione In-House mancano i contributi OPEX, ossia il costo delle persone che fanno funzionare il NAS e che lo mantengono.

Come Enrico ha accennato durante la sessione di Q&A, i costi di gestione dei due modelli (on-prem vs. in-cloud) sono certamente diversi. Tuttavia _NON_ spariscono nel caso di "in-cloud". L'infrastruttura cloud va comunque "gestita" dall'ente cliente, con proprio personale. Specie in ambito "security", l'onere di garantire adeguati livelli di sicurezza dell'infrastruttura resta in capo all'ente (esattamente come nel caso "on-prem"). Tuttavia, se si è su cloud, servono competenze ancora piu' sofisticate o, in alternativa, aumentare ulteriormente i costi per implementare le soluzioni di security offerte dal fornitore (che, in questo caso, opera in regime di quasi-monopolio). A queste considerazioni pratiche, ne aggiungo una ulteriore, decisamente piu' "alta". Anticipo subito che NON è una domanda provocatoria... Ha senso parlare di "costi OPEX" riferiti al personale tecnico che avrebbe in carico l'infrastruttura ICT on-prem.... in un contesto (quello del nostro Paese), dove ogni giorno, a qualsiasi livello politico, non si perde occasione per dire che "servono competenze!", "servono tecnici", "serve riconquistare la sovranita' digitale", etc. etc. ? Detta piu' brutalmente: qualcuno pensa che per ottenere questi risultati "evolutivi", esistano delle ricette magiche che _NON_ comportano costi? Oppure, forse, sarebbe piu' opportuno considerare i costi del personale tecnico come un "investimento" (...e non un costo, quindi), con un ritorno a medio-lungo termine che è funzione solo della capacità politica di guidare il cambiamento nella strategia IT? È una domanda complicata... ma che su questa lista, mi sento decisamente di poter porre :-) Un caro saluto, DV -- 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

Il 04/11/22 09:20, Stefano Traverso ha scritto:

NFIDENTIAL

[...]

Da utilizzatore di sistemi cloud sono francamente sbalordito dai costi stimati da Enrico.

Riconosco anche io che il caso di Enrico sia molto particolare, ma nella mia esperienza, i costi di un’infrastruttura cloud sono assolutamente competitivi con quelli di un’infrastruttura on prem.

[...]

Comunque, considerando il preventivo di spesa sviluppato da Enrico, mi viene il sospetto che l’accordo quadro con Consip permetta ai fornitori di gonfiare i prezzi oltremisura. Un confronto con fornitori non inclusi nell’accordo ci permetterebbe di avere un quadro piu’ completo della situazione.

Il punto centrale, a mio avviso, è quest'ultimo. L'analisi di Enrico riguarda _ESCLUSIVAMENTE_ le soluzioni "in convenzione CONSIP", e per esperienza personale diretta, posso _GARANTIRE_ che i modelli di "pricing" (quantomeno rispetto ad alcune vecchie convenzioni in ambito TLC), sono a dir poco "opachi" e, soprattutto, forieri di _ENORMI_ problemi in fase di fatturazione (problemi che a occhi non-tecnici, spesso sfuggono). Concordo sull'opportunita' di estendere l'analisi agli altri cloud-provider (AWS, Azure & Co.): a lume di naso scommetto sul fatto che la soluzione on-prem sia _SEMPRE_ piu' economica della soluzione "on-cloud" (...e senza neanche contare l'aspetto di "evoluzione delle competenze" cui, personalmente, attribuisco un valore inestimabile). Riuscire a "certificare" tale comparazione (da una parte terza) sarebbe molto interessante. Il problema che vedo è l'estrema dinamicita' del mercato: il tasso di evoluzione dei server (con rapporto potenza/prezzo sempre in costante aumento) e la dinamicità delle offerte del mondo cloud (nuovi servizi; nuovi prezzi), impone analisi fatte in tempi estremamente rapidi (alcuni mesi) e... diventa obsoleta nel giro di 6 mesi. Temo che nessuno (indipendente) voglia incamminarsi verso una tale attivita'... Saluti, DV -- 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

Buongiorno, Stefano Traverso <s.traverso@ermes.company> writes: [...]

Riconosco anche io che il caso di Enrico sia molto particolare, ma nella mia esperienza, i costi di un’infrastruttura cloud sono assolutamente competitivi con quelli di un’infrastruttura on prem.

Nella mia esperienza no, specialmente per servizi di storage/file-server ...però OPEX fa la /netta/ differenza e come in molte altre attività esternalizzare abbassa i costi /finanziari/ anche se aumenta (sempre) il debito tecnico [1] e talvolta (spesso?) diminuisce la qualità del lavoro, ma quei due aspetti non compaiono a bilancio Prima di vedere i punti a favore del cloud vorrei proporne uno non tanto a favore: siamo sicuri che far girare il proprio core-business in cloud sia saggio? Cosa succederebbe se il fornitore dovesse togliere prodotti "a catalogo" e uno di quei prodotti è quello che fa funzionare il proprio core-business?

Ci sono altri punti da considerare in favore del cloud:

1. L’infrastruttura cloud puo’ essere potenziata dinamicamente per soddisfare la domanda, sia verticalmente (es: aumento potenza singola macchina)

Dimensione RAM? numero di processori? Immagino stia parlando di macchine virtuali, che comunque possono arrivare al massimo a impiegare tutte le risorse della macchina fisica Se quindi parliamo di macchine virtuali, anche on-prem è possibile la scalabilità verticale all'interno della macchina fisica... poi tocca cambiare macchina (o aggiungere processori o RAM se possibile)

che orizzontalmente (aumento numero di macchine e parallelizzo).

Anche on-prem, con sistemi di cluster management; in altri termini la scalabilità orizzontale non è una caratteristica del "cloud" ma una caratteristica di un cluster distribuito, no? BTW per "il parallelismo" anche l'applicazione deve essere scalabile orizzontalmente, per esempio il trasferimento di un file lo è ma solo via bittorrent.

Enrico ha svolto la sua valutazione considerando il sistema “a regime”, ovvero senza considerare un progressivo potenziamento dell’infrastruttura.

Nonostante certe pretese a volte (spesso?) un po' eccessive, non è necessario che l'infrastruttura sia costantemente in funzione per poterla utilizzare con soddisfazione (non tutte le industrie sono altoforni) e in molti casi analoghi a quello presentato da Enrico una migrazione ad altro "bare metal" o analoghe operazioni di upgrade hardware è più conveniente che passare on-cloud; per esempio un servizio di file-server per gli uffici può essere manutenuto/migrato quando gli uffici sono chiusi, senza interruzioni di servizio. Dove questo non fosse consentito per ragioni di continuità del servizio, come ho detto sopra anche on-prem si può adottare un cluster HA

2. I sistemi cloud offrono servizi specifici per storage di dati (es: AWS Simple Storage) che sono molto economici. Non so se questi siano stati considerati da Enrico.

Facciamo finta che OPEX sia zero: sarebbero ancora più economico di un NAS on prem?

3. Per quanto riguarda il discorso delle competenze, una delle grosse difficolta’ che si incontrano quando ci si interfaccia con i sistemi cloud e’ l’ampiezza e la varieta’ dell’offerta. Capire quali servizi nel catalogo siano quelli giusti per i propri requisiti richiede competenze specifiche che spesso sono messe a disposizione tramite consulenza dai provider cloud stessi.

Pare che il mercato dei consulenti di ottimizzazione dei costi per "stare sul cloud" sia fiorente... mi domando che fine abbia fatto il mercato per l'ottimizzazione dei costi per "stare on-prem" :-) Comunque, questi costi di consulenza come li contiamo? CAPEX o OPEX? Io so di aziende che non riescono nemmeno a capire bene se i servizi a catalogo siano adatti alle loro esigenze "boots on the ground" e men che meno quanto costerà loro alla fine dell'anno, ...e mica solo io: https://www.theregister.com/2020/09/03/cloud_control_costs/ «Why cloud costs get out of control...» --8<---------------cut here---------------start------------->8--- Spinning up services on public clouds is dead easy, but what about staying in control of the bill? Organisations are "over budget for cloud spend by an average of 23 per cent, and expect cloud spend to increase by 47 per cent next year," according to a "State of the cloud 2020" report by Flexera, based on a survey of 750 technical professionals. As if that weren't bad enough, respondents self-estimate that 30 per cent of cloud spend is wasted. --8<---------------cut here---------------end--------------->8--- Da quanto leggo "in giro" /pare/ che il nocciolo del problema è che molti clienti di servizi cloud vogliano "saving plans" o risorse "reserved" e _per_questo_ alla fine spendeno di più che acquistare risorse on-demand... ma come biasimare i DevOps, come va di moda chiamarli oggi, se vogliono essere tranquilli che le proprie applicazioni siano sempre performanti senza /letteralmente/ perdere la testa gestire sistemi che "scalano da soli"? ...con le librerie e gli ambienti di sviluppo "webbico" che ci sono oggi?!?!? --8<---------------cut here---------------start------------->8--- Another aspect of this problem is that the people responsible for optimising cost tend to be different from those who build the technology. "Imagine you're an engineer deploying a new application," said Apptio engineering veep Abuna Demoz. "You want your application to work. Estimating how much capacity you need, how much compute you need, how much storage you need is very hard to do in advance so an engineer will typically overprovision, with the best intentions of going back later and adjusting. What often happens is you move on to the next project, you never went back." Likewise, Bradley said there's a risk that "technical people make decisions on provisioning that get disconnected from what the business actually needs". --8<---------------cut here---------------end--------------->8--- La tensione tra tecnici e amministrativi è nota dai tempi dell'invenzione della ruota. --8<---------------cut here---------------start------------->8--- [...] It is also worth looking at application architecture from a cost perspective, Quinn said. "We had one customer that was taking in a giant pile of data from their customers, but 50 times that much data was being transferred between [AWS] availability zones. In a data centre that's effectively no-cost. In AWS or any cloud environment you are charged per GB for that, and that needs to be addressed." --8<---------------cut here---------------end--------------->8--- Per non parlare del problema della troppa scelta: --8<---------------cut here---------------start------------->8--- "Customers have a difficult time understanding which SKU among a similar bunch of offerings to choose from," said Chancellor. "Rather than using, say, a pre-built data analytics solution from AWS, maybe it makes sense to cheaply store data in S3 buckets and use one of the lower-cost options to query that data, and visualise that via a free open-source tool." --8<---------------cut here---------------end--------------->8--- Sì ma... le competenze per implementare la lower-cost option dove le mettiamo? OPEX, CAPEX? Ma ecco LA questione delle questioni, le "pricing dimensions": --8<---------------cut here---------------start------------->8--- products are priced piecemeal. "This is where it gets screwy and broken because there are so many different pricing dimensions. How many IOPS? How many reads and writes does your database do in a month? The correct answer is: 'I don't know.' No one does." There is a reason for the way the pricing works, said Quinn, based on "the underlying logic of what it costs AWS to provide the service", but it makes the cost "incredibly variable". [...] The solution is to run something and see what it costs. --8<---------------cut here---------------end--------------->8--- Significa che con quelle "pricing dimensions" i costi non si possono ragionevolmente preventivare?!? Non mi stupisce che i clienti vogliano una tariffa flat (vi ricordate le tariffe a consumo delle connessioni Internet?). --8<---------------cut here---------------start------------->8--- "I don't know anyone who looks at their cost approach and what they're doing and doesn't feel ashamed because they're doing it wrong. You can always do it better. The trick is to understand that it's a process." --8<---------------cut here---------------end--------------->8--- Aaaaaaahhh ecco, lo sospettavo. Ma allora lo possiamo applicare quel processo (miglioramento continuo) anche con le risorse on-prem, no?

Comunque, considerando il preventivo di spesa sviluppato da Enrico, mi viene il sospetto che l’accordo quadro con Consip permetta ai fornitori di gonfiare i prezzi oltremisura.

É un sospetto che viene quasi sempre quando si tratta dei costi di appalti e fornitore alla PA, no?

Un confronto con fornitori non inclusi nell’accordo ci permetterebbe di avere un quadro piu’ completo della situazione.

Sì sarebbe interessante, ma chi è in grado di farlo?!? Come si fa a fare un confronto con "pricing dimensions" completamente incompatibili tra loro? Ma soprattutto, chi lo fa il capitolato: il fornitore o il committente?!? :-O [...] Saluti, 380° [1] sia chiaro, nessuna azienda può avere un debito tecnico a zero, ma c'è debito e debito: un conto sono i servizi accessori, altro quelli infrastrutturali. -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.