Il BSS cloud-native è più costoso del legacy?

Per operatori sotto pochi milioni di abbonati, il BSS cloud-native è tipicamente più economico su TCO a tre anni — senza capex, senza licenze per abbonato, senza voce infrastruttura dedicata e con molti meno integration engineer.

Un BSS cloud-native regge uptime di grado telco?

Sì. Le architetture cloud-native ottengono disponibilità superiori ai monoliti legacy grazie a scaling orizzontale, deployment blue/green e failover per servizio. Piattaforme hosted in Svizzera come METAVSHN eseguono workload ISP e MVNO in produzione.

Risposte

BSS cloud-native vs stack legacy

Le piattaforme BSS cloud-native sono costruite come microservizi indipendentemente deployabili, API-first, event-driven e prezzati come SaaS. Gli stack BSS legacy sono monolitici, on-prem o co-lo, licenziati per abbonato e richiedono tipicamente un system integrator a canone. Ognuno vince in segmenti diversi — la risposta onesta non è "sempre cloud-native".

Architettura

Cloud-native: microservizi, containerizzati, scalabili orizzontalmente, deploy più volte al giorno, domain event su broker condiviso, modello dati TM Forum SID. Legacy: monolite o SOA a grana grossa, deploy trimestrale, integrazione via database tra moduli, modelli dati custom per vendor.

Conseguenza pratica: il BSS cloud-native può lanciare un nuovo brand o bundle in giorni, quello legacy in trimestri. Il gap conta solo se l'operatore ha davvero bisogno di lanciare cose nuove di frequente.

Integrazione

Le piattaforme cloud-native espongono API tipizzate (REST, GraphQL) e pubblicano domain event (order.created, subscription.activated, invoice.paid) via webhook o message broker. Le piattaforme legacy si integrano via batch a file, view su database o strati di middleware che richiedono integration engineer dedicati.

METAVSHN usa connettori tipizzati — Service, Billing, Warehouse, Hardware, Verification — con webhook event-driven, così una nuova integrazione è un esercizio di configurazione anziché un progetto.

Pricing e total cost of ownership

Il BSS cloud-native è prezzato come SaaS — a consumo o a tier di subscription, senza capex né voce separata di infrastruttura. Il BSS legacy è licenziato per abbonato più infrastruttura, più un system integrator a canone. Per operatori sotto pochi milioni di abbonati, il TCO su tre anni del cloud-native è nettamente inferiore.

Quando il legacy vince ancora

Per operatori tier-1 con centinaia di milioni di abbonati, obblighi di reporting regolatorio pesanti e relazioni ventennali già in essere, smontare un deployment Amdocs o Oracle spesso non vale il rischio. Il BSS cloud-native vince nel segmento ISP, MVNO e rivenditori dove contano più velocità di lancio, unit economics e integrazione moderna.

Domande frequenti

Il BSS cloud-native è più costoso del legacy?: Per operatori sotto pochi milioni di abbonati, il BSS cloud-native è tipicamente più economico su TCO a tre anni — senza capex, senza licenze per abbonato, senza voce infrastruttura dedicata e con molti meno integration engineer.
Un BSS cloud-native regge uptime di grado telco?: Sì. Le architetture cloud-native ottengono disponibilità superiori ai monoliti legacy grazie a scaling orizzontale, deployment blue/green e failover per servizio. Piattaforme hosted in Svizzera come METAVSHN eseguono workload ISP e MVNO in produzione.