Gli esempi in questa pagina mostrano alcuni scenari ipotetici che utilizzano parchi risorse che illustrano alcuni dei concetti e delle best practice delle nostre guide. Prima di leggere questa guida, dovresti acquisire familiarità con i concetti descritti nella sezione Introduzione ai parchi risorse e con Best practice e requisiti del parco risorse.
Esempio 1: parchi risorse con risorse di produzione, gestione temporanea e sviluppo
In questo primo esempio, sono presenti quattro cluster. Due cluster sono per la produzione (in due regioni per la ridondanza), uno per la gestione temporanea e i test e l'ultimo per lo sviluppo. Tutti i cluster sono di proprietà e amministrati
a livello centrale da un team della piattaforma. In questo semplice esempio, sono disponibili due servizi:
frontend e backend. Tuttavia, scenari più complessi potrebbero avere
un numero maggiore sia di servizi che di cluster.
Approccio 1: parchi risorse separati per produzione, gestione temporanea e sviluppo
Un possibile approccio per sfruttare i parchi risorse è creare parchi risorse separati per le risorse di produzione, gestione temporanea e sviluppo.
A questo scopo, creiamo tre progetti host del parco risorse separati e inseriamo le risorse in tali progetti oppure, nel caso del nostro cluster di sviluppo on-premise, registriamo il cluster nel progetto example-dev. Non abbiamo dovuto
risolvere molti dei problemi relativi all'identicità dello spazio dei nomi e dei servizi a causa della
granularità in questo esempio, ma ci siamo assicurati che gli spazi dei nomi dei cluster prod-east e
prod-west fossero ben normalizzati.
Il vantaggio di questo approccio è che abbiamo un isolamento molto forte tra ciascuno dei parchi risorse. Lo svantaggio principale di questo approccio è che dobbiamo amministrare tre diversi parchi risorse, il che rende più difficile raggiungere una coerenza tra produzione, gestione temporanea e sviluppo. Inoltre, per i team di sviluppo è più difficile sviluppare i prodotti per i servizi temporanei.
Approccio 2: un unico parco risorse per tutte le risorse
Con questo approccio, creiamo un unico parco risorse per tutte le risorse.
Per farlo, possiamo lasciare le risorse nel progetto example e creare il parco risorse al suo interno. Avremmo potuto separare le risorse di produzione e di gestione temporanea inserendole in altri progetti host del parco risorse e sfruttando il VPC condiviso, ma per semplicità abbiamo scelto di non farlo in questo esempio.
Con questo approccio, dobbiamo assicurarci che i nostri spazi dei nomi e servizi siano normalizzati in tutto il parco risorse. Ad esempio, rinominiamo il nostro frontend generico in frontend-prod e frontend-staging rispettivamente nei cluster di produzione e di gestione temporanea. Infine, anche se potremmo mantenere i nomi originali per gli spazi dei nomi di sviluppo, forniamo nomi più chiari (come frontend-dev-alice) per indicare che si tratta di spazi dei nomi di sviluppo.
Con questo approccio, confrontiamo l'isolamento per semplificare la gestione. Ci affidiamo all'autorizzazione del mesh di servizi per evitare comunicazioni indesiderate tra servizi, ma possiamo facilmente amministrare l'intero sistema con l'unico parco risorse. Questo accordo ci permette di applicare criteri a tutte le risorse, il che può darci la certezza che lo sviluppo sembra molto vicino alla produzione.
Approccio 3: parchi risorse separati per la produzione e non per la produzione
In questo approccio, adottiamo una via di mezzo che combina le risorse di gestione temporanea e di sviluppo in un parco risorse non di produzione, posizionando la produzione in un parco risorse separato.
A questo scopo, creiamo due progetti host del parco risorse, uno per la produzione e uno per quelli non di produzione. Inoltre, inseriamo le nostre risorse direttamente in quei progetti, con il cluster dev on-premise registrato nel nostro parco risorse non di produzione. Dobbiamo normalizzare gli spazi dei nomi e i servizi tra le nostre risorse di gestione temporanea e di sviluppo per fare chiarezza; ad esempio, rinominiamo frontend in frontend-staging nel cluster di gestione temporanea.
Il vantaggio in questo caso è che la produzione è ben separata da quella non di produzione. Ad esempio, possiamo consentire ai servizi di sviluppo di comunicare con i servizi di gestione temporanea, in modo che la frontend della sviluppatore Alice possa parlare con un backend in modalità temporanea mentre lei sviluppa il suo servizio.
Riepilogo
Ciascuno degli approcci descritti nell'Esempio 1 è valido. La scelta della tua organizzazione dipende dall'isolamento rispetto alla coerenza (e dalla facilità di gestione). In altre parole, la quantità di isolamento necessaria tra tipi diversi di risorse e la relativa coerenza è necessaria tra loro. È più facile ottenere una maggiore coerenza con meno parchi risorse. Il terzo approccio viene proposto come possibile compromissione, mantenendo la produzione completamente isolata e offrendo al contempo agli sviluppatori la possibilità di lavorare su servizi in fasi.
Esempio 2: parchi risorse con proprietari di risorse diversi
Per questo esempio, abbiamo due team, team-a e team-b. Questi team possiedono e amministrano i propri cluster ed entrambi hanno utilizzato gli spazi dei nomi frontend e backend per i servizi che producono. Tuttavia, né i valori frontend né backend di team-a sono in realtà uguali a quelli di team-b. I due team vogliono creare un mesh di servizi in modo che i servizi possano interagire.
Senza un intervento, non è possibile includere questi cluster nella stessa rete mesh. Un buon punto di partenza è trasferire la proprietà dei cluster a un team della piattaforma centralizzata per stabilire una fiducia tra i cluster. In alternativa, se il team a e il team B si fidano l'uno dell'altro, possono coordinarsi per creare questa fiducia.
Il passaggio successivo consiste nel normalizzare l'utilizzo dello spazio dei nomi in modo che frontend e backend non siano più sovraccarichi nei cluster di questi due team. Al termine, possono creare un unico parco risorse per tutte le risorse e creare il proprio mesh di servizi.
Se non è possibile stabilire questo livello di attendibilità, team-a e team-b devono formare due parchi risorse separati che utilizzano due progetti host del parco risorse diversi. Lo svantaggio di questo approccio è che ora devono sfruttare la federazione dei mesh, che è più difficile da amministrare rispetto a un singolo mesh. Il vantaggio è che nessuno dei due team deve normalizzare gli spazi dei nomi e i servizi di cui è stato eseguito il deployment, perciò è possibile solo una comunicazione esplicita e specificamente autorizzata.
