Questo documento nel framework dell'architettura Google Cloud descrive i principi fondamentali della progettazione del sistema. Una solida struttura del sistema è sicura, affidabile, scalabile e indipendente. Consente di apportare modifiche iterative e reversibili senza interrompere il sistema, ridurre al minimo i potenziali rischi e migliorare l'efficienza operativa. Per una solida progettazione del sistema, ti consigliamo di seguire quattro principi.
Progetta per il cambiamento
Nessun sistema è statico. Le esigenze degli utenti, gli obiettivi del team che crea il sistema e il sistema stesso cambiano continuamente. Con la necessità di cambiare, crea un percorso verso la produzione che consenta ai team di apportare regolarmente piccole modifiche e ricevere rapidamente feedback su queste modifiche. Dimostrare costantemente la capacità di eseguire il deployment delle modifiche è un modo per creare fiducia con gli stakeholder, inclusi i team responsabili del sistema e gli utenti del sistema. L'utilizzo delle metriche di distribuzione del software di DORA può aiutare il tuo team a monitorare la velocità, la facilità e la sicurezza associati alla modifica del sistema.
Documenta tutto
La documentazione è una parte fondamentale dello sviluppo del software. L'analisi di DORA ha trovato un chiaro collegamento tra la qualità della documentazione e le prestazioni dell'organizzazione, ovvero la capacità dell'organizzazione di raggiungere i propri obiettivi in termini di prestazioni e redditività.
Quando inizi a spostare i carichi di lavoro nel cloud o a creare le tue applicazioni, uno dei principali ostacoli al successo è la mancanza di documentazione del sistema. La documentazione è particolarmente importante per visualizzare correttamente l'architettura dei deployment attuali.
Un'architettura cloud adeguatamente documentata stabilisce un linguaggio e standard comuni, che consentono ai team interfunzionali di comunicare e collaborare in modo efficace. Fornisce inoltre le informazioni necessarie per identificare e guidare le decisioni di progettazione future. La documentazione deve essere scritta in base ai tuoi casi d'uso, in modo da fornire un contesto per le decisioni di progettazione.
Nel tempo, le tue decisioni di progettazione si evolveranno e cambieranno. La cronologia delle modifiche fornisce il contesto necessario ai tuoi team per allineare le iniziative, evitare duplicati e misurare le variazioni delle prestazioni in modo efficace nel tempo. I log delle modifiche sono particolarmente importanti quando si esegue l'onboarding di un nuovo Cloud Architect che non ha ancora familiarità con la progettazione, la strategia o la storia del sistema attuale.
Semplifica la progettazione e utilizza servizi completamente gestiti
La semplicità è fondamentale per la progettazione del sistema. Se la tua architettura è troppo complessa da capire, sarà difficile implementare la progettazione e gestirla nel tempo. Ove possibile, utilizza servizi completamente gestiti per ridurre al minimo i rischi, il tempo e l'impegno associati alla gestione e alla manutenzione dei sistemi di riferimento.
Se esegui già i tuoi carichi di lavoro in produzione, esegui dei test con i servizi gestiti per vedere come potrebbero aiutarti a ridurre le complessità operative. Se stai sviluppando nuovi carichi di lavoro, inizia in modo semplice, definisci un prodotto minimo funzionante (MVP) e resisti alla tentazione di un lavoro eccessivo. Puoi identificare casi d'uso eccezionali, eseguire l'iterazione e migliorare i tuoi sistemi in modo incrementale nel tempo.
Disaccoppia l'architettura
Una ricerca di DORA mostra che l'architettura è un importante fattore predittivo per ottenere la distribuzione continua. Il disaccoppiamento è una tecnica utilizzata per separare le applicazioni e i componenti di servizio in componenti più piccoli che possono operare in modo indipendente. Ad esempio, puoi separare uno stack di applicazione monolitica in singoli componenti di servizio. In un'architettura a basso accoppiamento, un'applicazione può eseguire le funzioni in modo indipendente, indipendentemente dalle varie dipendenze.
Un'architettura disaccoppiata offre maggiore flessibilità per:
- Applicare upgrade indipendenti.
- Applicare controlli di sicurezza specifici.
- Stabilire obiettivi di affidabilità per ogni sottosistema.
- Monitorare l'integrità.
- Controlla in modo dettagliato i parametri di costo e prestazioni.
Puoi iniziare il disaccoppiamento fin dalle prime fasi della fase di progettazione o incorporarlo negli upgrade del sistema durante la scalabilità.
Utilizzare un'architettura stateless
Un'architettura stateless può aumentare l'affidabilità e la scalabilità delle tue applicazioni.
Le applicazioni stateful si basano su varie dipendenze per eseguire le attività, ad esempio i dati memorizzati nella cache locale. Le applicazioni stateful spesso richiedono meccanismi aggiuntivi per acquisire i progressi e riavviarli senza problemi. Le applicazioni stateless possono eseguire attività senza dipendenze locali significative utilizzando l'archiviazione condivisa o i servizi memorizzati nella cache. Un'architettura stateless consente di fare lo scale up delle applicazioni con dipendenze di avvio minime. Le applicazioni possono resistere ai riavvii rigidi, avere tempi di inattività ridotti e offrire prestazioni migliori per gli utenti finali.
La categoria di progettazione del sistema descrive i suggerimenti per rendere le tue applicazioni stateless o per utilizzare funzionalità cloud-native per migliorare l'acquisizione dello stato delle macchine per le applicazioni stateful.
Passaggi successivi
- Seleziona le regioni geografiche per supportare le tue applicazioni aziendali.
- Gestione delle risorse cloud.
- Scegli e gestisci le risorse di computing.
- Progetta la tua infrastruttura di rete.
- Seleziona e implementa una strategia di archiviazione.
- Ottimizza il database.
- Analizza i dati.
- Implementa il machine learning.
- Progetta i tuoi carichi di lavoro cloud per la sostenibilità.