Introduction to Microsoft Azure Well Architected Framework in Italian - Session 1 of 6
Introduzione a Microsoft Azure Well Architected Framework in Italiano - Sessione 1 di 6
Modulo 1: introduzione, principi e concetti base
2. ABOUT ME
➤ Rauno De Pasquale, Co-Founder and CTO at Newesis Srl,
constantly trying to reconcile his degree in Philosophy with
a passion for computer science. After almost 18 year at
Deltatre, at the beginning of 2019 he creates Newesis, with
the aim of simplifying the use of the most advanced
services of Cloud platforms even in fields other than sports.
➤ Newesis is a pure technology based, Cloud Native company,
having as a target to support and evolve adoption of
DevOps culture and practices, with particular focus on
Kubernetes as technological platform.
➤ Twitter: @RaunoDepa
➤ Twitter: @newesissrl
3. AZURE WELL-ARCHITECTED FRAMEWORK –
SESSIONE 1 DI 6 - AGENDA
➤ Presentazione generale del percorso
➤ Cloud Computing – Concetti base
➤ Cloud Native Application – Principi fondamentali
➤ Microsoft Azure Well-Architected Framework - Introduzione
5. AZURE WELL-ARCHITECTED FRAMEWORK –
PERCORSO
➤ I Modulo: introduzione, principi e concetti base
➤ II Modulo: affidabilità
➤ III Modulo: sicurezza
➤ IV Modulo: ottimizzazione dei costi
➤ V Modulo: eccellenza operativa
➤ VI Modulo: efficienza delle prestazioni
6. AZURE WELL-ARCHITECTED FRAMEWORK –
OBIETTIVI
➤ Sapere valutare tra una opzione « Lift and shift» o «cloud optimised»
➤ Sapere valutare tra opzioni IaaS, PaaS e SaaS
➤ Sapersi orientare tra gli strumenti e le risorse di Microsoft Azure
➤ Sapersi orientare rispetto possibili scelte organizzative e definizioni di ruoli e responsabilità
in un ambito Cloud Native e DevOps
8. CLOUD COMPUTING – STORIA E CONCETTI
➤ «Il cloud computing (in italiano nuvola informatica) indica, in informatica, un paradigma di
erogazione di servizi offerti su richiesta da un fornitore a un cliente finale attraverso la rete
internet (come l'archiviazione, l'elaborazione o la trasmissione dati), a partire da un insieme
di risorse preesistenti, configurabili e disponibili in remoto sotto forma di architettura
distribuita.» (fonte: Wikipedia)
9. CLOUD COMPUTING – STORIA E CONCETTI
➤ 2002 Amazon crea Amazon Web Services (AWS)
➤ 2006 S3 and EC2 general availability (AWS)
➤ 2008 Google App Engine beta availability
➤ 2008 Microsoft crea la sua azienda di Cloud Computing (Azure)
➤ 2009 Alyum (Alibaba Cloud) viene fondata dal gruppi Alibaba in Cina
➤ 2010 Azure General availability
➤ 2010 Rakspace e NASA creano la piattaforma Open Source OpenStack
➤ 2011 IBM Cloud services general availability
➤ 2012 Google Cloud Compute Engine general availability
10. CLOUD COMPUTING – STORIA E CONCETTI
➤ Differente Tecnologia
➤ Nuovi modalità di utilizzo
12. CLOUD COMPUTING – STORIA E CONCETTI
➤ Dal Server al Serverless – da Infrastrutture a Servizi
13. CLOUD COMPUTING – STORIA E CONCETTI
Bisogna portare le applicazioni
nel Cloud e poi sottoporle a un
graduale processo di modifica
per farne collimare la struttura
con le nuove logiche distributive
e funzionali, come prevede il Lift
& shift?
Oppure, seguendo la logica del
Refactoring, è meglio riscriverle
ex novo, senza stravolgerne
interfaccia, funzionalità e
comportamento per adattarle da
subito alla modalità “as-a-
service”?
17. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ Il principio dell'architettura per il cloud, noto anche come
architettura cloud-native, si concentra su come ottimizzare le
architetture di sistema per le capacità uniche del cloud.
➤ L'architettura tradizionale tende a ottimizzare per
un'infrastruttura fissa e ad alto costo, che richiede un notevole
sforzo manuale per la modifica.
➤ L'architettura tradizionale si concentra quindi sulla resilienza e
sulle prestazioni di un numero fisso relativamente piccolo di
componenti.
➤ Nel cloud, tuttavia, un'infrastruttura così fissa ha molto meno
senso perché il cloud viene addebitato in base all'utilizzo
(quindi risparmi denaro quando puoi ridurre l'ingombro) ed è
anche molto più facile da automatizzare (quindi l'aumento e la
riduzione automatici è molto più semplice ).
➤ Pertanto, l'architettura cloud-native si concentra sul
raggiungimento della resilienza e della scalabilità attraverso il
ridimensionamento orizzontale, l'elaborazione distribuita e
l'automazione della sostituzione dei componenti guasti.
18. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ Disegnare per l’automazione:
➤ Infrastruttura (IaC): automatizzare la creazione
dell'infrastruttura, insieme agli aggiornamenti,
utilizzando gli strumenti Terraform
➤ Integrazione continua/Consegna continua (CI/CD):
automatizzare la creazione, il test e la distribuzione dei
pacchetti che compongono il sistema utilizzando
strumenti come Jenkins o Azure DevOps.
➤ Ridimensionamento: a meno che il carico del sistema
non cambi quasi mai, è necessario automatizzare
l'aumento e la riduzione del sistema in risposta
all'aumento del carico e la riduzione in risposta a cali di
carico prolungati
➤ Monitoraggio e ripristino automatizzato: eseguire il
monitoraggio e l'accesso ai sistemi cloud-native come
elemento fondante del ciclo di vita della soluzione.
19. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ Gestione delle informazioni di stato
➤ Memorizzare lo "stato", che si tratti di dati utente (ad es. gli articoli nel
carrello degli acquisti degli utenti o del loro numero di dipendente) o di stato
del sistema (ad es. quante istanze di un lavoro sono in esecuzione, quale
versione del codice è in esecuzione in produzione) , è l'aspetto più difficile per
le soluzioni di un'architettura distribuita e nativa del cloud. Occorre quindi
progettare il sistema in modo che sia intenzionale su quando e come
archiviare lo stato e progettare i componenti in modo che siano senza stato
ovunque sia possibile.
➤ I componenti stateless sono facili da:
➤ Ridimensionare: per ridimensionare, aggiungi semplicemente più copie. Per
ridimensionare, chiudi le istanze di terminare una volta completata l'attività
corrente.
➤ Riparare: per "riparare" un'istanza guasta di un componente, è sufficiente
terminarla nel modo più elegante possibile e avviare una sostituzione.
➤ Rollback: se si dispone di una distribuzione errata, è molto più facile eseguire
il rollback dei componenti senza stato
➤ Bilanciare il carico: quando i componenti sono senza stato, il bilanciamento
del carico è molto più semplice poiché qualsiasi istanza può gestire qualsiasi
richiesta.
22. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ Infrastructure as Code
➤ Configuration as Code
➤ Gestire le proprie infrastrutture come
«mandrie» e non come «cuccioli»
➤ «L'infrastruttura come codice (IaC) è il
processo di gestione e provisioning delle
risorse di computing nei data center
tramite file di definizione leggibili dalla
macchina, piuttosto che configurazione
hardware fisica o strumenti di
configurazione interattivi.» (fonte:
Wikipedia)
24. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
Donovan Brown – Principal DevOps Manager at
Microsoft
DevOps is the union of people, process, and products to
enable continuous delivery of value to our end users.
DevOps is not just automating a pipeline so we can
quickly deliver software. Our goal is to deliver value.
It is very important to realize that DevOps is not a
product.
You cannot buy DevOps and install it.
DevOps is not just automation or infrastructure as
code.
DevOps is people following a process enabled by
products to deliver value to our end users.
26. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ “Observability is a measure of how well
internal states of a system can be inferred
from knowledge of its external outputs. In
control theory, the observability and
controllability of a linear system are
mathematical duals. The concept of
observability was introduced by
Hungarian-American engineer Rudolf E.
Kálmán for linear dynamic systems. A
dynamical system designed to estimate
the state of a system from measurements
of the outputs is called a state observer or
simply an observer for that system.”
27. AZURE WELL-ARCHITECTED FRAMEWORK – CLOUD
NATIVE ARCHITECTURE
➤ La raccolta di metriche e gli avvisi sono
attività guidate dal business.
➤ La raccolta di metriche e la gestione degli
avvisi sono cose diverse. È necessario
raccogliere metriche per avere visibilità sui
propri sistemi, ma non è necessario
utilizzare tutte le metriche per generare
avvisi.
➤ La misurazione, il monitoraggio e l'allerta
devono essere correlati agli SLO.
➤ Non avvisare per ogni evento, gli avvisi
devono segnalare un impatto sul servizio e
richiedere una azione.
29. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Azure Well-Architected Framework è una
serie di principi guida utilizzabili per
migliorare la qualità dei carichi di lavoro.
➤ Il framework è costituito da cinque elementi
fondamentali dell'eccellenza
dell'architettura:
➤ Affidabilità
➤ Sicurezza
➤ Ottimizzazione dei costi
➤ Eccellenza operativa
➤ Efficienza delle prestazioni
30. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Affidabilità
➤ Un carico di lavoro affidabile è sia resiliente che disponibile.
➤ La resilienza è la capacità del sistema di eseguire il ripristino in caso di errori e continuare a
funzionare.
➤ L'obiettivo della resilienza consiste nel ripristinare uno stato completamente funzionale
dell'applicazione dopo un errore.
➤ La disponibilità indica se gli utenti possono accedere al carico di lavoro quando è necessario.
31. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Affidabilità
➤ La creazione di un'applicazione affidabile nel cloud è diversa rispetto alla tradizionale
procedura di sviluppo delle applicazioni.
➤ Anche se in genere sono stati acquistati livelli di hardware ridondante di fascia alta per
ridurre al minimo le probabilità di errore di un'intera piattaforma applicativa, nel cloud è
stato riconosciuto in anticipo che si verificano errori.
➤ Invece di provare a evitare completamente gli errori, l'obiettivo deve essere quello di ridurre
al minimo gli effetti di un singolo componente in errore.
32. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Affidabilità
➤ La resilienza è la capacità di un sistema di correggere gli errori e continuare a funzionare.
➤ Ogni tecnologia ha modalità di errore specifiche che è necessario tenere in considerazione
durante la progettazione e l'implementazione di un'applicazione.
➤ Servizi di Azure specifici hanno caratteristiche diverse in termini di resilienza e di controlli e
correzioni automatiche.
34. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Sicurezza
➤ Si pensi alla sicurezza per l'intero ciclo di vita di un'applicazione, dalla progettazione e
implementazione alla distribuzione e alle operazioni.
➤ La piattaforma Azure offre protezione da varie minacce, ad esempio intrusioni di rete e
attacchi DDoS.
➤ È tuttavia necessario implementare la sicurezza nell'applicazione e nei processi DevOps
(DevSecOps).
35. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Sicurezza
➤ La sicurezza è uno degli aspetti essenziali di qualsiasi architettura. Offre garanzie di
riservatezza, integrità e disponibilità contro attacchi intenzionali e uso improprio di dati e
sistemi importanti.
➤ La perdita di queste garanzie può influire negativamente sulle operazioni e sui ricavi
aziendali e sulla reputazione dell'organizzazione.
➤ Per l'elemento fondamentale della sicurezza, verranno illustrati i principi e le considerazioni
chiave sull'architettura per la sicurezza e il modo in cui si applicano ad Azure.
39. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Ottimizzazione dei costi
➤ Quando si progetta una soluzione cloud, concentrarsi sulla generazione anticipata di valore
incrementale.
➤ Applicare i principi di creazione-misurazione-apprendimento per accelerare il time-to-market
evitando soluzioni a esborso intensivo di capitali.
40. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Ottimizzazione dei costi
➤ Il pilastro dell'ottimizzazione dei costi fornisce principi per il bilanciamento degli obiettivi
aziendali con una giustificazione del budget per creare un carico di lavoro conveniente
evitando soluzioni a elevato utilizzo di capitale.
➤ L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e
migliorare l'efficienza operativa.
➤ Ogni scelta di progettazione ha implicazioni in termini di costi.
➤ Prima di scegliere un modello architetturale, un servizio di Azure o un modello di prezzo per
il servizio, prendere in considerazione i vincoli di budget impostati dall'azienda.
➤ Come parte della progettazione, identificare limiti accettabili su scala, ridondanza e
prestazioni rispetto ai costi.
41. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Ottimizzazione dei costi
➤ Considerare il monitoraggio e l'ottimizzazione dei costi come un
processo, anziché come un'attività temporizzazione.
➤ Eseguire revisioni dei costi regolari e misurare e prevedere le
esigenze di capacità in modo da poter effettuare il provisioning
delle risorse in modo dinamico e ridimensionare in base alla
domanda.
➤ Esaminare le raccomandazioni di gestione dei costi e intervenire
per ottimizzare i costi del carico di lavoro.
42. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Eccellenza Operativa
➤ L'eccellenza operativa riguarda le operazioni e i processi che mantengono un'applicazione in
esecuzione nell'ambiente di produzione. Le distribuzioni devono essere affidabili e
prevedibili.
➤ Automatizzare le distribuzioni per ridurre la probabilità di errori umani.
➤ I processi di distribuzione veloci e di routine non rallentano il rilascio di nuove funzionalità o
correzioni di bug.
➤ Altrettanto importante, è necessario eseguire rapidamente il rollback o il roll forward se un
aggiornamento presenta problemi.
43. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Eccellenza Operativa
➤ Il pilastro dell'eccellenza operativa riguarda i processi operativi che mantengono
un'applicazione in esecuzione nell'ambiente di produzione.
➤ Le distribuzioni devono essere affidabili e prevedibili.
➤ Le distribuzioni automatizzate riducono la probabilità di errori umani ed aumentano la
velocità con cui effettuare il rilascio di nuove funzionalità o correzioni di bug o l’esecuzione
di un rollback.
➤ Meccanismi di self-healing sono necessari per rendere l’automatismo realmente affidabile.
45. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi per
soddisfare le esigenze poste dagli utenti in modo efficiente.
➤ I modi principali per ottenere l'efficienza delle prestazioni includono l'uso appropriato della
scalabilità e l'implementazione di offerte PaaS con scalabilità incorporata.
46. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ Comprendere le problematiche delle architetture distribuite
➤ La maggior parte delle distribuzioni cloud si basa su architetture distribuite in cui i
componenti vengono distribuiti tra vari servizi.
➤ La risoluzione dei problemi delle applicazioni monolitiche richiede spesso solo uno o due
obiettivi, ovvero l'applicazione e il database.
➤ Con le architetture distribuite, la risoluzione dei problemi è complessa e complessa a causa
di diversi fattori.
47. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ Due modi principali per ridimensionare un'applicazione: il ridimensionamento verticale e il
ridimensionamento orizzontale.
➤ Il ridimensionamento verticale (aumento della scalabilità) aumenta la capacità di una risorsa,
ad esempio usando una macchina virtuale (VM) di dimensioni maggiori.
➤ Il ridimensionamento orizzontale (scalabilità orizzontale) aggiunge nuove istanze di una
risorsa, ad esempio macchine virtuali o repliche di database.
48. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ La scalabilità orizzontale offre vantaggi significativi rispetto al ridimensionamento verticale, ad
esempio:
➤ Scalabilità cloud-native: le applicazioni sono progettate per l'esecuzione su centinaia o persino
migliaia di nodi, raggiungendo scale che non sono possibili in un singolo nodo.
➤ La scalabilità orizzontale è elastica: è possibile aggiungere altre istanze se il carico aumenta o
rimuovere istanze durante i periodi più brevi.
➤ La scalabilità orizzontale può essere attivata automaticamente, in base a una pianificazione o in
risposta alle variazioni del carico.
➤ La scalabilità orizzontale può essere più economica rispetto alla scalabilità verticale. L'esecuzione di
diverse macchine virtuali di piccole dimensioni può costare meno di una singola macchina virtuale
di grandi dimensioni.
➤ La scalabilità orizzontale può anche migliorare le resilienza aggiungendo la ridondanza. Se si arresta
un'istanza, l'applicazione continua a funzionare normalmente.
49. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ La scalabilità orizzontale deve però essere progettata nel sistema.
➤ Oltre che dall’applicazione, nel cloud la possibilità di sfruttare la scalabilità dipende
dall'infrastruttura e dai servizi, con opzioni diverse nelle diverse soluzioni IaaS e PaaS.
50. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Efficienza delle prestazioni
➤ Stabilire linee di base delle prestazioni — Determina l'efficienza corrente dell'applicazione e della
relativa infrastruttura di supporto. La misurazione delle prestazioni rispetto alle baseline può offrire
strategie per miglioramenti e determinare se l'applicazione sta per raggiungere gli obiettivi
aziendali.
➤ Eseguire test di carico e stress — I test di carico misurano le prestazioni dell'applicazione in
quantità predeterminate di carico. I test di stress misurano il carico massimo che l'applicazione e la
relativa infrastruttura possono supportare prima che si allaccia.
➤ Identificare i colli di bottiglia — I colli di bottiglia sono un'area all'interno dell'applicazione che può
ostacolare le prestazioni. Questi punti possono essere il risultato di una mancanza di codice o di
una configurazione errata di un servizio. In genere, un collo di bottiglia peggiora con l'aumentare
del carico.
51. AZURE WELL-ARCHITECTED FRAMEWORK –
INTRODUZIONE
➤ Mettere insieme i cinque pilastri
➤ Affidabilità
➤ Sicurezza
➤ Ottimizzazione dei costi
➤ Eccellenza operativa
➤ Efficienza delle prestazioni
Azure Well-Architected Framework è una serie di principi guida utilizzabili per migliorare la qualità dei carichi di lavoro. Il framework è costituito da cinque elementi fondamentali dell'eccellenza dell'architettura:
Affidabilità - La capacità di un sistema di correggere gli errori e continuare a funzionare.
Sicurezza - Protezione delle applicazioni e dei dati dalle minacce.
Ottimizzazione dei costi - Gestione dei costi per massimizzare il valore offerto.
Eccellenza operativa - Processi operativi che mantengono un sistema in esecuzione in produzione.
Efficienza delle prestazioni - La capacità di un sistema di adattarsi ai cambiamenti di carico.
L'integrazione di questi elementi fondamentali consente di produrre un'architettura cloud di alta qualità, stabile ed efficiente:
Il Cloud offre diverse piattaforme, esistono quindi diversi modi di approcciare l’adozione del cloud per le varie soluzioni già in essere
Il Cloud offre diverse piattaforme, esistono quindi diversi modi di approcciare l’adozione del cloud per le varie soluzioni già in essere
Come orientarsi nella scelta su quale approccio verso il cloud seguire per ogni applicazione? Il valore di business diventa la chiave della valutazione, insieme alla complessità per la trasformazione
Un grado ancora maggiore di revisione è “Re-Architect” in cui si ripensa da zero la soluzione per realizzarla nuovamente secondo I principi cloud native.
Automatizzato – Ripetibile – Affidabile: queste sono le parole chiave di una soluzione CI/CD
Le linee guida:
Un manufatto per tutti gli ambienti: Non creare build diverse per ambienti diversi
Un processo per tutti gli ambienti: Non creare pipeline diverse per ambienti diversi
Ripara e non aggirare: Se un passaggio fallisce, deve essere corretto e mai aggirato
Niente al di fuori del repository: Il repository è l'unica fonte completa di verità
Più è complesso, più frequentemente deve essere affrontato: Le attività complesse diventano complicate se eseguite di rado
PET model
Management of each individual element of your infrastructure
Goals: each server part of your infrastructure should be available 24/7
CATTLE model
Manager of the overall infrastructure considering each element as disposable
Goals: solution\service uptime, considering that single elements will go down and will be destroyed and replaced
Movimento nato tra il 2008 e il 2009 (Patrick Dubois and Andrew Schafer) e poi cresciuto negli anni successivi. Nel 2011 inserito da Gartner nelle sue predizioni.
Negli stessi anni Google sviluppava la metodologia SRE separatametne ma coerentemente con i principi DevOps.
Principi SRE e DevOps
Distributed systems are difficult to monitor
Each system and application can provide a large amount of information about its status
Different information from the same system can be correlated
Traces reporting higher response time + Metrics reporting high CPU usage
Different information from different systems can be correlated
Traces from web application reporting high error rate + Logs from database system reporting high occurrence of deadlocks
Numerosi strumenti di sicurezza in Azure, ma anche pratiche per l’utilizzo di strumenti comuni
Responsabilità condivise in cloud
Un approccio DevSecOps
Scegliere le risorse giuste allineate con gli obiettivi aziendali e in grado di gestire le prestazioni del carico di lavoro. Un servizio non appropriato o non configurato correttamente può influire sui costi. Ad esempio, la creazione di un servizio in più aree quando i livelli di servizio non richiedono disponibilità elevata o la ridondanza geografica aumenterà i costi senza alcuna giustificazione aziendale ragionevole.