Kubernetes non deve diventare un volo alla cieca.

Prima di scegliere la piattaforma, valutiamo quali applicazioni debbano essere accolte e quali esigenze abbiano i team. Come vengono distribuite oggi le nuove versioni? Quali dati devono restare disponibili in modo permanente? Chi si occupa delle modifiche alla piattaforma? Queste domande aiutano a delimitare l'ambito necessario. Kubernetes può avere senso, ma deve essere adeguato alle applicazioni e alle competenze disponibili. Una decisione basata soltanto su una tecnologia desiderata non chiarirebbe ancora l'impegno organizzativo e tecnico aggiuntivo.

Le varianti adeguate vengono quindi valutate anche in base alla ripartizione dei compiti. Con un servizio gestito resta da chiarire quali lavori su applicazione, configurazione e dati restino comunque necessari. Lo scenario target indica queste attività a vostro carico e stabilisce quali di esse OTOKO® assume nell'ambito dell'incarico. Un'applicazione pilota rappresentativa rende tangibili i requisiti. Su di essa si può verificare se la struttura scelta e le procedure previste soddisfino effettivamente le aspettative, prima che si aggiungano altri team o applicazioni.

Un team ha bisogno di qualcosa di più del semplice accesso al cluster. Deve sapere dove può lavorare, come vengono assegnate le risorse e quali approvazioni valgono per una modifica in produzione. Queste basi vengono allestite insieme e collegate al percorso di distribuzione. Immagini container, verifiche e versione desiderata devono corrispondere in modo tracciabile. L'attuazione concreta segue le vostre applicazioni e gli strumenti esistenti; le procedure già funzionanti vengono integrate nello scenario target per quanto opportuno.

La prima release viene eseguita insieme. In questa fase verifichiamo non solo l'avvio riuscito, ma anche la comprensibilità della procedura: i messaggi di errore sono attribuibili, l'approvazione è univoca e sviluppo e gestione operativa sanno quando devono intervenire? Anche i casi di errore concordati e i percorsi di rollback vengono discussi o testati. La documentazione così ottenuta deve supportare le release successive. Il vostro team riceve così un metodo di lavoro utilizzabile e non soltanto un ambiente tecnico il cui utilizzo andrebbe scoperto solo in seguito.

I container possono essere ridistribuiti, ma i dati associati e i servizi collegati richiedono procedure proprie. Consideriamo insieme quali informazioni devono restare disponibili in modo permanente e come viene verificato il loro ripristino. Ne fa parte anche la sequenza con cui applicazione e dati tornano utilizzabili. Una procedura di backup deve quindi essere adeguata all'applicazione reale. I compiti vengono assegnati in modo esplicito, affinché non nasca involontariamente una lacuna tra la gestione della piattaforma e la responsabilità sull'applicazione.

Anche gli aggiornamenti della piattaforma richiedono preparazione e coordinamento. Dipendenze, possibilità di test e approvazioni necessarie vengono descritte nella procedura operativa. Monitoraggio e canali di notifica stabiliscono come i problemi vengono individuati e trasmessi ai soggetti giusti. In caso di assistenza continuativa, l'ambito dei servizi indica quali compiti di piattaforma e di gestione operativa siano coperti e quali restino ai vostri team. Questa delimitazione facilita l'inserimento consapevole di nuovi requisiti in seguito e una pianificazione realistica del lavoro necessario sulla piattaforma.