 Thank you so much, Diane, and as Diane was saying, if anyone needs to have some details in English, I will stick around and feel free to reach out to me and talk to me and I will explain the bits and bytes of the topics that I'm going to have the discussion now in Italian. Mi presento, io sono Marco D'Angelo, lavoro per Microsoft Italia, più o meno, nel senso che lavoro per un team internazionale che si incarica di lavorare con gli sviluppatori. Ora, rivesto due o tre ruoli diversi e per questo che comincio la presentazione ingessato non esattamente con la camicia bianca, ma poi mi perdonerete, magari, evolviamo il discorso verso un'ambito un po' più tecnologico. Tendenzialmente, la presentazione oggi su che cos'è? Oggi è su una tecnologia che viene chiamata ARO, Azure Redact OpenShift. Che cos'è che rappresenta ARO? Praticamente il percorso terminale di una partnership che con Redact va avanti da diverso tempo, ma che negli ultimi anni è diventata sempre più forte. Diciamo che negli ultimi Open Source Days, quando sponsorizzavamo l'evento, la gente si chiedeva che cosa ci facessimo. Da Ian, giustamente, diceva, non mi sarei mai aspettata di avere una conferenza per sviluppatori comuni di con un tizio di Microsoft che parla e pure ci siamo arrivati. Perché questo? Perché, indipendentemente dalla partnership, indipendentemente dal tutto siamo due realtà, poi chiamateci aziende, chiamateci vendor, quello che volete, che nell'ambito delle proprie competenze indirizzano noi il 95% delle top 500. Redact indirizza il 100% delle Forcing Global 500, Microsoft è presente per essere chiari in tutte le società anche le più piccole, ma Azure, che è l'acchierata di oggi, ha ancora una penetrazione, diciamo, del 95% o esattamente del 100%. Siamo quindi qui a discutere di che cosa, della partnership, che data, come dire, indietro di parecchio tempo, data indietro di quando supportavamo Redact come macchina virtuale su Hyper-V, data di quando abbiamo importato le immagini dal mondo on-premise che abbiamo messi su Azure di Redact Enterprise Linux, del fatto che abbiamo in Italia degli esempi, tutto sommato, estremamente importanti di carichi applicativi, tipo SAP, che girano su Rella, su Azure, SAP di realtà produttive e industriali italiane. Quindi c'è ne sono tante di cose che possiamo fare insieme. Una delle quelle che si stiamo concentrando è la parte OpenShift, perché rappresenta, e ne siete testimonianza tutti quanti voi, un grandissimo focus per realtà sviluppatori, partner, ecc. Ora, tendenzialmente non vi devo spiegare qual è il valore di OpenShift perché siete qua, perché avete visto quelle che sono tutte le considerazioni fatte sull'evoluzione della piattaforma dove Redact sta andando con Redact. La considerazione che vi faccio è una considerazione un po' più generale rispetto a Kubernetes. Allora, Kubernetes fatto bene e complicato. Noi abbiamo come Microsoft la nostra implementazione di Kubernetes su Azure che si chiama KPS. Non tantissimi clienti sono in questo momento in produzione con quella roba là perché la complessità che sta dietro, a tutto quanto quello che deve essere tenuto in considerazione quando si fa un'implementazione enterprise grade con applicazioni che se si fermano, fermano l'azienda, non è banale. I cluster vanno installati, vanno manutenuti, devono essere sicurizzati, deve esserci poi quell'esema dei tu operation, cioè è facile installarlo, metterli in piedi, poi deve essere sicuro che man mano che i tuoi sviluppatori a botta di deploy di vario tipo riescano a sfruttare la piattaforma. Per questo motivo che cosa viene fuori? Viene fuori che molte dei challenge che stanno dietro all'utilizzo di una piattaforma Kubernetes based dove tutto bello quello che volete il mondo DevOps, tutto bello il nostro processo Agile con sviluppatori, sistemisti, chi si occupa di security di network in database che magari fanno uso davvero di metodologie e di tool per il versione di quello che fanno, ma la parte di security, la parte di maintenance e la parte di delivery sono cose con le quali non si scherza. OpenShift da questo punto di vista da davvero una mano, in quanto dalla possibilità, indipendentemente dalla tecnologia sottostante, di astrarre molto e di rendere davvero molto, se volete, prediciibile tutto quanto quello che è il processo che afferisceachts a questi tre ambiti. Ora, perché si sceglie Kubernetes e perché si scegli OpenShift? Abbiamo detto l'hanno già spiegato e è quasi, se volete lasciatemi ricoprire i compiti di un produttore. Per quanto riguarda me, l'idea era raccontarvi un attimo come si mettono insieme queste due cose, quindi scusate, fa caldo, un po' per quello, un po' perché abbiamo finito con le slide, con le Fortune e Garner. Allora, Azure, quante persone sanno cos'è Azure in questa platea? Fatemi la cortesia per alzata di mano, grandissimi! Quante persone in questa platea usano Azure anche per il sitarello, come dire, istituzionale, ma c'hanno qualcosa in produzione su Azure? Eh, diciamo, un po' tre ampli margini di miglioramento, come si dice, va benissimo. Scherzi a parte. Per non vi sto a spiegare cos'è Azure, il cloud per scarabili di Microsoft che se la giocava a Pari con AWS, GCP e dietro e quelle cose le conoscete, le leggete, come dire, sul gossip, internet talo tutti i giorni. L'idea era raccontarevi cos'è Azure, non tanto come, come è fatta, questioni di servizi, 97 tipologie di crassi di servizi, macchine fino a 64 terra, quella la sapete, la trovate tranquillamente. Azure è questo. Azure sono 57 regione sparse per il mondo. Le ultime due che abbiamo, come dire, aperto e battezzato il mese scorso sono in Svizzera e in Norvegia. Nell'arco del 2020 apriremo altre due regione in Europa. Non vi dico in che country, se non sembra gruppo. Quello che fa la differenza rispetto al Kubernetes è complicato, ci vuole OpenShift. A volte l'infrastruttura è complicata e quando diciamo che l'infrastruttura è complicata ci vogliono i backup, ci vuole la resilienza, ci vuole la business continuity, bisogna essere in grado di resistere all'alluvione, al terremoto, quello che volete. Il più grosso investimento che Microsoft sta facendo, oltre il livello di partnership con realtà come redatta, è un investimento banalissimamente su quella che è la componente di building. Noi spinghiamo 3billiona, oltre erano 3billiona all'anno, adesso sono 3billiona a semestre per aprire i nuovi datacenter. Avere a che fare con un datacenter Microsoft o mettere un cluster OpenShift su Microsoft, Microsoft Azure significa che da qualche parte dove scegliamo di metterla abbiamo come minimo 2 datacenter, 1 e 2, tendenzialmente 3 perché stiamo finendo il rollout del concetto di zoning, quindi troverete 3 zone di resilienza per ognuna delle 57 alle in cui abbiamo datacenter. Questo mi serviva per passare un messaggio legato al fatto su come si fa infrastruttura, non abbiamo da imparare quasi da nessuno, l'ultima tipologia di datacenter che mettiamo a disposizione impieghiamo 3 mesi dalla progettazione al deployment di un datacenter, perché i nostri datacenter somigliano a questa roba qua. Non ne abbiamo ancora uno in produzione reale, li stiamo, come dire, affossando letteralmente in questi giorni con il bene placido di tutto quanto quello che il controllo per l'impatto ambientale, i pesci amano quel grado in più che un datacenter gli dà nelle acque del nord a nord Europa, ma tendenzialmente questo è il, come dire, il perché in genere si sceglie o si lavora con Azure, perché se metto un workload in produzione su Azure quello che si rischia è che il workload sia effettivamente non solo bollato con la disponibilità dei 5.9 di avalabiliti, ma perché effettivamente questa cosa ci sia. Poi uno dei vantaggi dei cloud per scalabili e anche per quanto riguarda diciamo così OpenShift è il fatto che questa cosa si può testare, la possiamo verificare senza implementare, senza investire un rene e poi decidere se vediamo che le premesse e le promesse sono mantenute e eventualmente andare in produzione. Questo nulla di nuovo rispetto a qualsiasi altro cloud per scalabile, vi dicevo. Il mio messaggio era semplicemente per darvi un'idea di quanto completa possa essere l'offering in questo momento e quanto Microsoft ci crede, quindi non è solamente un, come dire, un fuoco di paglia l'investimento che Microsoft ha. Lo facciamo e siamo in questo momento più o meno la più grossa compagnia intermedia di capitalizzazione al mondo semplicemente perché c'è un grosso ritorno da questo investimento. Ok, e qua finisce la chiacchiera su Azure. Adesso mi si arrabbia il signore se non avrei fatto una cosa ulteriore e avrei tirato fuori questa roba qua che è il perché Microsoft lavora con Red Hat. Perché Microsoft 5N è questa parte tornata indietro a lavorare non solo con le società, le imprese, Office, Exchange per carità, ma è tornata a parlare con gli sviluppatori. E quando parliamo con gli sviluppatori, abbiamo capito che non possiamo più essere solo software vendor, non ha senso essere quelli che vendono .NET, SQL e Windows Server. Se gli sviluppatori usano una toolchain basata su Microsoft, se Linux, se si stanno per le tue traduzioni, se MySQL, PostgreSQL e Redis sono ognuna per le sue aree, gli ambiti database preferenziali per fare caching piuttosto che per fare transazioni piuttosto che per essere scalati dovunque, va benissimo che sia così. Questo perché non esiste più, diceva la Microsoft che deve solo vendere SQL Server, che perché è un grandissimo prodotto come Windows, iOS, etc., etc., ma non è più solo quello del nostro business. Per cui, che cos'è Azure Redat OpenShift o ARO, come le diciamo in italiano? Fondamentalmente è una implementazione full manager di OpenShift ingegnerizzata con Redat. Quindi, terra a terra, la vende Microsoft, siete quei pochi utenti che usano Azure in produzione e potresti addirittura accenderlo all'interno delle nostre sottoscrizioni? Non è l'unica modalità che esiste per far girare OpenShift su Azure. Esiste ancora la possibilità di avere la templatizzazione della farm che mette dentro il Mastery Node, è tutto quanto quello che siamo abituati a vedere in termini di una gestione di una farm OpenShift, ma è un'implementazione che si porta dietro. Una sla del 99, significa che se va giù vi ridiamo, facciamo la nota di credito del costo, diciamo così, dell'esborso già fatto, che si incarica di essere sufficientemente aperto. Poi, in massima di sufficientemente aperto, saremo presenti agli Open Source Days con Redat, racconteremo casi di clienti che stanno usando ARO, casi di clienti che hanno detto io che hanno pensito di fare cose talmente di un certo tipo, devo modificare talmente tanto l'infrastruttura sulle quali ARO magari non matcha, ma nel 90% dei casi lasciatemi dire ARO è non given come un starter come problema, e in termini scalabilità quello di vantaggio, diciamo, derivato dalla parte cloud. Quindi entrando un po' più nel dettaglio. Se immaginate quella che è un'implementazione di base di un cluster OpenShift su Azure, a cosa somiglierebbe? Somiglierebbe ad una serie di macchine virtuali che hanno il ruolo di master, che è necessariamente tre da blueprint, macchine di infrastruttura che fanno da scale set e da application, quindi sempre. Scusate, macchine virtuali di cui, come su qualsiasi altro cloud provider voi gestite, scegliete la parte di storage, premium non premium costoso o meno, la componente di macchine con la necessità di gestirle, perché è vero che Azure li accende, ne fai logging, ne fai la parte di healing, la fa passare da un data center all'altro, da una regione all'altro, ma comunque sono macchine virtuali che esistono e dovete sapere che esistono. C'è la componente di bilanciamento, c'è la necessità di esporre tutto all'esterno, c'è la necessità di proteggere quello che espondiamo all'esterno, c'è la possibilità o la necessità di gestire le componenti di sicurezza legate alla autenticazione egiurati di direttori piuttosto che Azure Key Vault lo store di tutte quante le credenziali di accesso a quelle che possono essere componenti applicative, database e quant'altro che stanno sopra sotto l'infrastruttura. Questa roba qua si implementa in Azure ed è disponibile da ormai due anni con quello che si chiama supporto congiunto di Redat. Se un cliente Azure qualcosa non torna, chiami Azure, il supporto Azure poi chiama l'ingegginio di Redat e viceversa. Che cosa comporta questa roba e in che cosa cambia le regole del gioco OpenShift su Azure? Questa cosa comporta, dicevamo, che esistono Decluster da gestire, esistono la parte di security di infrastruttura applicativa e logica da dover gestire. Esiste la necessità di verificare anche come monitorare e operare le VM non fosse altro anche per fare efficienza. Una dei vantaggi Declout scalabile è che io accendo e scalo, poi se non mi serve prendo, spengo, faccio in modo di scalare verso il basso le risorse quando non ho carico in maniera di risparmiare. Tutta questa roba qua, se è un cluster, ce l'ho in produzione usando il paradigma delle VM e a carico mio la gestione. Nel momento in cui passiamo a Daro, cosa succede? Che tutta quanta questa infrastruttura qua la assorbiamo, la facciamo sparire e quello che rimane, semplicemente, la gestione per me amministratore delle componenti di devo integrarti con l'Active Directory dell'azienda se lo voglio, se voglio che l'accesso anche alla consola di amministrazione di OpenShift venga fatto con credenziali D a D, devo gestire i secrets utilizzando uno storsi cure, non ando sicuramente a mettere dentro ai distributi di configurazione da qualche altra parte, quindi userò un altro servizio che è quello di Azure Key Vault, se voglio altrimenti faccio scroll dei dati da qualche altra parte. Se volete con Azure posso addirittura utilizzare un modulo HSM per metterci certificati credenziali e tendenzialmente a quel punto in poi è solo consola di amministrazione e gestione delle app. Andando avanti quindi quello che viene fuori è che la componente di Focus come persona IT, come sviluppatore, come altro ce l'ho su le componenti applicative, quelle non metterò nemmeno nessuno perché è il mio pane, quindi creare container, deployare container, gestire la componente di automazione delle build, scegliere quella che è la mia e crearmi la mia pipeline di CI, CD, se voglio usare Azure DevOps, piuttosto che GitHub, piuttosto che Jenkins per la parte di CD, quello è in un invariante per quanto lasciatemi dire ci tocca. Per quanto riguarda il focus di Red Hat e Microsoft è tutta la parte di orchestrazione di più basso livello, network in storage, registri, telemetria, security fino alla componente infrastruttura, quindi il cavo HDMI che non funziona, in questo caso specifico non c'è, ma nella componente di interazione e integrazione e roba di cui ci facciamo carico noi ed è contratto attualizzata tra la componente cliente e la parte Red Hat Microsoft dicevamo. Quindi fondamentalmente che cose che mi porto a casa, secondo me le cose che danno un minimo di informazione in più sono la componente di alta fidabilità e node scaling given data come caratteristica della piattaforma, cioè il prodotto scala senza dover fare investimenti su hardware ci siamo, e la componente di first party Azure Service. Essere un first party Azure Service significa che non è, lasciatemi dire, una blueprint, un deployment, un accrocchio, significa che è un investimento, una cosa per cui rispondiamo in prima persona. Quella roba deve funzionare perché è un prodotto, passatemi in termine brutale, è un prodotto Microsoft, realizzato con il bene paese di Red Hat, ma è a tutti gli effetti una sorta di contratto implicito tra noi e voi. Relativamente agli altri aspetti più tecnici, la componente di virtual network integration, per chi avessi, lasciatemi un'idea di come funziona Azure e la faccio vedere tra un secondo, è quella che poi mi consente di se ho fatto un investimento tutto sulla componente cloud, di gestire la parte di sicurezza. Se ho un investimento ibrido per cui ho un cluster OpenShift con l'applicazione nel cloud e una serie di workload applicativi che sono ancora on-premises e questi si devono e li devo far parlare, la componente di networking che sta sotto ad Azure è pensata per venire in aiuto e non rendere complicato il tutto. Ora, per quelle persone che hanno già dato un'occhiata ad Azure, in che cosa si traduce avere OpenShift su Azure come servizio of first party? Significa che non è semplicemente un'implementazione o un'installazione da marketplace, prendo, faccio click e installo. È un servizio che è integrato sia con la GUI, quindi sia con il portale di Azure, sia con quelli che sono i componenti perché ha familiarità con la CLI di Azure, con il comando EZ. EZ è qualunque cosa debba fare su Azure, EZ, AKS, Genera, Eprovision, Cluster, Kubernetes, nativi di Azure, a Z OpenShift si incarica di utilizzare quelle che sono le primitime native di OpenShift per implementare ARO. Una volta fatto questo, cioè una volta messo in piedi ARO, un'altra delle cose che vi menzionavo e oggi non faremo vedere come dire nativamente tutto perché poi vi spiego come fare per vederlo insieme. Un'altra delle cose è l'integrazione con Active Directory, per cui io posso accedere alla mia dashboard OpenShift, all'OpenShift container platform, come avete visto prima, facendo logon utilizzando credenziere di Active Directory. Questo a cosa può essere utile? Cosa può tornare utile? Può tornare utile se la mia società implementa già Active Directory per la sicurizzazione di quelli che sono gli ambienti on-premises, ma può tornare utile anche perché la Active Directory di Azure si lega poi con quelli che sono alcuni servizi, abbastanza importanti che sono i servizi di multi-factor authentication, quindi ho gratis, ho già pagato nel servizio la possibilità di fare MFA con cellulare token app di identificazione, con il controllo di quelli che sono la protezione degli accessi, quindi il controllo di chi accede al mio cluster da dove in tempo reale, IP, geografia, timing, zoning, eccetera, quindi un altro esempio se volete di quelle tematiche di sicurezza che non possono prendere in considerazione, ma che se lavoro come una piattaforma cloud come Azure, mi possono tornare già disponibili. Altro aspetto, lo menziamo prima, la componente Virtual Network Integration. La componente Virtual Network Integration serve, dicevamo perché non perché Microsoft abbia Azure, adesso Azure è diventato il martello per tutti i chiodi. Siamo perfettamente conci, e siamo quelli che hanno generato ai tempi, il proprio 75. Il problema dei server sotto le scrivenie, sappiamo che rimangono workload per mille ragioni, possono essere legate a tematiche di industrie 4.0 con le linee di produzione che sono là, sono in fabbrica dove puoi portare su, o a scenari dove la raccolta dati o il processing didati va fatto sul campo. Una delle funzionalità più, se volete, importanti che raccontiamo è la componente di vignette di networking che sta dietro ad Azure, che è quella che mi consente ad esempio con servizi come express route di aprire un peering diretto tra quella che è il mio networking e la componente di networking di Azure facendo mashing di quella che è la mia red MPS, piuttosto che parlando con il mio provider di connectività e dicendo io non voglio passare su internet a VPN o non VPN, voglio parlare direttamente per tagliare la ratenza piuttosto che per garantirmi sicurezza nelle comunicazioni con Azure. Anche questo è un, lasciatemi dire, non un problema che vale per, storicamente per Azure, ma che è stato mappato espressamente su uno dei servizi che mi chiamo a disposizione per AR. E l'ultimo aspetto era la tematica di supporto unificato. Non perché Microsoft è qui sopra, abbiamo la pretesa di essere quelli che danno supporto a tutto, facendo poi cadere i ticket, ma il tema è tutto quello che è infrastruttura di quella parte sotto, dicevo, gestita da noi e massima responsabilità nostra a farla funzionare come lo facciamo per i circa 970 clienti enterprise che abbiamo solo nel nord d'Italia e che fanno un consumo enterprise di Azure. Diciamo che enterprise intendo dai 200K in su circa. Ma lo è anche per la parte se volete redact. Quindi indipendentemente da come mi presento, se cliente redact o cliente Microsoft, il supporto sarà congiunto. Queste fondamentalmente sono tutte cose che servono a passare il messaggio del sviluppo. Abbiamo la consapevolezza, dicevamo, abbiamo iniziato la discussione dicendo redact OpenShift è una risposta ad un problema complicato, come fare Kubernetes in maniera seria e in maniera funzionale. Lo è di nuovo se lo implementiamo su Azure facendo che cosa, facendo notare che anche la parte di security tendenzialmente legata, le tematiche d'authenticazione abbiamo citata, la parte di TLS, la parte di certificati che posso importare e quindi usare direttamente i miei, la parte di virtual networking, ma anche la parte di, lasciatemi dire, hardening. Tendenzialmente una delle complessità che a volte si nota è in termini di sicurezza quanto tempo impiega un vendor a recepire quelle che sono le fix di security che vengono mesi a disposizione della community, in questo caso sul progetto source Kubernetes rispetto a OpenShift, quello che vedete qui tendenzialmente nel momento in cui OpenShift porta a casa quelle che sono le fix, portano a casa tuttimilamenti di piattaforma, per quella che è la piattaforma supportata al momento su Aro che quindi è la 3, stiamo arrivando con la 4, immediatamente appena queste sono state raccolte all'interno di OpenShift vengono rese disponibili come build all'interno di Aro, quindi è sempre current rispetto alla versione corrente deployata il livello di security fix di piattaforma. Questo vale sia per la parte, dicevamo, di fix in se sia per la parte di integrazione con quelle che sono le altre funzioniative di Azure, quindi OpenShift su Azure si integra con la componente di sicurezza che stai dietro ai pezzi di storage, di audit e logging, di network isolation e a tutto quello che è il security ecosystem che c'è perché Azure non si ferma a far funzionare Aro, si estende dando mia possibilità se voglio complementare quello che OpenShift su Azure fa con un sistema di logging di terze parti, se preferisco Splunk rispetto all'altro, piuttosto che un sistema di monitoraggio di application firewalling diverso rispetto a quello fornito essendo, come dicevamo prima, concludendo il servizio for sparti, tutti gli altri pezzi di Azure si mettono davanti o in parallelo a Aro per complementare o aumentarne quelle che sono le caratteristiche. Ora, in termini di developer experience, una volta che l'avete implementato, una volta che abbiamo fatto a z OpenShift create o che siamo andati sul portale di Azure, abbiamo creato il cluster Aro, da lì in poi l'esperienza di gestione esattamente la stessa. Quindi quello che avrei fatto con i tool classici di OpenShift o si login o si new project o si new app sono al 100% l'esperienza di gestione e di management che trovate per arrivare da lì al publishing delle proprie applicazioni. Chiudo dicendo, se dovete portarevi a casa una parola del a che cosa mi serve OpenShift manager su Azure, mi serve a fare le cose, fatte bene per definizione, ma velocemente, perché velocemente riesco a fare il provisioning di ambienti di test e development, a fare il deployment degli ambienti di produzione e se qualcosa non va, se il progetto subiri tardi, se ci sono considerazioni, fare lo scale down o lo scale up dell'applicazione è una cosa letteralmente insita nella piattaforma. Non devo comprare hardware, non devo fare overprovisioni, non devo fare cose del genere. Chiudo con due considerazioni. Vediamo un attimo se... Dove possono essere fatti a profondimenti il solito che abbiamo detto, perché in 30 minuti raccontarvi che Microsoft, Cos'Ager, Cos'OpenShift, un ultimo insieme, era abbastanza challenging. Come Microsoft, con il supporto di RAT, noi realizziamo nei nostri uffici di Milano e Roma dei laboratori, li chiamiamo Workshop, che sono degli Enzone Lab, con teacher di partner Microsoft, non Microsoft toCour, che guidano in una giornata di laboratorio da la creazione dell'applicazione, di micro servizi, creazione del cluster, creazione di alio, di applicazione del monitoraggio. Riceverete nella thank you mail che vi invieremo se avete dato lo che essere contattati, altrimenti poi contattate i vostri referenti Red Hat o Microsoft, se ne avete, per sapere quali sono le date di questi Workshop. Diciamo Milano e Roma, se vediamo che c'è tanta richiesta ne organizzeremo anche altri. Seremo poi presenti al Red Hat Open Source Days di Milano e Roma a fine novembre e inizio e dicembre per fare demo interattive in un boot con la componente di tutto. Se avete oltre le informazioni richieste, etc., oltre che contattarmi perché sono in giro, mi trovate su LinkedIn e su Twitter, seguitemi, contattatemi, le informazioni sono pubbliche, le condividiamo senza problemi. Grazie mille a tutti.