Scenario 1 - Ridimensionamento globale e accesso sicuro dell'architetto
Nelle due unità seguenti si esamineranno due scenari aziendali. Le descrizioni della società, gli obiettivi del progetto e i vincoli sono già stati disposti per l'utente. È possibile lavorare al progetto in autonomia, ma potrebbe essere interessante condividerlo con altri utenti per uno scambio di opinioni e idee, se possibile.
Processo per lo sviluppo di soluzioni
L'obiettivo, in questi scenari e probabilmente nel mondo reale, è comprendere quanto segue:
- Il problema che deve essere risolto dall'azienda.
- Tutti i requisiti e i vincoli associati a una soluzione.
Questo obiettivo assume spesso la forma di dichiarazione del problema. Si tratta di una serie formale di paragrafi che definiscono chiaramente le circostanze, la condizione attuale e i risultati desiderati per una soluzione. In questa fase è meglio evitare di analizzare come risolvere il problema e concentrarsi su ciò che si vuole risolvere.
Dopo aver concordato una dichiarazione del problema (probabilmente con il proprio team e altri stakeholder), è consigliabile estrapolare tutti i requisiti (obiettivi) trovati per il progetto. Definire quindi anche gli eventuali vincoli per la soluzione.
A questo punto, è accettabile avere vincoli non realistici. È possibile rivalutarli in un secondo momento, dopo aver esaminato il rapporto costi/benefici per ogni requisito e vincolo.
In produzione sono normalmente previste sei fasi per la creazione di una soluzione. L'elaborazione della dichiarazione del problema è solo l'inizio.
- Individuazione: dichiarazione originale del problema dal cliente.
- Definizione: descrizione "creativa" degli elementi che rappresentano un esito positivo del progetto. Spesso formulata con dichiarazioni del tipo "È possibile...".
- Sessione di progettazione dell'architettura: individuazione iniziale delle opzioni e delle scelte tecnologiche per una soluzione preliminare.
- Modello di verifica (POC): dopo aver selezionato le tecnologie e i processi ottimali della soluzione, viene configurato un modello di verifica con un piccolo esempio rappresentativo della soluzione. Se è disponibile una soluzione attualmente in esecuzione in un esempio parallelo, è possibile usarla.
- Implementazione: piano di implementazione graduale della soluzione completata in base ai risultati delle fasi precedenti.
- Handoff: analisi a posteriori del progetto con una discussione sui miglioramenti futuri.
In questo modulo è possibile sfruttare i vantaggi dei modelli di progetto e le icone più recenti. Questi asset possono essere usati anche nei carichi di lavoro di produzione.
Per gli scenari di questo modulo, sarà necessario dedicare un po' di tempo a definire la dichiarazione del problema (fase di individuazione). Tuttavia, gran parte del lavoro sarà incentrata sulla sessione di progettazione dell'architettura. Se si vuole sviluppare ulteriormente una soluzione dopo il completamento del modulo, è possibile usare gli asset nel modulo a tale scopo.
Dettagli dello scenario
Il cliente è un provider di servizi e distribuzione di contenuti in tutto il mondo. Ha richiesto assistenza nella progettazione di un sistema in grado di gestire migliaia di scritture al secondo in quello che è fondamentalmente un data mart operativo.
Il cliente ha anche la necessità di eseguire analisi in tempo reale sui dati, per determinare le tendenze e identificare le anomalie. Attualmente per questi scopi vengono usate applicazioni CLR (Common Language Runtime). Quello che cerca il cliente non è un data warehouse e usare grandi parti della superficie di SQL, ma la possibilità di estendere i servizi alla posizione in cui risiedono gli utenti.
Il cliente vuole anche stabilire quali metodi di autenticazione usare nel proprio ambiente ibrido. Sebbene la soluzione e l'applicazione principali risiedano in Azure, il cliente ha anche l'esigenza di gestire:
- Un'applicazione in un computer non Azure aggiunto a un dominio.
- Un'applicazione legacy che non consentirà la modifica del driver o della stringa di connessione in un computer non Azure.
- Più utenti che eseguono report da strumenti di amministrazione SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) in computer non Azure non aggiunti a un dominio.
Laddove possibile, il cliente vuole evitare password o segreti hardcoded nelle stringhe di connessione e nei file di configurazione delle app. Vuole anche evitare l'uso delle password negli strumenti SQL o trovare un modo per migliorare questa autenticazione.
Indicazioni sullo scenario
- Iniziare con l'opzione di distribuzione di SQL di Azure più compatibile con la soluzione corrente e attualmente disponibile.
- In che modo il cliente potrà estendere il servizio su più aree con più query eseguite contemporaneamente, isolando al tempo stesso i carichi di lavoro di lettura da quelli di scrittura?
- In che modo il cliente può accedere ai dati nelle varie distribuzioni?
- Quali metodi di autenticazione sono consigliabili per i percorsi di interazione descritti nello scenario?
Attività
Dopo aver esaminato lo scenario e le linee guida fornite, è ora di estrarre tutti i requisiti trovati per il progetto.
Elencare le tecnologie e i processi possibili che potrebbero essere usati in una soluzione. È possibile adattare lo scenario in modo da ottenere altre informazioni laddove si vuole ottenere maggiore chiarezza. In questo caso è possibile fare ipotesi.
Suggerimento
Per affrontare le problematiche correlate alla sicurezza, è consigliabile sfruttare il playbook delle procedure consigliate per la sicurezza di SQL di Azure.
Usando una matrice decisionale o un altro processo decisionale, selezionare tecnologie e processi che costituiranno la soluzione preliminare.
Prendere nota dei vari risultati per presentare gli obiettivi e i vincoli del progetto, nonché la progettazione della soluzione consigliata.
Dopo aver ideato una soluzione preliminare, il passaggio successivo è spesso quello di presentarlo agli altri membri del team o al cliente, alla dirigenza e così via, a seconda dello scenario. È necessario assemblare e presentare la soluzione in modo da condividere gli obiettivi e i vincoli del progetto, nonché il modo in cui la soluzione affronta tali elementi.
Quando si è pronti, rispondere alle domande seguenti per valutare la soluzione a confronto con una soluzione di esempio. Possono esistere più risposte corrette, quindi anche se la soluzione non è elencata, potrebbe essere appropriata.