Buongiorno, Stefano Traverso <[email protected]> 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>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list [email protected] https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
