Un’azienda tecnologica statunitense di call center aveva bisogno di modernizzare un’infrastruttura legacy autogestita in una piattaforma sicura cloud e DevOps. L’ambiente del cliente doveva supportare un delivery software rapido mantenendo governance, controllo degli accessi, osservabilità e requisiti di conformità SOC 2 coerenti tra sviluppo, produzione, servizi condivisi e workload on-premises.
HDWEBSOFT ha aiutato a progettare e implementare una piattaforma ibrida che ha collegato cluster AWS EKS, nodi datacenter on-premises a Las Vegas e DTLA, delivery GitOps, identità centralizzata, gestione dei segreti, automazione CI/CD e monitoraggio della sicurezza in un unico modello operativo auditabile.
Contesto del progetto
La piattaforma del cliente serviva operazioni di call center in cui affidabilità, sicurezza e velocità di delivery erano tutte importanti. Con la crescita del business, il modello di infrastruttura legacy è diventato più difficile da gestire in modo coerente, riflettendo i rischi di pianificazione, dipendenza e operatività comuni nella migrazione di workload legacy. I team avevano bisogno di un metodo più pulito per provisionare ambienti, controllare gli accessi, distribuire workload, monitorare gli incidenti e dimostrare che le modifiche all’infrastruttura erano deliberate e tracciabili.
L’obiettivo della modernizzazione non era solo spostare i workload nel cloud. L’obiettivo era creare una base di piattaforma ripetibile che potesse supportare migrazione legacy, modernizzazione di server autogestiti, operazioni basate su Kubernetes e delivery orientato alla conformità senza rallentare i team di engineering. Le esigenze di controllo SOC 2 hanno plasmato il design della piattaforma fin dall’inizio, inclusi logging centralizzato, identità governata, tagging coerente, modifiche all’infrastruttura auditabili e accesso tracciabile agli strumenti operativi.
Intervista agli stakeholder
“Questo progetto è stato impegnativo perché l’ambiente IT legacy non disponeva di documentazione sufficientemente affidabile. Prima di poter progettare il percorso di migrazione, abbiamo dovuto esaminare direttamente i server, raccogliere informazioni sul sistema operativo e sui pacchetti installati e comprendere quali servizi fossero effettivamente necessari per il software in esecuzione.”
— Duy Duong, Senior DevOps presso HDWEBSOFT
L’attività di scoperta è andata oltre la lettura di diagrammi o note di deployment. Il team ha ispezionato i server Linux legacy, raccolto inventari dei pacchetti installati, esaminato i servizi in esecuzione e mappato le dipendenze tra i componenti dell’infrastruttura e il comportamento dell’applicazione. Ogni pacchetto e servizio doveva essere valutato attentamente: se fosse necessario per i workload di produzione, se supportasse una dipendenza operativa o se creasse rischi di manutenzione e sicurezza non necessari.
Questa indagine ha contribuito a trasformare un ambiente autogestito poco chiaro in un piano di migrazione che i team di engineering, sicurezza e operazioni potessero esaminare. Ha anche ridotto il rischio di trasferire assunzioni non documentate nella nuova piattaforma cloud.
Funzionalità chiave
Base sicura di cloud ibrido
La piattaforma utilizzava AWS Organizations per separare gestione, servizi di piattaforma condivisi, sviluppo, produzione e archiviazione centralizzata dei log. Questa struttura ha aiutato il team a mantenere chiari i confini degli account supportando al contempo diverse esigenze operative tra gli ambienti.
I cluster Amazon EKS supportavano sviluppo, produzione e servizi di piattaforma condivisi. I workload di sviluppo utilizzavano una strategia di calcolo orientata ai costi, mentre la produzione si basava su capacità on-demand stabile con autoscaling basato su Karpenter. I servizi condivisi fungevano da hub di piattaforma per gli strumenti centralizzati.
La rete è stata progettata attorno a una connettività governata tra ambienti AWS e on-premises. La piattaforma utilizzava networking VPC, peering, Direct Connect, NAT gateway, flow log e baseline di sicurezza per supportare workload ibridi tra AWS e nodi datacenter.
Identità, accesso e gestione dei segreti
Okta fungeva da provider di identità centralizzato per gli strumenti di engineering e piattaforma. Federava l’accesso in AWS IAM Identity Center, GitHub, Grafana, Datadog, Vault, Rancher, Flux UI, Jenkins e strumenti di sicurezza degli endpoint.
HashiCorp Vault forniva gestione centralizzata dei segreti per ingegneri, pipeline CI/CD e workload Kubernetes. Vault girava in modalità alta disponibilità sulla piattaforma EKS dei servizi condivisi, mentre External Secrets Operator sincronizzava i segreti approvati nei namespace delle applicazioni.
La piattaforma utilizzava anche IAM Roles for Service Accounts per concedere autorizzazioni AWS granulari ai workload Kubernetes. Questo ha ridotto la necessità di credenziali ampie e ha reso l’accesso dei workload più facile da auditare.
Delivery delle applicazioni GitOps
FluxCD gestiva la riconciliazione continua da Git. La piattaforma utilizzava dipendenze Kustomization a livelli così che infrastruttura, segreti, applicazioni, osservabilità e componenti di sicurezza potessero essere distribuiti in un ordine controllato.
Flux Image Toolkit automatizzava gli aggiornamenti dei tag immagine per servizi selezionati. Questo ha aiutato i team a ridurre i passaggi di release manuali mantenendo il comportamento di deployment legato alle modifiche di source control revisionate.
I servizi principali della piattaforma includevano ingress, automazione DNS, gestione dei certificati, autoscaling, supporto WebRTC TURN, osservabilità e gestione multi-cluster. Insieme, questi servizi hanno fornito ai team applicativi un percorso coerente dal codice al runtime.
CI/CD ed esperienza sviluppatore
GitHub Actions utilizzava runner self-hosted sulla piattaforma EKS dei servizi condivisi. La capacità dei runner poteva scalare con la domanda, inclusa capacità orientata alle spot per un’esecuzione attenta ai costi.
I workflow OpenTofu supportavano operazioni di plan e apply per stack di infrastruttura. I commenti ai plan nelle pull request, il rilevamento programmato del drift e i segreti delle pipeline basati su Vault hanno contribuito a rendere le modifiche all’infrastruttura più visibili e deliberate.
Jenkins forniva orchestrazione centralizzata delle build, mentre Nexus gestiva l’archiviazione degli artefatti. Questo ha permesso alla piattaforma di supportare sia il delivery cloud-native moderno che i processi di build esistenti durante il percorso di modernizzazione.
Operazioni di osservabilità e sicurezza
Lo stack di osservabilità combinava Grafana, Loki, Alloy, Datadog e workflow di alerting. Questo ha fornito agli ingegneri una visione più chiara tra i livelli di infrastruttura cloud, Kubernetes e ibrida.
CrowdStrike Falcon endpoint protection era distribuito sui cluster EKS, mentre AWS GuardDuty aggiungeva rilevamento delle minacce lato cloud. Questi controlli hanno aiutato il cliente a rafforzare la propria postura di sicurezza soddisfacendo al contempo i requisiti di conformità SOC 2.
Sfide tecniche
Coordinare diversi livelli di automazione
La piattaforma coinvolgeva infrastructure as code, GitOps, configuration management, CI/CD, gestione dei segreti e automazione della sicurezza. Questi livelli dovevano collaborare tra diversi repository senza creare dipendenze nascoste o responsabilità poco chiare.
Governare ambienti multipli su larga scala
Sviluppo, produzione, servizi condivisi, logging centralizzato e account di gestione avevano ciascuno esigenze diverse. La sfida era mantenere accesso, tagging, controlli di rete, logging e regole di deployment coerenti senza rendere la piattaforma troppo rigida per i team di engineering.
Gestire operazioni di cloud ibrido
La modernizzazione includeva sia workload AWS che on-premises nel datacenter. Supportare EKS, Proxmox, cluster gestiti da Rancher e pattern operativi legacy richiedeva un’attenta integrazione tra networking cloud, identità, deployment e monitoraggio.
Ridurre il drift di documentazione e inventario
I sistemi legacy spesso creano drift tra ciò che è documentato e ciò che effettivamente gira. Il cliente necessitava di definizioni basate su Git, controlli automatizzati e provisioning ripetibile affinché la piattaforma potesse rimanere comprensibile mentre cambiava.
Bilanciare costo, affidabilità e stabilità
Il team doveva ottimizzare i costi di calcolo senza indebolire l’affidabilità di produzione. Questo richiedeva una strategia di capacità pratica tra workload orientati alle spot, capacità di produzione on-demand, regole di autoscaling e salvaguardie operative.
Supportare la conformità SOC 2 in condizioni di cambiamento rapido
La piattaforma doveva soddisfare i requisiti di conformità SOC 2 permettendo al contempo ai team di rilasciare rapidamente. Le modifiche all’infrastruttura, i flussi di accesso, l’utilizzo dei segreti e gli eventi operativi dovevano essere tracciabili e governati. La piattaforma necessitava anche di punti di evidenza coerenti per le audit, inclusa la cronologia delle modifiche, i record di controllo degli accessi, i log centralizzati e gli output del rilevamento del drift.
Soluzioni
Chiara separazione delle responsabilità
HDWEBSOFT ha aiutato a separare le responsabilità della piattaforma tra infrastruttura, segreti, workload, osservabilità e livelli di sicurezza. Contratti di integrazione documentati hanno reso più facile per i team comprendere quale sistema possedesse ciascuna parte del flusso di delivery.
Infrastructure as Code modulare
Gli stack OpenTofu erano organizzati attorno a confini di stato isolati e gate CI automatizzati. I commenti ai plan nelle pull request aiutavano i revisori a comprendere le modifiche all’infrastruttura prima dell’approvazione, mentre il rilevamento programmato del drift evidenziava le differenze tra l’infrastruttura dichiarata e quella effettiva.
Riconciliazione GitOps a livelli
FluxCD era organizzato con dipendenze esplicite tra i livelli della piattaforma. Questo ha ridotto il rischio di rollout e reso il recovery più semplice perché le modifiche potevano essere revisionate, applicate, ripristinate e tracciate attraverso Git.
Governance unificata di identità e accesso
La federazione Okta SSO ha fornito a ingegneri e operatori un modello di accesso centralizzato tra strumenti cloud e di piattaforma. AWS IAM Identity Center, Vault, GitHub, Grafana, Datadog, Rancher, Jenkins e altri sistemi potevano seguire un pattern di identità più coerente.
Design della piattaforma Kubernetes attento ai costi
Karpenter ha aiutato la piattaforma ad adattare la capacità di calcolo alle esigenze dei workload. I workload di sviluppo potevano utilizzare capacità attenta ai costi, mentre la produzione rimaneva allineata con i requisiti di affidabilità.
Pipeline CI/CD basate su Vault
I workflow CI/CD utilizzavano l’autenticazione basata su Vault per le operazioni sensibili delle pipeline. Questo ha supportato un delivery dell’infrastruttura più sicuro senza esporre segreti ampi e di lunga durata ai sistemi di build.
Risultati aziendali
Delivery più sicuro e rapido
I plan OpenTofu revisionati nelle pull request, la riconciliazione GitOps e il rilevamento automatizzato del drift hanno reso le modifiche all’infrastruttura più deliberate e auditabili. Gli ingegneri potevano riprodurre gli ambienti da Git, ripristinare tramite source control e diagnosticare i problemi da una cronologia delle modifiche più chiara.
Sicurezza più forte e conformità SOC 2
SSO centralizzato, accesso AWS governato, gestione dei segreti basata su Vault, endpoint protection, logging centralizzato, monitoraggio della sicurezza e record di infrastruttura basati su Git hanno aiutato la piattaforma a soddisfare i requisiti di conformità SOC 2 supportando al contempo il lavoro di engineering quotidiano.
Migliore controllo dei costi senza sacrificare l’affidabilità
Karpenter e strategie di capacità specifiche per ambiente hanno aiutato il cliente a ottimizzare l’utilizzo di calcolo. I workload di sviluppo potevano utilizzare infrastruttura attenta ai costi, mentre i workload di produzione mantenevano la stabilità necessaria per le operazioni di call center.
Osservabilità e risposta agli incidenti migliorate
Grafana, Loki, Alloy, Datadog, GuardDuty e avvisi di sicurezza degli endpoint hanno fornito ai team una visione operativa più forte tra l’infrastruttura cloud e ibrida. Questo ha migliorato la capacità del team di rilevare, indagare e rispondere ai problemi della piattaforma.
Base di piattaforma modernizzata
Il progetto ha creato una base più solida per la migrazione di infrastrutture legacy, la modernizzazione di server autogestiti, le operazioni cloud e l’automazione DevOps futura. Invece di affidarsi a processi operativi disconnessi, il cliente ha ottenuto un modello di piattaforma più governato per il delivery sicuro di call center.
Conclusione
Questo progetto di modernizzazione DevOps ha aiutato un’azienda tecnologica statunitense di call center a passare da un’infrastruttura legacy autogestita verso una piattaforma sicura di cloud ibrido. Combinando AWS, Kubernetes, GitOps, identità centralizzata, gestione dei segreti, osservabilità, controlli di sicurezza e governance della piattaforma orientata alla conformità, HDWEBSOFT ha supportato un modello di delivery più rapido, più auditabile e allineato con i requisiti di conformità SOC 2.
Se il suo team sta modernizzando un’infrastruttura legacy o preparando una piattaforma cloud sicura per un delivery pronto per le audit, esplori i servizi DevOps di HDWEBSOFT o ci contatti per discutere la roadmap della piattaforma più adatta.
Esplora altri contenuti correlati
Vedi altro case studies, servizi, settori e esperienza operativa regionale correlata
