Buongiorno, «Now you went from writing bad code to building bad infrastructure.» [3]
Damiano grazie infinite per la segnalazione dell'articolo «The Big Cloud Exit FAQ» (coitato sotto): è bellissomo e assolutamente da leggere, attentamente, /tutto/. Damiano Verzulli <dami...@verzulli.it> writes: [...] > l'on-prem costa MENO dipende da come si fanno i conti e RARAMENTE li ho visti fare bene, perché anche per fare i conti (fatti bene) ci vogliono le giuste competenze ...e quanto lo mettiamo al kilo il costo di essere GDPR compliant?!? :-O > (a latere, sul punto, segnalo anche un interessantissimo articolo > recentemente pubblicato da... qualcuno che ha scelto di comprare 600K$ > di server, per alleggerire la bolletta cloud che pesava 140/150K$ / > mese [3]) la bolletta pare pesasse di più: nell'articolo «Our cloud spend in 2022» [1] c'è scritto che spendevano 266797$ al mese in servizi cloud. Parto dalla fine: è fondamentale comprendere che la differenza tra "on-premises" e "on cloud" NON è dove diavolo stanno fisicamente i server che costituiscono l'infrastruttura, ma chi installa e gestisce l'infrastruttura a partire dal SISTEMA OPERATIVO che serve a erogare i servizi informatici necessari, su su fino alle applicazioni, passando per i sistemi di "infrastructure as code". La stragrande maggioranza delle infrastrutture "on-premises" è ospitata in /colocation/ (e una forma di "on-premises" "sporca" è anche l'affitto del bare-metal). QUINDI, executive summary: il solo e unico problema in campo informatico della PA *e* del sistema imprenditoriale italiano è quello di avere adeguati "white glove" data centre professionali dove poter affittare rack/stanze/capannoni presso i quali far arrivare i propri server o in alternativa affittare direttamente il bare-metal... tutto il resto è noia :-D. C'è così tanto lavoro da fare di fronte a noi! Per fini archivistici, l'articolo che cita Damiano è questo: https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010 «The Big Cloud Exit FAQ» by David Heinemeier Hansson December 19, 2023 --8<---------------cut here---------------start------------->8--- Just over a year ago, we announced our intention to leave the cloud. We then shared our complete $3.2 million cloud budget for 2022, and the fact that we were going to build our own tooling rather than pay for overpriced enterprise service contracts. The mission was set! --8<---------------cut here---------------end--------------->8--- è un denso articolo, ricco di link che vale la pena seguire - tipo l'articolo che espone alcuni costi per il 2022 [1] - che segue l'articolo: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0 «Why we're leaving the cloud» October 19, 2022 --8<---------------cut here---------------start------------->8--- Basecamp has had one foot in the cloud for well over a decade, and HEY has been running there exclusively since it was launched two years ago. We've run extensively in both Amazon's cloud and Google's cloud. We've run on bare virtual machines, we've run on Kubernetes. We've seen all the cloud has to offer, and tried most of it. It's finally time to conclude: Renting computers is (mostly) a bad deal for medium-sized companies like ours with stable growth. The savings promised in reduced complexity never materialized. So we're making our plans to leave. [...] Let's take HEY as an example. We're paying over half a million dollars per year for database (RDS) and search (ES) services from Amazon. Yes, when you're processing email for many tens of thousands of customers, there's a lot of data to analyze and store, but this still strikes me as rather absurd. Do you know how many insanely beefy servers you could purchase on a budget of half a million dollars per year? Now the argument always goes: Sure, but you have to manage these machines! The cloud is so much simpler! The savings will all be there in labor costs! Except no. Anyone who thinks running a major service like HEY or Basecamp in the cloud is "simple" has clearly never tried. Some things are simpler, others more complex, but on the whole, I've yet to hear of organizations at our scale being able to materially shrink their operations team, just because they moved to the cloud. It was a wonderful marketing coup, though. Sold with analogies like "well you don't run your own powerplant either, do you?" or "are infrastructure services really your core competency?". Then lathered up with a thick coat of NEW-NEW-NEW paint, and The Cloud has beamed so brightly only the luddites would consider running their own servers in its shadow. [...] The cloud is sold as computing on demand, which sounds futuristic and cool, and very much not like something as mundane as "renting computers", even though that's mostly what it is. --8<---------------cut here---------------end--------------->8--- Sottolineo che anche David Heinemeier Hansson, il 19 Ottobre 2022, ha usato una parafrasi del vecchio slogan "the cloud is just someone else's computer" :-D Relativamente ai costi, vale la pena sottolineare che per tenerli sotto controllo applicano un sistema integrato di controllo di gestione *e* hanno contratti a prezzi scontati, come scrivono in [1]: --8<---------------cut here---------------start------------->8--- Getting this massive spend down to just $3.2 million has taken a ton of work. The ops team runs a vigilant cost-inspection program, with monthly reporting and tracking, and we’ve entered into long-term agreements on Reserved Instances and committed usage, as part of a Private Pricing Agreement. This is a highly-optimized budget. --8<---------------cut here---------------end--------------->8--- Cigliegina sulla torta (ma questo è OVVIO per chi ha competenza sistemistica) è che la performance dei servizi eseguiti "on-premises" supera quella degli stessi eseguiti "on cloud" (a parità di risorse e ottimizzazione): https://world.hey.com/dhh/cloud-exit-pays-off-in-performance-too-4c53b697 «Cloud exit pays off in performance too» by David Heinemeier Hansson May 2, 2023 --8<---------------cut here---------------start------------->8--- The median request now runs in just 19ms, compared to 67ms before. The mean request in 95ms vs 138ms. The median query time has dropped in half (which adds up when you do a lot of queries per request!). Basecamp Classic was no slouch in the cloud before, but now 95% of all requests are below that magic 300ms cut-off. (But take these comparisons with a pound of salt. It's not exactly a clean-room, scientific test. Just a peak at the reality of leaving a fine-tuned cloud setup for a fully-owned hardware alternative.) --8<---------------cut here---------------end--------------->8--- > Quindi, qual'e' il problema? > > Il problema è che per capire come configurare quei server, quanti > comprarne, dove dislocarli [...dovesse mai essere che arrivi un > ransomware....], quali software (open-source) metterci sopra, come far > si che tutto il setup venga effettuato con "automatismi" (in grado di > essere banalmente replicati su altre macchine, magari presso altri > enti), come monitorarne il regolare funzionamento... come garantirne una > "ragionevole" funzionalita'.... è una attivita' COMPLESSA. joke: è più difficile saper suonare bene un concerto per violino e oboe di Vivaldi :-D Complessa ma NON complicata, le complicazioni le inventano solo quelli che non hanno sufficiente competenza... o BARANO. [...] Saluti, 380° [1] https://dev.37signals.com/our-cloud-spend-in-2022/ P.S.: e qui soprassediamo sulle buzzwords tipo "serverless" [2] o "microservices" [3], perché entreremmo nel tecnico "spinto". [2] https://world.hey.com/dhh/don-t-be-fooled-by-serverless-776cd730 [3] https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 -- 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 nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
