AWS cresce. Il vostro controllo deve crescere di pari passo.

Un progetto pilota nasce spesso sotto pressione e con una cerchia di utenti limitata. Non appena si aggiungono altri team, però, gli accordi informali non bastano più. Le risorse devono essere assegnate, i diritti amministrativi verificati e i servizi comuni inquadrati. L'analisi dello stato attuale considera quindi gli account esistenti insieme ai progetti e alle persone che vi stanno dietro. In questo modo diventa visibile quali strutture sono state scelte consapevolmente, quali erano solo provvisorie e quali modifiche sono davvero necessarie prima di un'estensione su larga scala.

Lo scenario target descrive come vengono integrati i nuovi team e quali regole devono valere per gli account esistenti. Vengono considerate responsabilità, centri di costo e la separazione tra ambienti diversi. L'introduzione avviene in fasi concordate, in modo che le applicazioni in esercizio e le dipendenze esistenti restino incluse. Un primo caso d'uso concreto serve come verifica delle nuove procedure. In seguito il vostro team può valutare se provisioning, autorizzazioni e documentazione restano chiari e funzionano anche al di fuori del team pilota originario.

L'ambiente target di un'applicazione è spesso composto da più componenti con requisiti diversi. Potenza di calcolo, gestione dei dati, interfacce e accessi amministrativi devono essere considerati insieme. Valutiamo insieme una struttura adeguata e includiamo il futuro impegno operativo. In questo contesto restano rilevanti anche le competenze disponibili: una soluzione deve poter essere compresa, monitorata e modificata dai team previsti. L'ambito di una modernizzazione viene quindi deliberatamente separato dai compiti necessari in un primo momento per una transizione sicura.

Per la realizzazione vengono documentate dipendenze e verifiche. I team applicativi confermano il corretto funzionamento dell'applicazione, mentre i test tecnici verificano accessi, connessioni e la struttura operativa concordata. Se i sistemi locali continuano a essere necessari, i relativi percorsi di comunicazione rientrano nel collaudo. Il passaggio di consegne descrive inoltre come vengono introdotte le modifiche dopo il progetto e quale documentazione è disponibile per questo. In questo modo un workload aggiuntivo può essere integrato nell'infrastruttura AWS senza lasciare aperta la responsabilità al termine del trasferimento.

Una fattura in aumento può avere cause molto diverse: nuove applicazioni, un uso diverso, risorse sovradimensionate o ambienti che restano attivi più a lungo del necessario. Una semplice panoramica dei costi non mostra ancora quale modifica tecnica sarebbe opportuna. Per questo le spese vengono collegate a utilizzo e responsabilità. Nel dialogo con i team applicativi si chiarisce quali riserve sono previste consapevolmente e dove emerge effettivamente un consumo evitabile. Le misure nascono così dal contesto dell'applicazione.

Prima di una modifica vengono concordati i possibili effetti e la verifica necessaria. Dopo la realizzazione osserviamo l'utilizzo rilevato e gli effetti sulla gestione operativa. Non tutte le riduzioni tecnicamente possibili sono adatte a ogni workload. La documentazione registra quindi ipotesi e decisioni, in modo che ulteriori ottimizzazioni possano basarsi su di esse. Per l'assistenza continuativa vengono inoltre definiti canali di segnalazione, manutenzione e responsabilità; così le decisioni sui costi restano collegate alla responsabilità effettiva per i sistemi.