Există un moment în viața unei companii în creștere când cineva deschide spreadsheet-ul lunar de cloud și SaaS, arată cu degetul spre o linie și spune o variantă de „am putea să construim asta singuri pentru mai puțin de atât”. Linia este de obicei Snowflake, sau Datadog, sau Segment, sau Sentry, sau Salesforce, sau unul dintre cei câțiva vendori ale căror curbe de preț au fost modelate să extragă o fracțiune semnificativă din bugetul de infrastructură al unei companii tech de la series-B în sus. Numărul este mare, în creștere și vizibil corelat cu numărul de utilizatori, evenimente sau host-uri pe care compania le are, într-un fel care face ușor să-l extrapolezi înainte și să intri în panică.
Reacția este adesea corectă în spirit și greșită în detaliu. Uneori a construi lucrul respectiv este genuin un trade bun. Adesea este un trade mult mai prost decât pare în momentul realizării, pentru că costul cu care se compară este factura de la vendor, iar costul la care de fapt te angajezi este salariile inginerilor, infrastructura, costul de oportunitate și povara continuă de mentenanță a unei piese de infrastructură internă de care nimeni din afara echipei care a construit-o nu-i pasă. Lecția aceasta este despre cum să faci comparația aceea onest.
Este urmarea naturală a pârghiilor de cost pe care Modulul 9 le-a acoperit. Storage tiering, optimizarea de query-uri, right-sizing și cultura FinOps sunt toate despre cum să cheltui mai puțin în interiorul modelului de preț al unui vendor. Build-versus-buy este meta-întrebarea: ar trebui să cheltui în interiorul modelului de preț al vendorului deloc, sau workload-ul este acum suficient de matur și stabil încât să aibă sens să-l deții?
Pattern-ul
Forma se repetă peste categorii. Un vendor vinde un serviciu gestionat care rezolvă o problemă pe care echipa ta o are. În primii ani, vendorul este o victorie clară: produsul lor este mai capabil decât orice ai construi tu, prețul este mic relativ la restul cheltuielii tale și echipa ta are lucruri mai importante de făcut. Te înscrii, integrezi, echipa de platformă răsuflă ușurată.
Apoi compania crește. Factura crește cu ea, uneori mai rapid decât compania în sine, pentru că prețul vendorului este reglat să capteze mai multă valoare per unitate pe măsură ce clienții scalează. Un vendor care te costa cincizeci de mii de dolari pe an când aveai zece ingineri te costă acum trei milioane pe an când ai trei sute. Fracțiunea din use case pe care chiar o exersezi este adesea mică: folosești zece la sută din suprafața vendorului, dar plătești pentru produsul complet pentru că așa funcționează contractul.
La un anumit prag, cineva face calculul de pe spatele plicului. Doi ingineri full-time pentru un an înseamnă aproximativ jumătate de milion de dolari all-in. Infrastructura pentru a găzdui lucrul respectiv este poate alți o sută de mii. Deci dacă factura de la vendor este peste un milion pe an și workload-ul este o felie subțire din ce vând ei, a-l construi singuri arată ca o economie de cincizeci la sută. Pitch-ul prinde, echipa este aprobată, proiectul începe.
Dacă se termină cu bine nu este determinat de spreadsheet. Este determinat de pe care parte a unei mâini de factori se află workload-ul.
Matematica onestă
Comparația naivă este „factura vendorului versus salariile inginerilor plus infrastructura”. Comparația onestă are mai mulți termeni.
Costul vendorului. Factura curentă, proiectată înainte pentru perioada pe care o planifici. Trei până la cinci ani este orizontul potrivit, pentru că aceea este scala de timp pe care un rebuild intern trebuie să-și recupereze costurile.
Salariile inginerilor. Nu doar cei care îl construiesc. Cei care îl mențin după ce este construit. Un build cu doi ingineri este un angajament de șase ani-inginer pe trei ani dacă ții cont de operațiunile continue, iar acel număr scalează în sus pe măsură ce sistemul crește.
Infrastructura. Compute-ul, storage-ul și rețeaua pe care va rula versiunea in-house. Acesta este adesea subestimat, mai ales pentru sisteme care au nevoie de high availability, redundanță între regiuni sau instrumentare operațională atentă.
Cost de oportunitate. Ce ar fi construit acei ingineri în schimb. Termenul cel mai greu de estimat și adesea cel mai mare. Dacă cei doi cei mai buni ingineri de platformă ai tăi petrec un an clonând o bază de date de metrici, este un an pe care nu l-au petrecut pe următorul produs.
R&D-ul vendorului pe care îl replici. Acesta este termenul cel mai des ratat. Vendorul are zeci sau sute de ingineri care lucrează la produs. Livrează feature-uri, repară bug-uri, îmbunătățesc performanța, gestionează regimuri noi de conformitate, suportă cloud-uri noi. Versiunea ta in-house pornește ca un snapshot al ceea ce vendorul avea acum trei ani, iar diferența se mărește în timp. Costul de a rămâne competitiv cu roadmap-ul vendorului este real și recurent.
Costul de a comuta înapoi, dacă merge prost. Unele rebuild-uri eșuează. Planul onest contabilizează costul de întoarcere la vendor (migrare de date, renegociere de contract, post-mortem-ul intern jenant) dacă efortul in-house nu funcționează.
Când însumezi acei termeni, spreadsheet-ul rareori este atât de unilateral pe cât a făcut framing-ul original să sune. Uneori build-ul tot câștigă. Uneori nu. Ideea este să faci calculul în loc să-l sari.
Când rebuild-ul are sens
Patru condiții, toate trebuie să fie îndeplinite înainte ca proiectul să fie aprobat.
Costul vendorului este genuin o fracțiune mare din infra spend total. „Mare” aici înseamnă mai mult de zece la sută din bugetul total de infrastructură, susținut, cu o proiecție credibilă că va continua să crească. O linie de vendor care reprezintă trei la sută din bugetul total nu merită deranjată, chiar dacă numărul absolut e enervant. Aritmetica favorizează rebuild-ul doar când economiile sunt suficient de mari încât să finanțeze efortul de inginerie și să mai lase o marjă care să merite riscul.
Funcționalitatea pe care o folosești este o felie subțire din ce oferă vendorul. Dacă folosești zece la sută din produsul Datadog (doar metrici, doar o integrare de alerting, doar un set mic de dashboard-uri), plătești pentru celelalte nouăzeci la sută de feature-uri pe care nu le folosești. Cu cât felia este mai subțire, cu atât mai credibil o poți replica fără să absorbi povara R&D completă a vendorului. Dacă folosești cea mai mare parte a produsului, rebuild-ul este produsul complet și aceea este o conversație diferită.
Ai ingineri cu skill-urile relevante stând degeaba, sau skill-urile sunt o investiție strategică. Echipa care va construi înlocuitorul trebuie să cunoască domeniul. O echipă care nu a construit niciodată o bază de date de metrici nu va clona Datadog într-un trimestru, indiferent cât de motivată este. Candidații realiști pentru înlocuirea in-house sunt categoriile unde echipa ta a demonstrat expertiză sau unde construirea de expertiză este un obiectiv strategic care merită finanțat în sine.
Lucrul respectiv s-a deplasat de la diferențiat la commoditizat. Acesta este factorul subapreciat. O bază de date de metrici în 2016 era o problemă grea cu un set mic de blocuri de construcție open-source viabile. O bază de date de metrici în 2026 este o problemă mult mai ușoară, pentru că Prometheus, ClickHouse, VictoriaMetrics, Mimir și Grafana au făcut blocurile de construcție abundente și bine înțelese. Aceeași schimbare s-a întâmplat în pipeline-uri de evenimente (Kafka plus un framework mic versus un înlocuitor custom de Segment), error tracking (Sentry open-source versus versiunea hostată), feature flags și mai multe alte categorii. Când blocurile de construcție s-au commoditizat, rebuild-ul este în mare parte muncă de integrare, iar calculul înclină spre build.
Când toate patru sunt îndeplinite, build-ul are o șansă reală să iasă. Cazurile publicate (companii care au părăsit Segment pentru o conductă custom de evenimente, companii care și-au construit propria observabilitate și au economisit facturi lunare cu șase cifre, companii care au înlocuit vendori scumpi de feature flags cu un mic serviciu intern) tind să satisfacă toate cele patru condiții.
Când rebuild-ul nu are sens
Setul oglindă, la fel de important, mai ușor de uitat când spreadsheet-ul țipă.
R&D-ul vendorului este mult mai mare decât al echipei tale. Datadog are mai mulți ingineri care lucrează la produsul lor de observabilitate decât majoritatea companiilor au ingineri, punct. A încerca să-l clonezi cu trei oameni este un proiect care va produce ceva demonstrabil în șase luni, ceva pe jumătate credibil în optsprezece și ceva genuin competitiv niciodată. Răspunsul onest este să accepți factura și să folosești timpul echipei pe probleme unde ai o șansă să fii world-class.
Lucrul este infrastructură de critical-path pentru care nu vrei să fii responsabil la trei dimineața. Vendorii au rotații on-call, SLA-uri și personal de suport douăzeci-și-patru-șapte. Versiunea ta in-house are echipa care a construit-o, care ar dori și ea să doarmă. Pentru sisteme unde fiabilitatea este load-bearing pentru restul afacerii (autentificare, plăți, observabilitatea însăși când o întrerupere cascadează), maturitatea operațională a vendorului este parte din ce plătești, iar a o înlocui înseamnă a înlocui mult mai mult decât setul de feature-uri.
Echipa ta este mică sau focusată pe produs. Dacă compania are cincizeci de ingineri și bottleneck-ul este să livrezi produs către clienți, a scoate doi dintre acei ingineri din produs și a-i îndrepta spre rebuild de infrastructură de platformă este alocarea greșită. Întrebarea de rebuild devine credibilă doar la scale unde există o echipă de platformă suficient de mare să absoarbă munca fără să canibalizeze viteza produsului. Pragul acela este de obicei undeva în zona de joase sute de ingineri, cu excepții în ambele direcții.
Workload-ul încă evoluează rapid. Dacă utilizarea ta pe vendor se schimbă în fiecare trimestru pe măsură ce produsul evoluează, ești o țintă mobilă, iar un rebuild urmărește cerințe care se vor fi schimbat până când rebuild-ul se livrează. Workload-urile stabile, mature, sunt candidați mai buni pentru rebuild decât cele care se schimbă rapid.
Pattern-ul „l-am construit într-un weekend și acum este o piatră de moară” trăiește la intersecția acestor factori. Un inginer cu o săptămână bună și o opinie puternică construiește un înlocuitor intern pentru un tool SaaS enervant. Funcționează. Inginerul merge mai departe sau pleacă. Doi ani mai târziu, nimeni nu înțelege complet codul, dependențele s-au stricat, tool-ul este încă în critical path-ul a o jumătate de duzină de workflow-uri și echipa îl blestemă de fiecare dată când ceva se rupe. Economia originală a fost reală pe hârtie și negativă în practică, pentru că nimeni nu a contabilizat mentenanța din coada lungă.
Hibridul care învinge des
Pattern-ul pe care rebuild-urile cele mai de succes de fapt îl urmează nu este o înlocuire curată. Este o partiție. Construiește optzeci la sută ușor in-house, unde workload-ul este bine înțeles și suprafața vendorului este mult mai mare decât ce folosești. Ține douăzeci la sută greu pe un vendor, unde complexitatea operațională, edge case-urile sau pura amploare a feature-urilor ar domina costul rebuild-ului.
Pattern-ul se repetă. Companiile care au părăsit Segment au făcut-o adesea pentru pipeline-ul de evenimente server-side cu volum mare (Kafka, un mic serviciu de ingestie, câteva transformări bine înțelese), păstrând în același timp vendorul pentru coada lungă de SDK-uri mobile și integrări de parteneri. Companiile care și-au construit propria observabilitate dețin de obicei ingestia de metrici și dashboard-urile de bază, plătind în același timp un vendor pentru verificări sintetice, detecție avansată de anomalii sau APM în limbaje unde gap-ul de instrumentare in-house este cel mai mare. Companiile care și-au construit propriul feature flagging au păstrat adesea un vendor pentru părțile produsului care au nevoie de analize de experimentare integrate cu platforma lor de A/B.
Hibridul este nesexy. Nu produce anunțul satisfăcător „ne-am anulat contractul cu Datadog”. Produce însă economiile reale de cost, pentru că păstrează R&D-ul vendorului pentru părțile suprafeței unde contează cel mai mult și îl recâștigă unde nu.
Arborele de decizie
Diagramă de creat: un
flowchartMermaid care parcurge decizia rebuild-vs-buy. Input-uri: costul anual al vendorului, costul vendorului ca procent din infra total, fracțiunea din suprafața vendorului folosită, headcount disponibil cu skill-urile relevante, dacă categoria s-a commoditizat, dacă workload-ul este critical-path. Output-uri: păstrează la vendor / hibrid (build core, păstrează edge) / rebuild complet / negociază mai dur întâi.
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.]Arborele nu este un substitut pentru calcul. Este un filtru care prinde cazurile unde calculul nici măcar nu merită rulat. Majoritatea dezbaterilor build-versus-buy mor la prima poartă, pentru că factura vendorului este enervantă, dar nu suficient de mare să finanțeze alternativa. Dintre cele care trec de acea poartă, majoritatea mor la a doua sau a treia, pentru că utilizarea reală a echipei este mai largă decât a sugerat framing-ul, sau categoria este mai grea de construit decât pare. Cazurile care supraviețuiesc tuturor porților sunt cele în jurul cărora merită construit un plan real.
O notă despre negociere
Înainte ca orice proiect de rebuild să fie aprobat, rulează jocul negocierii. Vendorii vor da adesea reduceri substanțiale când se confruntă cu o amenințare credibilă de plecare, mai ales la momentul renewal-ului. O reducere de douăzeci-până-la-patruzeci la sută la un contract de mai multe milioane de dolari plătește pentru multă muncă de optimizare fără să cheltui un singur an-inginer pe un rebuild. Informația pe care ai adunat-o în timp ce contabilizai alternativa in-house este exact leverage-ul de care ai nevoie la masa de negociere.
Acesta nu este un substitut pentru întrebarea de rebuild. Este modul cel mai ieftin de a obține o porțiune semnificativă din economii fără să-ți asumi riscul de rebuild, iar echipa care rulează jocul negocierii întâi descoperă de obicei că întrebarea de rebuild își schimbă forma după aceea.
Unde lasă asta Modulul 9
Optimizarea costurilor a fost coloana vertebrală a Modulului 9. Layout-ul de stocare, right-sizing-ul de compute, rescrierile de query, practica FinOps și acum meta-întrebarea dacă relațiile cu vendorii însele trebuie să se schimbe. Următoarea lecție închide Modulul 9 cu un program publicat de optimizare a costurilor al unei singure companii, unde majoritatea acestor pârghii au fost trase deodată și economiile s-au compus. Apoi Modulul 10 se deschide ieșind complet din platforma de date, în întrebarea mai largă despre cum serviciile dintr-un sistem își împart responsabilitatea, cu microservicii și trade-off-urile care vin cu ele.