{"id":1090,"date":"2019-12-17T16:21:55","date_gmt":"2019-12-17T15:21:55","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1090"},"modified":"2021-03-17T15:08:17","modified_gmt":"2021-03-17T14:08:17","slug":"pensieri-e-considerazioni-dall-aws-reinvent2019","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/pensieri-e-considerazioni-dall-aws-reinvent2019\/","title":{"rendered":"Pensieri e considerazioni dall’AWS re:Invent 2019"},"content":{"rendered":"

L’AWS re:Invent 2019 si \u00e8 concluso.
\n\u00c8 passata una settimana dalla fine dell’evento Cloud pi\u00f9 importante dell’anno<\/strong>, il tempo necessario per riprendermi dal jet lag, per sistemare parzialmente lo spaventoso backlog di e-mail che solo una conferenza di una settimana pu\u00f2 produrre e anche per divertirmi un po’ sulla spiaggia dell’Oceano Pacifico insieme al team prima di tornare a casa. Quindi ora \u00e8 il momento perfetto per riorganizzare i pensieri sull’evento e condividerli finalmente con voi.<\/p>\n

\"\"<\/p>\n

\u00c8 stato il mio ottavo re:Invent di fila<\/strong> (il primo nel 2012): sono abbastanza sicuro di essere l’unico in Italia – e, credo, una tra le pochissime persone al di fuori degli Stati Uniti – a detenere questo piccolo record.<\/p>\n

Fun fact: sono italiano, ho 37 anni, e nella mia vita sono stato solo due volte a Venezia e ben otto volte nella “falsa” Venezia nel bel mezzo di Las Vegas<\/a>; curioso, eh? E non solo per me!<\/a>
\n<\/em><\/p>\n

\u00a0<\/span><\/p>\n

\"\"<\/p>\n

Ho partecipato all’evento con lo stesso entusiasmo della prima volta, anche se dal 2012 molte cose sono cambiate relativamente sia ad AWS che al Cloud Computing in generale. Otto anni fa, i veri Cloud user erano organizzati in una piccola nicchia di pionieri alle prese con l’adozione precoce di un paradigma ancora relativamente nuovo. Oggi, al contrario, la corsa al Cloud ha ormai coinvolto tutti (o quasi). I siti dedicati all’argomento non si contano e migliaia sono i siti web, i blog e i post sui social che ci hanno gi\u00e0 fornito carrellate pi\u00f9 o meno dettagliate su tutti gli annunci della settimana a Las Vegas, alcuni aggiornamenti addirittura in real-time, mentre gli speaker erano ancora sul palco e parlarne!
\nUn paio di esempi? Ecco qui<\/a>… e qui<\/a>!<\/span><\/p>\n

Per questo motivo, quest’anno, ho deciso di non esaminare ogni singolo annuncio, descrivendo caratteristiche e dettagli tecnici. Al contrario, mi concentrer\u00f2 maggiormente su una visione pi\u00f9 a lungo termine di AWS<\/strong> e dell’utilizzo di vecchi e nuovi servizi alla luce delle notizie a mio parere pi\u00f9 dirompenti e rivoluzionarie da Las Vegas.
\nQuindi, cominciamo!<\/strong><\/span><\/p>\n

L’aspetto infrastrutturale \u00e8 una delle pi\u00f9 trascurate: la grande parte dell’hype su AWS \u00e8 sempre pi\u00f9 developer-driven e guidata da “quei tipi hipster che pensano che il mondo finisca ad un endpoint REST” J (cit.)
\nMa, come si pu\u00f2 facilmente intuire, l’innovazione in questo strato della torta \u00e8 la chiave per poter rilasciare qualsiasi altro tipo di servizio di livello superiore.<\/span><\/p>\n

Parlando di computing<\/strong>, due dei servizi pi\u00f9 interessanti sono Local Zones<\/a> (ultra-low-latency edge computing per le citt\u00e0 metropolitane) e AWS Wavelength<\/a> (ultra-low-latency edge computing all’interno delle reti 5G dei provider telco).
\nEntrambi i servizi, a mio avviso, sono basati su AWS Outpost<\/a>, annunciato l’anno scorso al re:Invent, ma rilasciato in GA lo scorso 3 dicembre. Ho avuto l’opportunit\u00e0 di discutere di Outpost in modo estremamente approfondito (potendolo anche toccare fisicamente con mano per la prima volta all’Expo del re:Invent di quest’anno) con Anthony Liguori<\/a>, uno dei supervisori del progetto. Outpost, mi ha detto, \u00e8 un’esatta riproduzione (su scala ridotta) dell’infrastruttura EC2 ed EBS di ultima generazione effettivamente in produzione all’interno delle AZ pubbliche. Questo mi \u00e8 sembrato piuttosto strano, dato che il rack Outpost \u00e8 pieno di server 1U (AWS custom) e dispositivi di rete (AWS custom), ma non c’\u00e8 traccia invece di dispositivi di storage.<\/span><\/p>\n

\"\"<\/p>\n

La risposta a questa mia obiezione \u00e8 stata sorprendente… e anche relativamente semplice : tutti i server 1U sono full-length, quindi proprio accanto alla scheda madre c’\u00e8 molto spazio per un sacco di SSD NVMe. Il chip Nitro<\/a> gestisce direttamente tutte queste unit\u00e0, quindi gli stessi dispositivi fisici possono agire sia come EBS che come Instance Storage (effimero), basato sulle diverse richieste degli utenti fatte alle API AWS. Nel caso dell’Instance Storage, il volume logico viene esposto “localmente” attraverso il bus PCIe, mentre l’EBS viene astratto attraverso diversi server e poi esposto attraverso Ethernet grazie all’enorme larghezza di banda di rete disponibile all’interno di Outpost. Immagino che una terza astrazione dello storage di Outpost basata sullo stesso hardware potrebbe essere S3 (senza la riconosciuta “11-nines durability” purtroppo!), che sar\u00e0 disponibile nel 2020. Non mi sono stati forniti ulteriori dettagli sulla ridondanza dello storage e sulla tolleranza ai guasti (RAID? Erasure coding?), mi hanno solo informato che la magia di tutto questo avviene grazie – di nuovo – al chip Nitro. Quando uno specifico server 1U raggiunge una soglia predefinita di unit\u00e0 difettose, l’intero server viene contrassegnato come “da sostituire” e le procedure di controllo di Instance Storage ed EBS possono reagire di conseguenza. Una soluzione non convenzionale, ma a mio parere ingegnosa. Solo una piccola differenza con le AZ pubbliche: anche se i datacenter di AWS “girano” ufficialmente su un hardware di rete personalizzato (alimentato da ASIC di Annapurna Labs), all’interno di Outpost ci sono dispositivi di rete Juniper standard, ma estremamente potenti. Questo massimizza la compatibilit\u00e0<\/strong> con i dispositivi di rete dei clienti.<\/p>\n

Sempre parlando di computing: sembra che AWS stia facendo molto leva sull’acquisto degli Annapurna Labs, dato che gli altri due principali annunci, AWS Inferentia<\/a> e AWS Graviton 2<\/a>, riguardano, ancora una volta, il silicio personalizzato. Mentre Inferentia (che alimenta la nuova famiglia di instance Inf1) \u00e8 semplicemente un chip ML personalizzato con un impressionante rapporto prestazioni\/costo rispetto alle alternative standard basate su GPU. La novit\u00e0 rivoluzionaria \u00e8 probabilmente Graviton 2. E non per l’impressionante miglioramento delle specifiche<\/a> rispetto al Graviton 1 dello scorso anno, la prima CPU personalizzata basata su ARM di AWS.<\/p>\n

Tutto ci\u00f2 \u00e8 rivoluzionario: sembra che la sesta generazione di istanze EC2<\/a> si baser\u00e0 (almeno per i primi tempi) SOLO sull’architettura ARM<\/strong>. Ad essere onesti, dubito fortemente che questa sia la fine definitiva dell’era x86 sul Public Cloud – esistono troppi carichi di lavoro ereditati che non saranno mai ricompilati per ARM – ma penso che sia comunque un grande segnale di cambiamento. L’architettura x86 ha 40 anni e nonostante le continue revisioni ed evoluzioni, porta con s\u00e8 molti problemi e inefficienze, soprattutto a causa della parte “legacy” del set di istruzioni, mantenuta per ragioni di compatibilit\u00e0. A queste considerazioni bisogna aggiungere che sono molte le voci (autorevoli) in circolazione<\/a> riguardo al fatto che Apple stia cercando di abbandonare l’architettura Intel (e x86) per i suoi laptop (un altro campo, questo, dove il rapporto prestazioni\/efficienza energetica \u00e8 estremamente critico, esattamente come per il Cloud pubblico), sfruttando i suoi pluripremiati chip custom ARM (gi\u00e0 in uso su iPhone e iPad). \u00c8 una tendenza super-interessante, corroborata dalle scelte di due big della Silicon Valley.<\/p>\n

L’annuncio pi\u00f9 “visionario” di tutto il re:Invent<\/a> – a chiusura del nostro capitolo sulla potenza di calcolo – \u00e8 senza dubbio quello di Amazon Braket<\/a> (nella speranza che non sia solo un annuncio “marketing-driven” per aggiudicarsi la Quantum Supremacy<\/a> contro Google e IBM). Il quantum computing \u00e8 tanto complesso da comprendere in teoria, quanto da implementare nel mondo reale. Per questo motivo, l’arrivo di infrastrutture quantistiche gestite<\/strong> (anche se estremamente semplici e allo stadio di prototipo) \u00e8 una grande opportunit\u00e0 per gli scienziati, fino ad ora impegnati nella difficile ricerca che di un “hardware” adeguato per condurre le loro ricerche in questo campo.<\/p>\n

\"\"<\/p>\n

Una menzione d’onore va a Lambda Provisioned Concurrency<\/a>, che ha finalmente risolto il famigerato problema del cold-start per le applicazioni serverless (pagando una piccola tassa uscendo da un modello di puro on-demand), e a EKS Fargate,<\/a> annunciato 2 anni fa, ma ancora, secondo me, l’unico modo ragionevole per far funzionare Kubernetes su AWS.<\/p>\n

Sul fronte networking<\/strong>\u00a0nessun annuncio particolarmente eclatante, ma comunque molti annunci interessanti che vanno ad aggiungere nuove funzionalit\u00e0 ai servizi gi\u00e0 esistenti, rendendoli pi\u00f9 pronti per l’impresa in termini di supporto di topologie di rete complesse (supporto multicast<\/a>, inter-region peering<\/a> e Network Manager<\/a> per Transit Gateway<\/a>), fornendo prestazioni adeguate (VPN site-to-site accelerate<\/a>), e supportando integrazioni di terze parti (VPC ingress routing<\/a>). Con quest’ultimo, le aziende molto grandi saranno in grado di portare nelle loro VPC appliance di sicurezza e UTM<\/a> distribuiti tra ogni livello applicativo e ogni subnet per motivi di conformit\u00e0, non avendo principalmente idea di cosa farne.<\/p>\n

Non provateci a casa.<\/p>\n

Molti annunci intriganti per Database, DWH, Data Lakes<\/strong>\u00a0aggiungono funzionalit\u00e0 (integrazione di Aurora Machine Learning<\/a>, Redshift Managed Storage<\/a>), prestazioni (RDS Proxy,<\/a> AQUA per Redshift<\/strong>) e governance (Athena<\/a> e Redshift Federated Query<\/a>). Redshift, in particolare, sta ottenendo un numero impressionante di nuove funzionalit\u00e0 e prestazioni migliorate. Un altro messaggio chiaro e diretto ai clienti Oracle e un altro episodio della battaglia tra le diverse filosofie dei due giganti dell’informatica: database specializzati vs. database general-purpose<\/strong>. Chi vincer\u00e0?<\/p>\n

Il piatto forte dell’intero evento \u00e8 stato come previsto l’argomento AI\/ML,<\/strong>\u00a0il topic di tendenza per eccellenza degli ultimi tre anni nel panorama Cloud, se non addirittura in tutto il mondo IT (chiedo scusa agli amanti delle blockchain!).<\/p>\n

Per quanto riguarda i servizi di IA, sembra che gli ingegneri di Seattle stiano mettendo l’esperienza AI di AWS (e di Amazon.com) in servizi e campi sempre pi\u00f9 diversi, dal rilevamento delle frodi<\/a> al customer care<\/a>, dal riconoscimento delle immagini<\/a>, all’analisi del codice<\/a><\/strong>… tra tutte le applicazioni possibili, ecco infatti l’idea di Amazon CodeGuru<\/strong> di sfruttare i modelli ML per rivedere e profilare il codice. Ma il servizio \u00e8 in fase iniziale (per ora solo supporto Java), e discretamente costoso<\/a>. Sono molto curioso di vedere se le ottimizzazioni delle prestazioni e dei costi derivanti dai processi di revisione e di profilazione<\/strong> riusciranno a bilanciare il costo del servizio. Devo solo resuscitare alcuni vecchi pezzi di codice Java per provare \ud83d\ude42<\/p>\n

Lato ML, fondamentalmente, si tratta di mettere SageMaker sotto steroidi<\/strong>, aggiungere un IDE dedicato<\/a>, un ambiente di collaborazione<\/a>, effettuare esperimenti<\/a>, introdurre automazione dell’elaborazione,<\/a> monitoraggio dei modelli<\/a> e debugging<\/a>… addirittura si parla di generazione automatica dei modelli<\/a>. Su quest’ultimo aspetto ho alcuni dubbi: quale sar\u00e0 il compromesso tra facilit\u00e0 d’uso, precisione e flessibilit\u00e0? Forse si pu\u00f2 chiedere ad alcuni umani.<\/a>..<\/p>\n

DeepComposer<\/a> merita una discussione a parte (ma certamente non meritava la mia coda di 6 ore per entrare nell’ultimo re:Invent workshop disponibile<\/a>…). Sono un tastierista, e quando Matt Wood ha annunciato DeepComposer<\/a>, ero cos\u00ec eccitato al pensiero di mostrare la potenza del Machine Learning ai nostri clienti mentre suonavo assoli di synth in stile Dream-Theater davanti a loro<\/a>… Ma poi, ecco il meme “aspettative contro realt\u00e0”: io che suono una versione con un solo dito di “Twinkle twinkle little star” senza successo cercando di istruire il servizio DeepComposer su come armonizzarlo e organizzarlo… Scherzi a parte, credo che ci siano stati molti fraintendimenti su questo servizio.<\/a><\/p>\n

Facciamo chiarezza:<\/p>\n