problema
soluzione
Sprint Computer Services è il più grande fornitore italiano al servizio del ciclo di vita dell'hardware: IT Asset recovery, IT Recycling, data security, parti di ricambio. In un anno serve oltre 3.000 clienti con 20.000 cancellazioni sicure utilizzando software certificato e con processo controllato e 45.000 server, desktop e laptop rigenerati. Tutti i processi sono gestiti nel rispetto delle numerose certificazioni che Sprint ha conseguito (ISO 9001 e 14001, OHSAS 18001).
Sprint utilizza diverse applicazioni su misura per le sue esigenze specifiche, molte sviluppate direttamente da COSA, oltre ad alcuni software commerciali specifici. Tutti questi strumenti richiedono un’infrastruttura hardware molto ampia e onerosa da gestire e manutenere, e complessa da mantenere in sicurezza e accessibile continuamente sia dagli utenti interni che da quelli esterni.
La migrazione su AWS è avvenuta in varie fasi successive per semplificare i test e limitare i downtime necessari al passaggio fisico dei dati. Abbiamo cominciato migrando e/o reindirizzando i domini usando Route 53.
La prima fase vera e propria ha riguardato la migrazione dell’ERP custom, software monolitico che girava su una macchina virtuale on premise, e ora gira con il database PostgreSQL ospitato su AWS Aurora e l’applicazione su una EC2. Contestualmente, il modulo che gestisce le API private per le altre applicazioni interne è stato riscritto come Lambda function in node.js e reso accessibile tramite API Gateway.
Per la seconda e terza fase abbiamo fornito il supporto allo sviluppatore di alcune delle soluzioni interne. La seconda fase ha riguardato la migrazione di alcune applicazioni minori interne, migrando prima i database su AWS Aurora MySQL Serverless e poi ottimizzando l’infrastruttura delle macchine virtuali utilizzando S3 per lo storage e vari docker in sostituzione delle VM on premise. Per alcune vecchie applicazioni PHP abbiamo fornito supporto allo sviluppatore per la riconversione a serverless (AWS Lambda, API Gateway, Aurora MySQL Serverless). La terza fase ha riguardato la migrazione di Up2doc, altra applicazione PHP legacy, spostando sempre prima il database su AWS Aurora e poi modificando e ottimizzando l’applicazione che ora gira su Lambda.
Tra una fase e l’altra abbiamo fatto passare una settimana per poter monitorare il traffico ed eventuali problemi (e non se ne è presentato alcuno) e ottimizzare le dimensioni delle EC2 in base al traffico effettivo. CloudWatch è stato uno strumento prezioso che ha permesso sia di dimensionare in maniera efficiente le risorse usate che di monitorare con un effort minimo tutta l’infrastruttura e notificare i rispettivi responsabili in caso di problemi.
Un’altro strumento che il cliente ha apprezzato molto è stato CloudTrail che abbiamo usato per l’auditing degli accessi all’intera infrastruttura.
Non abbiamo però finito: abbiamo già previsto alcuni sviluppi futuri, come l’ottimizzazione dei carichi di Elasticsearch e la migrazione dei siti web e degli ultimi strumenti software, prevalentemente open source, ancora rimasti on-premise.
La roadmap per proseguire la migrazione ad AWS è ancora in fase di definizione, i restanti servizi da migrare sono l’email aziendale, Active Directory e l’attuale servizio di condivisione dei files. Il cliente sta anche valutando la possibilità di una connessione AWS Direct Connect per veicolare tutto il traffico verso il datacenter AWS su linea dedicata.
Parliamone
Hai qualche progetto da proporci? Qualche idea da sottoporre? Lasciaci un po’ di dettagli e ti ricontatteremo il prima possibile. Più dettagli ci lasci, e meglio potremo risponderti.