On Sat, 12 Jun 2021 at 09:35, <nexa-request@server-nexa.polito.it> wrote:
Date: Sat, 12 Jun 2021 10:35:00 +0200
From: Damiano Verzulli <damiano@verzulli.it>
[...]
Di nuovo: _NON_ conosco startup (abruzzesi) che partono _OGGI_ e che
dicono: "/Voglio conquistare il mondo, e siccome il mio
prodotto/servizio andra' su tutto il mondo... anziche' partire con la
mia infrastruttura, parto con AWS/".
Di nuovo, credo che nei discorsi fatti qui sulla ML si sia parzialmente mancato il punto principale per me, che mi ha spinto a scrivere il primo messaggio.
Mi scuso, Marco, ma credo ci sia un mismatch di protocollo nelle nostre comunicazioni (cosa che capita non cosi' raramente, su questa lista).
Il faro che mi guida nelle frequentazioni della ML NEXA e che mi
porta a spendere alcune ore davanti alla tastiera è legato al
fatto che attualmente la politica Italiana (da Colao, in giu)
vuole adottare piattaforme cloud a trazione made-in-USA per
sportarci sopra un corposo workload attualmente running su una
pletora di sistemi distribuiti nelle varie PA (in particolare:
Atenei ed Enti Locali [Regioni, Province, Comuni, Società
Pubbliche], ASL). Questo processo è gia' in corso e, a mio modo di
vedere, sta gia' comportando danni "sociali" che rischiano di
essere drasticamente amplificati. L'imminente arrivo dei fondi del
PNRR rischia, da questo punto di vista, di essere un eccezionale
boomerang. Vorrei "lavorare" non dico per evitare questo scenario
ma, almeno, provare a contribuire a sgombrare il campo da
sgradevoli equivoci (molto diffusi, anche fra gli addetti ai
lavori).
E' di questo che parlo (io). Non di startup. Spero ora sia piu' chiaro.
Nessuna startup quando comincia pensa alla scalabilita', al 99.999% di uptime o a raggiungere tutto il mondo, ma pensa alla _facilita' di sviluppo e al time to market.
L'alternativa e' tra affittare un piccolo rack, comprare l'hw, assumere un sistemista, per avere poi un sistema subottimale su cui gli sviluppatori devono lavorare, o assumere un developer full stack che ha gia' usato AWS e puo' cominciare a sviluppare il prodotto utilizzando tecnologie che richiedono pochi click per essere utilizzate.
Il 100% delle startup (ma anche delle compagnie medio-grandi) scegliera' la seconda alternativa.
Le strategie delle startup (private) _NON_ mi interessano. Il mondo "privato" è liberissimo di fare tutte le scelte che vuole: pensera' il mercato a "premiarle" o a "sopprimerle". Certamente non impatteranno la mia vita allo stesso livello di quanto possa fare la scuola frequentata dai miei figli, il Comune dove vivo, la Regione dove vivo, la mia ASL, etc. etc.).
Ciò premesso, se indosso il cappello da "tecnico", ritengo comunque fuorvianti alcuni passaggi del testo citato.
Pensare che per sviluppare un servizio/prodotto software-centrico siano necessari, cito: "...un piccolo rack, comprare l'hw, assumere un sistemista, per avere poi un sistema subottimale su cui gli sviluppatori devono lavorare..." mi pare eccessivo.
Sul mio XPS 13" da 2K€ (un portatile), posso banalmente far girare 10 VM (o 50 container; o un mix delle due cose). Posso sviliuppare una applicazione di log-analysis che include tutto l'ambiente di sviluppo (parlo dell'IDE) all'interno del quale girano front-end (SPA) e back-end. Dove il back-end include due simulatori di stream di dati e dove è running anche un nodo elasticsearch. Tutto quello che sviluppo è versionato (GIT) e versionata è anche la documentazione.
Un solo portatile. 2K€. Nessun rack. Nessun sistemista. Niente. Solo un XPS 13, il mio cervello ed un numero _ENORME_ di tecnologie open-source. Niente altro.
Ad una startup serve di piu'? ...puo' essere, Ma se partisse focalizzandosi sul prodotto/servizio, e lo facesse con la consapevolezza di definirne l'architettura in modo da minimizzare le dinamiche di "lock-in", sarebbe gia' un ottimo risultato.
Sul "...avere poi un sistema subottimale su cui gli
sviluppatori devono lavorare..." ho tantissime riserve. Sul
mio portatile posso far girare kubernetes (che è il layer
utilizzato da google per gestire il suo workload); posso sviuppare
ed eseguire elasticsearch; posso scrivere codice con almeno i
primi 5 linguaggi piou' diffusi al mondo. Posso raccogliere e
analizzare decine di milioni di eventi (a ritmi da diversi k per
secondo). E posso condivere tutto con altri (colleghi, ad
esempio).
Perche' tutto questo sarebbe sub-ottimale?
Il grande vantaggio di AWS e' lo sviluppo nel tempo di un ecosistema che rende estremamente facile fare qualsiasi cosa. Se ho un'esigenza, sono quasi sicuro che esista un tool o una libreria nel mio linguaggio preferito che mi permette di usare l'infrastruttura di AWS come IaaS.
E' evidente che noi due [1][2] osserviamo il mondo da due punti di vista molto diversi. Non necessariamente l'uno è migliore dell'altro. Certo è che il terreno che forma la collina su cui poggio io _NON_ è fatto di AWS, di GCP, di Azure o cose del genere.
Ma non per questo ho dubbi sulla qualità delle fondamenta (della
collina): la quantità di tecnologie di cui dispongo _NON_ è
certamente "un freno" che impedisce a me (ed alle PA che mi
circondano) di "crescere". Tutt'altro. Se loro vogliono, con
queste tecnologie possono crescere... avendo la possibilità di
mantenere nelle proprie mani il proprio destino.
[...]
utilizzando tecnologie che richiedono pochi click per essere utilizzate
[...]
Si tratta di fornire soluzioni alternative che introducano meno sforzi, non di piu', altrimenti nessuno le scegliera' volontariamente, ma solo se obbligato.[...]
Consentimi un ultimo commento su questi due passaggi, che pongono l'accento sul tema della "accessibilità della tecnologica".
Nelle discussioni su questa ML, dovremmo definire se parliamo di:
In altri termini: io credo che tutto l'enorme sforzo profuso per
rendere semplice l'uso di tecnologie complesse.... debba essere
"calibrato" rispetto all'obiettivo che ci si pone. La
semplificazione è certamente auspicabile. Ma esiste un limite che
--IMHO-- non puo' essere superato: se qualcosa è difficile... è
giusto che vada affrontato per quello che è.
Pensare ad uno sviluppatore dell'App-IO che _NON_ ha la piou'
pallida idea delle problematiche di "privacy" che coinvolgono
l'uso di Firebase [3] (o di Analytics), mi _TERRORIZZA_!
Quello sviluppatore si trova dentro una Aygo (perche' è quello che sa guidare), senza rendersi conto che è a "Le Mans" e sta partecipando alla cosa. Ed è ancora piu' terribile se penso al fatto che la sua squadra non lo abbia "edotto" o, quantomeno, "corretto".
Vedo molta schizofrenia. Dall'uso di stessi termini ("cloud", in primis) per riferirsi a contesti totalmente diversi, all'uso di "numeri" recuperati con tecnologie specifiche (es.: supporto dei livelli TLS dei siti web delle PA) ma poi utilizzati per scopi totalmente diversi (es.: "il 95% delle PA è insicuro").
Mi piacerebbe vedere diffondersi un processo rigoroso e razionale (come, su questa ML, _SICURAMENTE_ è possibile fare, stante la qualità elevatissima di chi la frequenta....) che aiuti a far chiarezza su questi temi... anche e soprattutto nell'interesse primo del nostro Paese (l'Italia).
Saluti,
DV
[1] https://uk.linkedin.com/in/marcodelaurenti
[2] https://it.linkedin.com/in/damianoverzulli
[3] sul tema ci sono molti articoli. Questo e' un buon inizio:
https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9668748
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