Webapp sviluppa da oltre dieci anni app e piattaforme di ordinazione per ristoranti, pizzerie e catene del delivery: app white-label con il marchio del locale, gestione ordini in tempo reale, notifiche push allo stato della consegna.
Il problema: un traffico che arriva tutto insieme
Il food delivery ha un profilo di carico molto particolare. Per gran parte della giornata il traffico è basso, poi tra le 19:30 e le 21:30, e soprattutto il venerdì e il sabato sera, gli ordini si moltiplicano fino a otto volte nel giro di pochi minuti. Proprio nel momento in cui un ristorante non può permettersi di perdere un ordine.
Con la crescita dei clienti, l'infrastruttura originale (sei server standalone, configurati a mano negli anni) aveva cominciato a mostrare i suoi limiti:
- Scalare voleva dire comprare un server più grande, dimensionato sul picco del sabato e inutilizzato il resto della settimana.
- Due o tre rallentamenti al mese proprio negli orari di punta, con il team tecnico a intervenire di sera via SSH.
- Rilasci manuali e rischiosi: circa due ore di lavoro, concentrati il giovedì notte per evitare i giorni di traffico.
- Staging e produzione non allineati: quello che funzionava in test non sempre funzionava in produzione.
- Single point of failure ovunque: se un server si fermava, si fermava un pezzo del servizio.
La soluzione: una piattaforma completa, non solo un cluster
Replio ha progettato e messo in esercizio per Webapp una piattaforma Kubernetes gestita su bare-metal, con produzione e staging su cluster separati e identici nella configurazione. Ma il cluster è solo la base: intorno c'è l'ecosistema che serve per andare in produzione con tranquillità, già integrato e presidiato dai nostri ingegneri.
Autoscaling tarato sugli ordini, non sulla CPU
L'autoscaling è guidato da metriche applicative raccolte da Prometheus: richieste al secondo e code di ordini da evadere. Durante il picco serale i servizi di ordinazione passano automaticamente da 4 a 20 repliche e tornano giù quando il traffico cala. Per le serate più prevedibili (venerdì, sabato, partite importanti) un pre-scaling programmato porta la capacità in alto qualche minuto prima che arrivi l'ondata.
Rilasci in GitOps
Ogni push sul repository Git avvia una pipeline che esegue i test, costruisce l'immagine e la pubblica sul registry privato Harbor, dove viene analizzata per le vulnerabilità prima di poter essere usata. Il rilascio lo fa Argo CD: lo stato di ogni ambiente è descritto in Git, quindi ogni modifica è tracciata e un rollback è un semplice ritorno alla versione precedente.
Osservabilità che parla la lingua del business
Le dashboard Grafana non mostrano solo CPU e memoria, ma anche ordini al minuto per ristorante, tempi di risposta delle API e stato dei pagamenti, con 12 mesi di storico su Thanos per pianificare la capacità della stagione successiva. I log di tutte le applicazioni sono centralizzati su OpenSearch: trovare l'errore di un singolo ordine richiede pochi secondi.
Alerting e reperibilità
Gli alert sono smistati per gravità: quelli informativi arrivano nel canale del team Webapp, quelli critici entrano nei turni di reperibilità Replio, anche di sera e nel weekend. In pratica, quando c'è un problema nel pieno del servizio, qualcuno di noi ci sta già lavorando prima che il cliente se ne accorga.
Sicurezza e accessi
Segreti e credenziali sono gestiti in Vault, il traffico in ingresso passa da un WAF e i nodi seguono l'hardening CIS con patch applicate in rolling update, senza fermi. Gli sviluppatori di Webapp accedono a dashboard, log, pipeline, registry e console dei cluster con un unico login SSO (Authentik): quando entra o esce una persona dal team, basta un solo intervento.
Backup verificati
Configurazioni e volumi (su storage Longhorn) sono salvati ogni notte su storage esterno al cluster, e il restore viene testato periodicamente: un backup che non è mai stato ripristinato non è un backup.
Come abbiamo lavorato
- Analisi (2 settimane): mappatura di servizi, dipendenze e flussi di traffico, misurazione dei picchi reali.
- Containerizzazione (3 settimane): insieme al team di Webapp, ogni applicazione è stata portata in container senza modificarne la logica.
- Migrazione progressiva (4 settimane): un servizio alla volta, con replica del database e cambio del DNS nelle fasce di traffico più basse. Nessun fermo programmato per i ristoranti.
- Messa a punto (1 settimana): taratura dell'autoscaling su due weekend reali e formazione del team su console, dashboard e flusso GitOps.
I risultati
- Zero fermi in orario di punta negli ultimi 12 mesi, con un uptime del 99,97%.
- Da 2 a 25 rilasci al mese: un rilascio richiede 8 minuti invece di due ore e si fa in qualsiasi giorno, anche il venerdì.
- Capacità elastica: l'infrastruttura si moltiplica per cinque durante il picco e si ridimensiona da sola, senza server sovradimensionati tutta la settimana.
- Il team torna a sviluppare: il tempo speso sull'infrastruttura è sceso da circa il 30% a meno del 5%.
Webapp è con Replio dal 2022 e la piattaforma è cresciuta insieme a loro: nuovi clienti, nuovi servizi, stessa tranquillità il sabato sera.