Cloud vs on-prem – o analiza care nu costa nimic

Am vorbit mai deunazi cu Miez. Un Miez experimentat pe IT, pragmatic. E din generatia mea, de astia care au pus mana la floppy cand au avut ocazia, au derulat casete audio cu pixu si au stat pe dial-up de 14400. Vorbeam de cloud, noi fosilele care am prins Windows NT Server Edition… M-a pus pe ganduri 🙂

Exista un moment in viata oricarui arhitect de sistem cand cineva din management vine ud tot si spune: „Auzi, am citit ca Amazon/Google/Microsoft ne poate scala la infinit. Hai sa ne mutam in cloud, se poate nu?” Momentul ala e frumos pentru ca stii ca este momentul in care constientizezi vreo 18 luni de migrare, un contract cu trei pagini de fine print si o factura lunara care va face contabilitatea sa lacrimeze amar si o sa ne tina cu hartie igienica d-aia roz si aspra pana venim cu ea de acasa. Cloud computing e o idee excelenta. A fost o idee excelenta in 2008 cand startup-urile nu aveau bani de servere si aveau nevoie de flexibilitate. E o idee mai putin excelenta cand o aplici uniform la orice workload, indiferent de caracteristici, si o facturezi pe cardul de firma fara sa te uiti la detalii.

Inainte sa semnezi ca primaru’ tre’ sa calculezi

Sa luam un exemplu concret si public. AWS EC2 instanta m6i.xlarge — 4 vCPU, 16GB RAM. Costa ~0,192 USD/ora on-demand, adica vreo 1.682 USD/an pentru o singura instanta care ruleaza non-stop. Un server fizic echivalent — Dell R640 refurbished (2×Gold 6234, 128GB, 2×1TB SSD) se gaseste la ~2.300 EUR second-hand, sau un Dell R660xs nou la ~8.000–9.000 EUR.

Dar pe serverul ala de 2.300 de euro nu pui o singura masina virtuala echivalenta cu m6i.xlarge. Pui un hypervisor — glorie Proxmox-ului sau un echivalent — si scoti vreo 8 instante de genul asta, poate 10 daca te lasi pe overcommit, ca doar ai 128GB de RAM si nu poti exagera. Cumperi inca doua servere identice si ai 20 de servere virtuale, legal-legal, fara sa bifezi niciun contract cu nimeni. Pica un Dell la 3 dimineata? Iti raman 2, restul workload-ului migreaza in cluster si tu dormi.

Oricare din variante — refurbished sau noua — se amortizeaza in 2–3 ani si ruleaza 5–7 ani (poate chiar 10). Pe AWS, acelasi workload costa 1.682 USD/an × 5 ani = 8.410 USD pentru o singura instanta — si la final nu ai nimic. Nici macar un surub. Inmulteste cu cele 20 de instante echivalente pe care ti le da un singur mini-cluster Dell de 6.900 de euro si vezi unde ajunge factura. * pe langa alea 3 servere ar mai fi nevoie de niste chestii (nu le pun sa para ieftin dar cred ca totalul ar fi la 10K cu tot cu niste networking). Asta e doar compute, pentru ca instanta aia are nevoie de storage din EBS, are nevoie de placi de retea, de VPC-uri, de subneturi, de niste NAT-uri, gateway… etc. Astea sunt serviciile pe care in maximum o ora le ai up in AWS. Click click pow! Asa si apar pe factura, usor, facil, gata sa le vezi pe card in coloana de sume creditate.

Egress si Inter-AZ – taxa pe curiozitate si arhitectura

Momentul favorit al oricarui cloud provider este cel in care faci o arhitectura mai rezistenta la dorel, se si aude cum isi freaca palmele de bucurie. Bagi date in cloud gratuit sau aproape gratuit si scoti date din cloud pe bani. AWS percepe ~0,09 USD/GB pentru egress spre internet si cred ca Azure si Google Cloud similar. Suna putin 0,09 USD pe GB pana cand ai un workload cu 10TB de date pe luna care trebuie sa ajunga la clienti. 10.000 GB × 0,09 USD = 900 USD/luna doar pentru egress. Aproape 11.000 USD/an ca sa iti trimiti propriile date, propriilor clienti. Cloudflare a publicat in 2021 o analiza in care arata ca AWS taxeaza egress-ul cu marcaje de peste 300% fata de costul real al benzii pe care AWS insusi il plateste, in functie de regiune. Nu pentru servicii. Pur si simplu pentru ca ai vrut sa iti iei datele inapoi.

Vrei high availability? Pai nu vrei tu high availability? Iti distribui aplicatia pe mai multe Availability Zones — AZ-uri diferite in aceeasi regiune, datacenter-uri fizice separate, exact cum recomanda AWS in orice documentatie de best practices. Problema: traficul intre AZ-uri costa. AWS percepe 0,01 USD/GB in fiecare directie pentru traficul inter-AZ.

Suna neglijabil pana cand realizezi ca serverul web din AZ-a citeste date din SQL-ul din AZ-b la fiecare request. Daca ai un workload cu 10TB de trafic intern pe luna intre servicii — si 10TB e o cifra modesta pentru orice aplicatie serioasa — asta inseamna ~2.000 USD/luna pentru trafic care, pe infrastructura proprie, calatoreste gratuit printr-un switch intern. Verifica de trei ori care server web consuma date din care SQL inainte sa iti proiectezi arhitectura multi-AZ. AWS a redus la zero costul inter-AZ pentru traficul prin PrivateLink, Transit Gateway si Client VPN inca din aprilie 2022, dar pentru EC2-to-EC2, RDS, ElastiCache — contorul merge. Arhitectura corecta din punct de vedere al disponibilitatii e arhitectura scumpa. E o vorba veche in IT ca cinci de 9 costa mult. Alegi cu cap, dar si cu inima – oare backup-urile le tinem in acelasi AZ cu workload-ul? Intreb pentru un amic… cred ca nu e ok. Folosim Elastic DR? Copiem date inter-AZ si cu ala?

Scalarea infinita – infinit buna dar si scumpa

Argumentul numarul unu pentru cloud e scalarea. Daca ai un varf de trafic, cloud-ul scaleaza automat – adevarul e ca AWS de-abia asteapta sa scalezi in sus… Suna bine, real si scump. Problema e ca 90% din workload-urile enterprise nu au spikes imprevizibile. Vezi banci, vezi primarii, sau chiar datacenterul BOR si eMAG. Au pattern-uri predictibile — trafic mai mare in orele de business, mai mic noaptea, variatii sezoniere cunoscute (Black Friday, Paste, Craciun).

Pentru astea, nu ai nevoie de scalare infinita. Ai nevoie de capacitate dimensionata corect, care nu se schimba semnificativ de la luna la luna. Scalarea infinita are sens pentru lansari de produse cu trafic imprevizibil, procesare batch ocazionala, startup-uri care nu stiu inca ce volum vor avea. Pentru o banca, un retailer sau o companie cu SaaS matur — predictibilitatea workload-ului ar trebui sa fie un argument pentru on-prem sau hybrid, nu pentru full cloud.

Faci un calcul, doua si te intorci in trecut la non-cloud

In 2022, 37signals (Basecamp, Hey) a publicat un calcul detaliat si a anuntat ca migreaza de pe AWS pe infrastructura proprie. Concluzia lor: cheltuiau ~3,2 milioane USD/an pe AWS. Hardware-ul echivalent on-prem costa ~600.000 USD total, cu costuri operationale anuale de ~500.000 USD. Economie estimata pe 5 ani: ~7 milioane USD. Nu e un caz izolat. Dropbox a migrat de pe AWS in 2016 si a economisit ~75 milioane USD in doi ani. Stack Overflow a rulat ani buni pe hardware propriu si a publicat repetat ca costul per request e de 10–100x mai mic decat cloud-ul echivalent pentru workload-ul lor predictibil.

Toate aceste companii au in comun acelasi lucru: workload predictibil, volume mari de date si ingineri care stiu ce fac… ah, si serverele lor in datacenter. A… si icoana pe rasarit in datacenter pentru demonii BSOD-urilor.

Cine are nevoie de cloud?

Startup in faza timpurie — fara capital pentru hardware si fara certitudine despre scale. Nu cumperi servere cand nu stii daca produsul va exista in 12 luni. Workload-uri cu spikes reale si imprevizibile — batch processing, ML training ocazional, campanii de marketing cu trafic variabil de 10-100x. Prezenta geografica multipla rapida — sa deschizi un datacenter in Croatia sau in Costa Rica costa milioane si luni de zile. O regiune AWS in Singapore costa un click si cateva ore. Echipe mici fara expertiza de operare infrastructura — un startup de 10 oameni nu ar trebui sa aiba un inginer de infrastructura full-time.

AWS e matur — si asta inseamna ceva concret

AWS exista din 2006, atunci a fost momentul cheie, plateste din mers, hey e asa de usor… Aproape 20 de ani de edge cases rezolvate, documentatie acumulata, tooling construit peste tooling. Cam orice problema pe care o ai a mai avut-o cineva inaintea ta. Integrarea cu AI si DevOps agents e un produs serios — Amazon Q Developer, CodeWhisperer, pipeline-uri automate cu analiza de securitate inclusa.

Pe infrastructura on-prem cu stack enterprise clasic — experienta proprie, mai demult — Windows Server, VMware, SQL Server, storage Dell sau NetApp, switch-uri Cisco — ai 4-5 vendori care trebuie sa colaboreze ca sa rezolve o problema serioasa. Si nu colaboreaza. Microsoft zice ca e problema hypervisor-ului, VMware zice ca e problema OS-ului, Dell zice ca storage-ul e perfect si logurile arata verde, Cisco tace si trimite un alt TAC engineer care cere aceleasi loguri pe care le-ai trimis saptamana trecuta. Intre timp, tu scrii RCA. Un RCA decent pe un incident serios cu stack multi-vendor inseamna minimum o saptamana: loguri din 4 sisteme cu timezone-uri diferite si formate incompatibile, ore de analiza, tichete la fiecare vendor, call-uri in care nimeni nu admite nimic. La final, RCA-ul are o sectiune „Root cause” care spune „interactiune neprevazuta intre componentele X si Y” si o sectiune CAPA cu recomandari generice pe care le-ai mai vazut in ultimele 3 RCA-uri.

Si daca tot vorbim de vendori care iti complica viata, hai sa vedem si licensing-ul Microsoft — sau de ce ai nevoie de un consultant certificat ca sa intelegi ce ai cumparat. Exista un motiv pentru care exista o intreaga industrie de consultanti specializati exclusiv in Microsoft licensing, probabil ca si acei consultanti apeleaza la un level mai smecher de consultanti… Nu e pentru ca modelul e complex din necesitate tehnica. E complex pentru ca complexitatea e un feature, nu un bug — cu cat e mai greu de inteles, cu atat e mai greu sa optimizezi si cu atat platesti mai mult din inertie. Vrei SQL Server? Exista Standard, Enterprise, Developer, Express. Vrei sa il rulezi in VM? Depinde cate core-uri are hostul fizic. Vrei HA cu Always On? Verifica daca licenta ta acopera replica pasiva. Vrei sa muti licenta pe alt server? Software Assurance. Vrei sa rulezi in cloud tert non-Azure? Exista reguli specifice pentru asta. Vrei sa intelegi toate astea dintr-un singur document clar? Nu exista.

Pe AWS sau Azure, iei o instanta RDS cu SQL Server, platesti per ora, licensing-ul e inclus. Nu jonglezi cu contracte, nu ai auditul Microsoft anual care vine sa verifice daca esti compliant, nu ai surprize cand vrei sa adaugi un nod la cluster si descoperi ca licenta ta nu acopera scenariul respectiv. Cost predictibil, zero consultanti de licensing, zero surprize contractuale. La fel, pe AWS, CloudTrail iti da loguri centralizate cu timestamp consistent, AWS Health Dashboard iti arata daca e un incident la nivel de serviciu — un vendor, un tichet. Timpul de la incident la RCA clar scade de la o saptamana la ore. Cel mai subestimat avantaj al unui cloud provider matur e acesta: cand ceva pica, e problema unui singur vendor.

Motivul principal pentru care cloud-ul are sens

Exista un argument solid pentru cloud pe care nu il auzi intr-o prezentare de vanzari: vrei sa muti responsabilitatea. Cand rulezi on-prem, esti responsabil pentru tot. Discul care pica la 3 dimineata — al tau. Firmware-ul switch-ului care are o vulnerabilitate — al tau. Contractul de mentenanta cu furnizorul de storage care are wait time de 4 ore pentru piese de schimb — al tau. O comanda de hardware nou care dureaza 6-8 saptamani pentru ca supply chain-ul global a avut o zi proasta — al tau. Update-urile de firmware la switch-uri, storage, hypervisor — ale tale. Inlocuitul discului cazut din RAID — al tau, la 3 dimineata, in datacenter, in frig. Cloud-ul muta toate astea. Nu le elimina — undeva exista un inginer AWS care se trezeste la 3 dimineata pentru discul ala. Avantajul e ca nu esti tu sau cineva din echipa ta. Asta are valoare reala si masurabila. Daca o echipa de 5 ingineri petrece 20% din timp pe ops de infrastructura fizica, iar costul lor total e 500.000 EUR/an, 100.000 EUR/an merg pe activitati care pot fi externalizate. Cloud-ul costa 200.000 EUR/an pentru workload-ul echivalent? Diferenta e de 100.000 EUR si castigul e ca cei 5 ingineri rezolva probleme de business in loc sa comande piese de schimb la 3 dimineata.

On-prem in 2026 – cloud-ul saracului?

On-prem poate fi semnificativ mai ieftin decat cloud pentru workload-uri mari si predictibile — cu o conditie care nu apare in niciun calcul TCO prezentat top managementului: ai nevoie de oameni buni de infrastructura. Nu oameni care stiu sa dea click in console, ci oameni care inteleg storage, networking, virtualizare, backup, DR, security patching, capacity planning. Oameni care stiu sa comande hardware la timp, sa negocieze contracte de mentenanta, sa scrie runbook-uri si sa le urmeze la 3 dimineata. Oameni scumpi, greu de gasit si mai greu de pastrat, o specie pe cale de disparitie. Daca ai echipa asta, on-prem pe workload predictibil si volume mari poate costa de 3-5x mai putin decat cloud-ul echivalent pe un orizont de 5 ani. Dropbox, 37signals si Stack Overflow nu sunt exceptii — sunt exemple de companii cu echipe de infrastructura competente care au facut calculul corect. Daca nu ai echipa asta — sau nu vrei sa o construiesti, sa o mentii si sa gestionezi tot ce vine cu ea — cloud-ul e raspunsul corect, chiar si la costuri mai mari. Prima pe care o platesti cloud provider-ului e in parte prima pentru ca nu trebuie sa angajezi, sa formezi si sa retii ingineri de infrastructura seniori, level 100 sau aproape de godmode.

Concluzia stiuta, dar de care nu vorbim…

Cloud-ul nu e ieftin, dar este convenabil, flexibil si rapid de pornit — si pentru astea platesti semnificativ in plus fata de a detine si opera „propria” infrastructura. Decizia corecta e de fiecare data specifica workload-ului. „Totul in cloud” e o strategie la fel de proasta ca „totul on-prem”. Prima e mai scumpa, dar a doua e mai rigida si necesita oameni pe care poate nu ii ai. Problema nu e cloud-ul in sine. E ca „migram in cloud” a devenit o decizie luata inainte de orice analiza tehnica, urmata de o analiza tehnica al carei scop e sa justifice decizia, nu sa o evalueze. La sfarsitul procesului, ai un contract de 3 ani cu un cloud provider cu preturi de oferta, preturile cu care iti iese TCO-ul, un arhitect care a dat din cap politicos si un CFO care va descoperi egress fees trimestrul urmator si va fi surprins peste 3 ani cand vin preturile alea reale. Amazon, Google si Microsoft au construit businessuri de sute de miliarde de dolari pe ideea ca e mai simplu sa inchiriezi infinit decat sa detii finit. Au dreptate. E mai simplu. Dar simplu si ieftin nu sunt acelasi lucru — si diferenta dintre ele apare pe factura.

O nota personala dupa 20 de ani in ambele lumi

Am inceput in IT in 2002. AIX, Linux, Active Directory, backup pe banda si o tona de floppy disk-uri sau cd-uri — cand „cloud” era inca un cuvant pe care il foloseau oamenii de la meteo, nu oamenii de vanzari. Prin 2005 am ajuns la primul dataroom serios, cu un upgrade in 2007. De acolo, doua decenii de infrastructura fizica: servere in rack, SAN-uri NetApp, VMware stretched cluster pe doua datacenter-uri din Bucuresti, iSCSI sau FC pe DWDM, SQL clusters active-passive, MongoDB replica sets. Adica exact genul de stack despre care Microsoft, VMware si Dell iti garanteaza ca functioneaza perfect — separat, fiecare in parte, niciodata impreuna, niciodata la 3 dimineata.

Am vazut tot ce poate merge prost cu on-prem. Am si rezolvat tot ce poate merge prost cu on-prem, ceea ce suna impresionant pana realizezi ca sunt acelasi om si ca nu ar fi trebuit sa fie nevoie de niciunul dintre cele doua. Am imbatranit in sedinte de 8-10 ore in care Microsoft zicea ca e vina VMware, VMware zicea ca e vina Microsoft, Dell trimitea un alt engineer care cerea aceleasi loguri pe care le trimisesem saptamana trecuta, si noi scriam RCA-uri in care „root cause” era intotdeauna o „interactiune neprevazuta” — adica nimeni nu stia nimic, dar o spuneam elegant.

Am coordonat relocari de datacenter. Am scris proceduri BC-DR pe care speram sa nu le folosesc niciodata. Am mapat fiecare server la un runbook si fiecare runbook la un om care sa se trezeasca noaptea sa il urmeze.

In 2024 am inchis cele doua datacenter-uri fizice din Bucuresti pentru ca totul s-a mutat in AWS. Zero incidente de productie cauzate de Dell, VMware sau Cisco. De atunci dorm. Pur si simplu dorm — concept pe care il uitasem complet in contextul profesional.

Asta nu apare in nicio analiza TCO si nu o poti pune intr-un spreadsheet. Dar daca ai crescut cu on-prem cum am crescut eu, stii exact cat valoreaza un somn linistit, cu telefonul lasat la incarcat pe noptiera, dar fara volumul dat la maximum. Dar cateodata mi-e dor…

Lasă un comentariu

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.