\ /
AWS 

AWS BOOTCAMP MIGRATION

Ciao a tutti , vi faccio un veloce RECAP di quanto è stato fatto all'AWS BOOTCAMP MIGRATION tenutosi il 28-29 Maggio in AWS Milano. Sostanzialmente è stato un corso a metà tra il tecnico e il cocenttuale. Più orientato a fornire un framework agile su come approcciare una migrazione massiva verso AWS piuttosto che un deep dive su tool o prodotti utilizzati per migrare.

  • Introduzione alla creazione del BUSINESS CASE

    • definire uno scopo del progetto
    • delimitarne il perimetro
    • definire i benefici non economici del progetto
    • definire i benefici ecomonici del progetto
    • utilizzano dei fogli excel "precompilati" che in base a delle assunzioni inserite, forniscono degli output/trend che mostrano i benefici economici. Noi quali partner non abbiamo accesso a questi excel-macro.

    1 FASE: MRA Migration Readiness Assessment

    • durata di una sola giornata , generalmente offerta gratuitamente da AWS al cliente
    • lo scopo è quello di fare un Assessmente di "alto livello" generico dell'attuale infrasttruttura del cliente
    • Devono essere presenti tutti gli stackolder del progetto con poteri decisionali: CIO, CISO, application owner, Operation Manager (quindi molto difficile da organizzare)
    • Si devono definire e discutere ad alto livello 8 tematiche: a) La landing Zone ( Region AWS, e le principali informazioni generali sull'infrasttruttura AWS a partire dal VPC ) b) I vincoli di security & Compliance in modo in modo da evitare di proporre soluzioni poi non avvallate dal CISO c) Business plan:esaminare attuali costi di gestione on-prem, valutare la bubble migration ovvero l'aumento di gestione dei costi durante la migrazioni in cui ci saranno due ambienti paralleli, i finali benefici della migrazione in cloud d) Definire gli skill richiesti e la creazione di un centro dell'eccellenza del cliente e) Condividere le esperienze di migrazioni f) Operating model attuale assieme alle applicazioni coinvolte e alle loro interdipendenze g) Piano di migrazione
      • Questo 8 tematiche vengono sviscerate in questa giornata attraverso un questionario di 69 domande che l'architetto AWS pone al cliente durante questo primo giorno di workshop. Il questionario è disponibile on-line, ma solo per dipendenti AWS. Forse ci gireranno un excel con le 69 domande per averne una visione. Viste le ampie tematiche, e per evitare di avere durante il progetto delle fasi di stallo dovute all'approvazione del cliente come detto sopra, tutto gli stackolder con potere decisionali devono essere coivolti.
      • Successivamente AWS si prende qualche giorno per elaborare i risultati ottenuti dal tool con le 69 domande, olte alle informazioni appresa durante la prima giornata e creano una presentazione in PowerPoint da inviare al cliente con le criticità che prima vanno assolutamente smarcate e risolte prima di partire con la migrazione ed un primo piano di migrazione ad alto livello

2 FASE MRP (Migration Readiness & Planning)

  • Viene proposta al cliente una fase di analisi e planning della attività qui sotto descritte
  • Discovery dettagliata dei server e delle applicazioni (AWS application discovery service ). Oppure terze parti come ATADATA, RISC NEtwork
  • Raggruppamento delle applicazioni per tipo, per produzione test o svil, eventuali dipendenze
  • Definizione dei limiti di sicurezza da rispettare
  • Definizione dei tempi di migrazione e di downtime da rispettare
  • Definizione dei tipi di migrazione possibili le 6R
    • retain --> non è possibile migrare in cloud
    • retire --> durante l'analisi di scopre che quella applicazione non è più in uso e va dismessa
    • repurchase --> l'applicazione è offerta in cloud come SaaS per cui va ricomprata in quella maniera
    • rehost --> il classico lift and shift (automatico tramite tools: AWS SMS o di terze parti Cloudendure, ATADATA, CloudVelox, Racimi)
    • replatform --> si indetifica una nuova platform sul cloud da utilizzare con una parte di modifica infrastrutturale
    • rearchitect or refactor --> l'applicazione va ridisegnata, risviluppata, integrate per essere portata in cloud (lavoro complesso)
  • Prediligere le cose semplici, per cui per prima cose valutare un rehost ed un replatform poi a fine progetto di migrazione si può aprire un progetto di optimization per abbattare di nuovo i costi tramite ottimizzazioni quali eventuali rearchitect
    • Definizione dei TEAM di progetto che possono essere di due tipi. Altamente specializzati in cui le risorse coivolte sanno mettere mano a tutte le componenti, oppore focalizzati su specializzazioni per cui ogni team sarà in grado di fare solo alcune determinate operazioni (sicurezza e rete , piuttosto che system engineer, piuttosto che application engineer). Di solito per ambienti medio-piccolo (secondo AWS sino a 250 server) si possono avere team divisi per expertise. Per migrazioni veramente massive oltre i 500 server, meglio team composti da "Reliability Engineer" ovvero persone che hanno tutti gli skill per cui i team lavarano in parallelo.
    • Definizione delle metodologie di migrazione in base al raggruppamento delle applicazioni. Per cui si dovranno definire i TEAM che si occuperanno del REHOST, quelli che si occuperanno del REPLATFORM, quelli che si occuperanno del RE-ARCHITECT (in questo caso dicevano va sempre coinvolta AWS per validare la configurazione), oltre ad un TEAM che coordina il progetto con un almeno un PM o in caso di progetti complessi un ProgramManager ed un paio di PM
    • Definizione dettagliata della landing Zone AWS
    • Definizione del customer center of excellence : il team composto esclusivamente da persone del cliente che durante tutto il progetto, seguendolo(toj) acquisiranno man mano skill sulla piattaforma cloud AWS per poterla amministrare (questo "cozza" un po con sorint che poi magari vorrebbe mantenerla anche tramite service Desk)
    • Definizione dettagliata del BUSINESS-CASE con TCO e ROI
    • Definizione delle QUICK-WINS. Ovvero individuare almeno 5 ambienti da migrare per primi come "pilot". I suggerimenti sono : a) selezionare un paio di ambienti facili come web-server b) selezionare almeno due ambienti critici/difficili da migrare ma magari in ambiente di test. In questo modo dimostriamo la capacità di migrare un ambiente complesso ma senza il rischio di toccare la produzione c) cercare quindi di diversificare gli ambienti di QUICK-WINS in modo da testare più tipi di migrazione d) il successo delle migrazione pilota può stimolare e dare un feedback positivo al cliente mostrando che si può procedere
    • Definire le sequnze di migrazioni suddividendole in SPRINT (un arco temporale breve tra i 5 ed i 10 giorni) e definire in ciascun sprint quale applicazioni/server verranno migrati
      • REITERARE sempre la seguenza di discovery/analisy/migrazione durante gli sprint (metodo agile)
      • Definire quindi il numero degli sprint con cui concludere il progetto, dando cosi una chiara visibilità al cliente su quanto durerà il progetto di migrazione e come evolverà MRP può durare sino a 2 o 3 mesi a seconda della complessità del progetto. Ovviamente queste fase è offerta da AWS a pagamento al cliente come investimento sulla migrazione per non avere intoppi. Potrebbe includere anche un pilot di migrazione scelto tra le quick-wins.

3 FASE MIGRAZIONE

  • In questa fase semplicemente , tramiti i team definitivi si iniziano le vere e proprie migrazioni sprint dopo sprint. Ovviamente è la fase più lunga e in caso di migrazioni massive oltre 250 server può cubare anche due o tre anni.

4 FASE OTTIMIZZAZIONE

  • Opzionale , di solito il cliente dopo un lavoro cosi lungo non tocca per un bel pò quello che funziona. Può in ogni caso essere proposta appunto come ottimizzazione della nuova struttura in cloud per avere maggiori benefici.

Dopo tutto la parte concettuale, ci sono stati proposti due esercizi. Il primo di gruppo. Ci hanno proposto un case study di un ipotetico cliente, il quale doveva migrare 250 server fornendoci alcune "assunzioni", un excel con la lista dei server e delle applicazioni e alcune raccomandazioni del CISO e del CEO. In due ore abbiamo dovuto proporre un piccola presentazione/planning tipica della FASE MRP e discuterla.

Il secondo progetto è stato fatto individualmente con la simulazione della migrazione su AWS di un ipotetico server fisico tramite AWS-Migration-Hub in accoppiata col software di CloudEndure.

Vi segnalo solo queste due cose tecniche

  • AWS application discovery services --> installi un agent sul tuo host linux o Windows e ogni 5 minuti pusha le informazioni di performance e di processi running sul migration hub di aws
    • AWS SMS Server migration services --> tool per la migrazione di macchine VM (vmware o hyperV) verso AWS. Richiede circa 2ore per migrare una VM. In caso si voglia lasciare appesa la syncronia il "delta" viene inviato solo ogni 12-24 ore. Per cui non è adatatto in caso di downtime limitati pochi minuti! Inoltre come vedete supporta solo virtual machine non server fisici. Inoltre non mi è stato ben chiarito cosa suggende in caso di VM con più VMDK....loro mi han fatto sempre solo vedere la migrazione di una VM monodisco (facile cosi....) Mi hanno segnalto altri prodotti che di solito usano quali CLOUDENDURE, ATADATA, RACIMI senza entrare nel dettaglio ma solo nominandoli
    • AWS DMS data migration services --> Utilizzato per la migrazione dei DB. Questo lo abbiamo visto in dettaglio il 2 Maggio con Oreste Dimaggio in sorint anche tramite esercizi.

Qualche immagine che descrive questo approccio alle migrazioni "agile"

https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/mig_1.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/mig_2.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/mig_3.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/mig_4.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/mig_5.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/6_r.png https://floatingpoint.sorint.it/storage/media/87688c7756e62267514133610879ed76/6r_2.png

Diego

comments powered by Disqus