La decisione del 'ricostruirlo a meno'

C’è un momento nella vita di un’azienda in crescita in cui qualcuno apre lo spreadsheet mensile di cloud e SaaS, indica una riga, e dice qualche versione di “potremmo costruircelo da soli a meno di così”. La voce di solito è Snowflake, o Datadog, o Segment, o Sentry, o Salesforce, o uno della mezza dozzina di vendor i cui pricing curve sono stati modellati per estrarre una frazione significativa del budget infrastrutturale di un’azienda tech series-B-and-up. Il numero è grande, in crescita, e visibilmente correlato al numero di utenti o eventi o host che l’azienda ha, in un modo che lo rende facile da estrapolare in avanti e farsi prendere dal panico.

La reazione spesso è corretta nello spirito e sbagliata nei dettagli. A volte costruire la cosa è davvero un buon trade. Spesso è un trade molto peggiore di quanto sembri al momento della realizzazione, perché il costo con cui si confronta è la fattura del vendor, e il costo a cui ci si sta davvero impegnando è fatto di stipendi degli ingegneri, infrastruttura, costo opportunità, e il carico di manutenzione continuo di un pezzo di infrastruttura interna a cui nessuno fuori dal team che l’ha costruita tiene. Questa lezione riguarda come fare quel confronto onestamente.

È il naturale seguito alle leve di costo che il Modulo 9 ha trattato. Lo storage tiering, l’ottimizzazione delle query, il right-sizing, e la cultura FinOps riguardano tutti lo spendere meno dentro il pricing model di un vendor. Build-versus-buy è la meta-domanda: dovreste spendere dentro il pricing model del vendor in primo luogo, o il workload è ora abbastanza maturo e stabile perché abbia senso possederlo?

Il pattern

La forma si ripete trasversalmente alle categorie. Un vendor vende un servizio managed che risolve un problema che il vostro team ha. Nei primi anni, il vendor è una vittoria chiara: il loro prodotto è più capace di qualunque cosa costruireste, il prezzo è piccolo rispetto al resto della vostra spesa, e il team ha cose più importanti da fare. Si firma, si integra, il team di piattaforma tira un respiro.

Poi l’azienda cresce. La fattura cresce con essa, a volte più velocemente dell’azienda stessa, perché il pricing dei vendor è regolato per catturare più valore per unità man mano che i clienti scalano. Un vendor che vi costava cinquantamila dollari all’anno quando avevate dieci ingegneri ora vi costa tre milioni all’anno quando ne avete trecento. La frazione dello use case che effettivamente esercitate è spesso piccola: usate il dieci percento della superficie del vendor, ma state pagando per il prodotto pieno perché è così che funziona il contratto.

Ad una qualche soglia, qualcuno fa la stima a spanne. Due ingegneri full-time per un anno fanno grosso modo mezzo milione di dollari all-in. L’infrastruttura per ospitare la cosa è forse altri centomila. Quindi se la fattura del vendor è oltre il milione all’anno e il workload è una fetta sottile di ciò che vendono, costruircelo da soli sembra un risparmio del cinquanta percento. Il pitch atterra, il team viene approvato, il progetto inizia.

Se finisce bene non è determinato dallo spreadsheet. È determinato da quale lato di una manciata di fattori si trova il workload.

La matematica onesta

Il confronto naive è “fattura del vendor contro stipendi degli ingegneri più infrastruttura”. Il confronto onesto ha più termini.

Costo del vendor. La fattura attuale, proiettata in avanti sul periodo per cui state pianificando. Da tre a cinque anni è l’orizzonte giusto, perché è la timescale su cui un rebuild interno deve recuperare i suoi costi.

Stipendi degli ingegneri. Non solo quelli che lo costruiscono. Quelli che lo manutengono dopo che è stato costruito. Un build a due ingegneri è un impegno da sei engineer-year su tre anni se contate le operations continue, e quel numero scala in alto man mano che il sistema cresce.

Infrastruttura. Compute, storage e network su cui girerà la versione in casa. Questo viene spesso sottostimato, specialmente per sistemi che hanno bisogno di alta disponibilità, ridondanza tra region, o instrumentation operativa attenta.

Costo opportunità. Cosa quegli ingegneri avrebbero costruito invece. Il termine più difficile da stimare e spesso il più grande. Se i vostri due migliori platform engineer passano un anno a clonare un metrics database, è un anno che non hanno passato sul prossimo prodotto.

R&D del vendor che state replicando. Questo è il termine più spesso mancato. Il vendor ha decine o centinaia di ingegneri che lavorano sul prodotto. Stanno spedendo feature, fixando bug, migliorando performance, gestendo nuovi regimi di compliance, supportando nuovi cloud. La vostra versione in casa parte come uno snapshot di ciò che il vendor aveva tre anni fa, e il gap si allarga nel tempo. Il costo per rimanere competitivi con la roadmap del vendor è reale e ricorrente.

Costo di tornare indietro, se va male. Alcuni rebuild falliscono. Il piano onesto contabilizza il costo di tornare al vendor (migrazione dei dati, rinegoziazione del contratto, l’imbarazzante post-mortem interno) se lo sforzo in casa non funziona.

Quando si sommano questi termini, lo spreadsheet raramente è univoco come il framing originale lo faceva sembrare. A volte costruire vince comunque. A volte no. Il punto è fare il calcolo invece di saltarlo.

Quando ricostruire ha senso

Quattro condizioni, tutte e quattro dovrebbero valere prima che il progetto venga approvato.

Il costo del vendor è genuinamente una grande frazione della spesa infra totale. “Grande” qui significa più del dieci percento del budget infrastrutturale totale, sostenuto, con una proiezione credibile che continuerà a crescere. Una linea di vendor che è il tre percento del budget totale non vale la pena di essere disturbata, anche se il numero assoluto è fastidioso. L’aritmetica favorisce il rebuild solo quando i risparmi sono abbastanza grandi da finanziare lo sforzo ingegneristico e lasciare ancora un margine che valga il rischio.

La funzionalità che usate è una fetta sottile di ciò che il vendor offre. Se usate il dieci percento del prodotto Datadog (solo metriche, solo un’integrazione di alerting, solo un piccolo set di dashboard), state pagando per l’altro novanta percento di feature che non usate. Più sottile è la fetta, più credibilmente potete replicarla senza assorbire il carico R&D pieno del vendor. Se usate la maggior parte del prodotto, il rebuild è il prodotto pieno, e quella è una conversazione diversa.

Avete ingegneri con le skill rilevanti che stanno fermi, o le skill sono un investimento strategico. Il team che costruirà il sostituto ha bisogno di conoscere il dominio. Un team che non ha mai costruito un metrics database non clonerà Datadog in un trimestre, indipendentemente da quanto sia motivato. I candidati realistici per la sostituzione in casa sono categorie in cui il vostro team ha dimostrato expertise o in cui costruire expertise è un obiettivo strategico che vale la pena finanziare per conto suo.

La cosa è passata da differenziata a commodity. Questo è il fattore sottovalutato. Un metrics database nel 2016 era un problema difficile con un piccolo set di building block open-source viable. Un metrics database nel 2026 è un problema molto più facile, perché Prometheus, ClickHouse, VictoriaMetrics, Mimir, e Grafana hanno reso i building block abbondanti e ben compresi. Lo stesso shift è avvenuto nelle pipeline di eventi (Kafka più un piccolo framework contro un sostituto custom di Segment), nell’error tracking (Sentry open-source contro la versione hosted), nei feature flag, e in diverse altre categorie. Quando i building block sono diventati commodity, il rebuild è per lo più lavoro di integrazione, e il calcolo si inclina verso il build.

Quando tutte e quattro valgono, costruire ha una possibilità reale di ripagare. I casi pubblicati (aziende che hanno lasciato Segment per una pipeline di eventi custom, aziende che hanno costruito la propria observability e risparmiato fatture mensili a sei cifre, aziende che hanno sostituito vendor di feature flag costosi con un piccolo servizio interno) tendono a soddisfare tutte e quattro le condizioni.

Quando ricostruire non ha senso

Il set speculare, ugualmente importante, più facile da dimenticare quando lo spreadsheet sta urlando.

L’R&D del vendor è molto più grande del vostro team. Datadog ha più ingegneri che lavorano sul loro prodotto di observability di quanti ingegneri abbia la maggior parte delle aziende, in totale. Provare a clonarlo con tre persone è un progetto che produrrà qualcosa di demoabile in sei mesi, qualcosa di mezzo credibile in diciotto, e qualcosa di genuinamente competitivo mai. La risposta onesta è accettare la fattura e usare il tempo del team su problemi in cui avete la possibilità di essere world-class.

La cosa è infrastruttura critical-path su cui non volete essere reperibili alle tre del mattino. I vendor hanno rotazioni on-call, SLA, e personale di supporto ventiquattrore-sette. La vostra versione in casa ha il team che l’ha costruita, che pure vorrebbe dormire. Per sistemi in cui l’affidabilità è load-bearing sul resto del business (autenticazione, pagamenti, l’observability stessa quando un disservizio fa cascade), la maturità operativa del vendor è parte di ciò per cui state pagando, e sostituirla è sostituire molto più del feature set.

Il vostro team è piccolo o focalizzato sul prodotto. Se l’azienda è cinquanta ingegneri e il collo di bottiglia è spedire prodotto ai clienti, prendere due di quegli ingegneri dal prodotto e puntarli al rebuild di infrastruttura di piattaforma è l’allocazione sbagliata. La domanda del rebuild diventa credibile solo a scale in cui c’è un team di piattaforma abbastanza grande da assorbire il lavoro senza cannibalizzare la velocity del prodotto. Quella soglia è di solito da qualche parte nelle basse centinaia di ingegneri, con eccezioni in entrambe le direzioni.

Il workload sta ancora evolvendo velocemente. Se il vostro uso del vendor sta cambiando ogni trimestre man mano che il prodotto evolve, siete un bersaglio mobile, e un rebuild sta inseguendo requirement che si saranno spostati nel momento in cui il rebuild andrà in produzione. Workload stabili e maturi sono candidati migliori per il rebuild di quelli che cambiano velocemente.

Il pattern “l’abbiamo costruito in un weekend e ora è una macina al collo” vive all’intersezione di questi fattori. Un ingegnere con una buona settimana e un’opinione forte costruisce un sostituto interno per qualche fastidioso strumento SaaS. Funziona. L’ingegnere passa ad altro o se ne va. Due anni dopo, nessuno capisce completamente il codice, le dipendenze sono marcite, lo strumento è ancora nel critical path di mezza dozzina di workflow, e il team lo maledice ogni volta che qualcosa si rompe. Il risparmio originale era reale sulla carta e negativo nella pratica, perché nessuno ha contabilizzato la manutenzione long-tail.

L’ibrido che spesso vince

Il pattern che la maggior parte dei rebuild di successo seguono in realtà non è una sostituzione pulita. È una partition. Costruisci l’ottanta percento facile in casa, dove il workload è ben compreso e la superficie del vendor è molto più grande di ciò che usate. Tieni il difficile venti percento su un vendor, dove la complessità operativa, gli edge case, o la sola ampiezza di feature dominerebbero il costo del rebuild.

Il pattern si ripete. Le aziende che hanno lasciato Segment spesso lo hanno fatto per la pipeline di eventi server-side ad alto volume (Kafka, un piccolo servizio di ingestion, qualche transform ben compreso) tenendo il vendor per la coda lunga di SDK mobile e integrazioni partner. Le aziende che hanno costruito la propria observability tipicamente possiedono l’ingestion delle metriche e le dashboard di base mentre pagano un vendor per i synthetic check, l’anomaly detection avanzato, o l’APM nei linguaggi in cui il gap di instrumentation in casa è più grande. Le aziende che hanno costruito il proprio feature flagging spesso hanno tenuto un vendor per le parti del prodotto che hanno bisogno di analytics di sperimentazione integrate con la loro piattaforma di A/B.

L’ibrido è poco sexy. Non produce il soddisfacente annuncio “abbiamo cancellato il nostro contratto Datadog”. Produce sì i risparmi di costo reali, perché preserva l’R&D del vendor per le parti della superficie dove conta di più e lo recupera dove non conta.

L’albero di decisione

Diagramma da creare: un Mermaid flowchart che cammina attraverso la decisione rebuild-vs-buy. Input: costo annuo del vendor, costo del vendor come percentuale dell’infra totale, frazione della superficie del vendor usata, headcount del team disponibile con skill rilevanti, se la categoria è diventata commodity, se il workload è critical-path. Output: tieni sul vendor / ibrido (costruisci il core, tieni l’edge) / rebuild completo / negozia più duro prima.

flowchart TD
    A[Vendor bill is painful] --> B{>10% of total<br/>infra spend?}
    B -- No --> Z1[Negotiate. Stop here.]
    B -- Yes --> C{Use thin slice<br/>of product?}
    C -- No --> Z2[Stay on vendor.<br/>Optimise usage.]
    C -- Yes --> D{Category<br/>commoditised?}
    D -- No --> Z3[Stay. R&D gap<br/>too large.]
    D -- Yes --> E{Skilled team<br/>available?}
    E -- No --> Z4[Stay or hire first.]
    E -- Yes --> F{Critical-path<br/>at 3am?}
    F -- Yes --> H[Hybrid: build core,<br/>keep vendor for edge]
    F -- No --> G[Full rebuild candidate.<br/>Plan 3-year horizon.]

L’albero non è un sostituto per il calcolo. È un filtro che cattura i casi in cui il calcolo non vale nemmeno la pena di essere fatto. La maggior parte dei dibattiti build-versus-buy muore al primo cancello, perché la fattura del vendor è fastidiosa ma non abbastanza grande da finanziare l’alternativa. Di quelle che superano quel cancello, la maggior parte muore al secondo o terzo, perché l’uso effettivo del team è più ampio di quanto il framing implicasse o la categoria è più difficile da costruire di quanto sembri. I casi che sopravvivono a tutti i cancelli sono quelli per cui vale la pena costruire un piano vero.

Una nota sulla negoziazione

Prima che qualunque progetto di rebuild venga approvato, gioca la carta della negoziazione. I vendor spesso fanno sconti sostanziali davanti a una minaccia credibile di andarsene, specialmente al rinnovo. Uno sconto dal venti al quaranta percento su un contratto multi-milionario paga molto lavoro di ottimizzazione senza spendere un singolo engineer-year su un rebuild. Le informazioni che hai raccolto mentre quotavi l’alternativa in casa sono esattamente la leva che ti serve al tavolo della negoziazione.

Questo non è un sostituto per la domanda del rebuild. È il modo più economico per ottenere una fetta significativa dei risparmi senza prendersi il rischio del rebuild, e il team che gioca la carta della negoziazione per primo di solito scopre che la domanda del rebuild cambia forma dopo.

Dove questo lascia il Modulo 9

L’ottimizzazione dei costi è stata la spina dorsale del Modulo 9. Storage layout, right-sizing del compute, riscritture di query, pratica FinOps, e ora la meta-domanda se le relazioni con i vendor stesse abbiano bisogno di cambiare. La prossima lezione chiude il Modulo 9 con il programma di ottimizzazione dei costi pubblicato di una singola azienda, in cui la maggior parte di queste leve è stata tirata in una volta sola e i risparmi si sono composti. Poi il Modulo 10 si apre uscendo dalla data platform interamente, nella domanda più ampia di come i servizi in un sistema dividano la responsabilità, con i microservices e i trade-off che ne derivano.