Per spiegare perché i team dedicati all'infrastruttura o alle applicazioni effettuano determinate attività di progettazione è possibile utilizzare i record decisionali dell'architettura (ADR). Questo documento spiega quando e come utilizzare le ADR durante la creazione e l'esecuzione delle applicazioni in Google Cloud.
Un ADR cattura le opzioni chiave disponibili, i requisiti principali che determinano e le decisioni di progettazione stesse. Spesso archivi le ADR in una Annotazione vicino al codebase pertinente alla decisione. Se qualcuno deve comprendere il background di una specifica decisione architetturale, ad esempio perché usa un cluster Google Kubernetes Engine (GKE) a livello di regione, esaminare l'ADR e poi il codice associato.
Le ADR possono anche aiutarti a eseguire applicazioni e servizi più affidabili. L'ADR ti aiuta a comprendere lo stato attuale e a risolvere eventuali problemi. Gli ADR creano anche una raccolta di decisioni ingegneristiche per supportare le scelte e i deployment futuri.
Quando utilizzare gli annunci dinamici della rete di ricerca
Utilizzi le ADR per monitorare le aree chiave che ritieni importanti per il tuo e deployment continuo. Gli ADR potrebbero contenere le seguenti categorie:
- Scelte di prodotti specifici, ad esempio la scelta tra Pub/Sub e Cloud Tasks.
- Opzioni e configurazioni specifiche del prodotto, ad esempio l'utilizzo di formati regionali di cluster GKE Ingress multi-cluster per applicazioni ad alta disponibilità.
- Linee guida generali sull'architettura, ad esempio le best practice per Dockerfile e i file manifest.
Alcuni esempi specifici che potrebbero richiedere la creazione di un ADR potrebbero essere le seguenti opzioni:
- Come e perché configurare l'alta disponibilità (HA) per le tue istanze Cloud SQL?
- Qual è la tua strategia per l'uptime dei cluster GKE? Usi a livello di regione? Utilizzi le release canary? Qual è il motivo?
Durante la valutazione dei prodotti da usare, l'ADR aiuta a spiegare ogni prendono le loro decisioni. Puoi rivedere l'ADR man mano che il team si evolve e apprende di più sulle e altre decisioni vengono prese o modificate. Se apporti modifiche, includere la decisione precedente e il motivo della modifica. Questa cronologia conserva un resoconto di come l'architettura è cambiata con l'evoluzione delle esigenze aziendali o dove sono presenti nuovi requisiti tecnici o soluzioni disponibili.
I seguenti prompt ti aiutano a capire quando creare le ADR:
- Se hai una domanda o un problema di natura tecnica e non di base per una decisione, ad esempio una soluzione consigliata, un'operazione procedura, progetto o codebase.
- Quando tu o il tuo team offrite una soluzione non documentata da qualche parte accessibile al team.
- Quando ci sono due o più opzioni tecniche e vuoi documentare la tua pensieri e motivi alla base della selezione.
Quando scrivi un ADR, è utile avere a mente i potenziali lettori. Il principale I lettori sono membri del team che si occupa della tecnologia coperta dall'ADR. Gruppi più ampi di potenziali lettori dell'ADR potrebbero includere team adiacenti che vuoi comprendere le tue decisioni, come l'architettura e i team di sicurezza.
Tieni inoltre presente che l'applicazione potrebbe cambiare proprietari o includere nuovi membri del team. L'ADR aiuta i nuovi collaboratori a comprendere il contesto del scelte tecniche che sono state fatte. Un ADR semplifica anche la pianificazione delle modifiche future.
Formato di un ADR
Una tipica funzione ADR include una serie di capitoli. Le ADR dovrebbero aiutarti a capire che ritieni importante per l'applicazione e la tua organizzazione. Alcune ADR potrebbero su una pagina, mentre altre richiedono una spiegazione più lunga.
Il seguente esempio di riassunto ADR mostra come puoi formattare un ADR in modo da includere le informazioni importanti per il tuo ambiente:
- Autori e team
- Contesto e problema da risolvere
- Requisiti funzionali e non funzionali da soddisfare
- Potenziale percorso critico dell'utente (CUJ) influenzato dalla decisione
- Panoramica delle opzioni principali
- La tua decisione e i motivi alla base della scelta accettata
Per tenere traccia delle decisioni, puoi includere un timestamp per ogni decisione per indicare quando è stata effettuata la scelta.
Come funzionano le ADR
Gli ADR funzionano al meglio quando ingegneri, sviluppatori o proprietari di applicazioni possono accedere facilmente alle informazioni in essi contenute. Quando il cliente vuole sapere perché se qualcosa viene fatto in un certo modo, possono esaminare l'ADR per trovare la risposta.
Per rendere accessibile l'ADR, alcuni team lo ospitano in un wiki centrale che accessibili ai proprietari delle attività, invece che nel loro repository di controllo del codice sorgente. Quando qualcuno ha una domanda su una specifica decisione di progettazione, l'ADR viene disponibili per fornire risposte.
Le ADR funzionano bene nei seguenti scenari:
- Operazioni preliminari: i nuovi membri del team possono ottenere facilmente informazioni sul progetto e possono rivedere l'ADR se hanno domande durante l'apprendimento codebase.
- Evoluzione dell'architettura: in caso di trasferimento dello stack tecnologico tra i team, i nuovi proprietari possono rivedere le decisioni passate per comprendere lo stato attuale. Il team può anche rivedere le decisioni passate in caso di nuove la tecnologia a loro disposizione. L'ADR può aiutare i team a evitare la ripetizione gli stessi punti di discussione e può aiutare a fornire un contesto storico i team rivedono gli argomenti.
- Condivisione delle best practice: i team possono allinearsi alle best practice dell'intera organizzazione quando gli ADR descrivono nel dettaglio il motivo per cui sono state prese determinate decisioni e perché sono state escluse le alternative.
Un ADR è spesso scritto in Annotazione per mantenerlo leggero e basato su testo. I file Markdown possono essere inclusi nel repository di controllo del codice sorgente con il codice dell'applicazione.
Archivia gli ADR vicino al codice dell'applicazione, idealmente nella stessa versione di controllo qualità. Man mano che apporti modifiche all'ADR, puoi esaminare le versioni precedenti dal controllo del codice sorgente, se necessario.
Puoi anche utilizzare un altro mezzo, ad esempio un documento Google condiviso o una wiki interna. Queste località alternative potrebbero essere più accessibili per gli utenti che non fanno parte del di ADR. Un'altra opzione è creare l'ADR in un repository di controlli del codice sorgente, ma il mirroring delle decisioni chiave in un wiki più accessibile.
Passaggi successivi
- La Centro architetture cloud e ai Framework dell'architettura forniscono indicazioni e best practice aggiuntive.
- Per alcune aree che potrebbero essere incluse nell'ADR, consulta Pattern per app scalabili e resilienti.