---
title: "Colocare sau cloud: cum se construiește o comparație de cost onestă"
description: "Metoda pentru un calcul pe trei-cinci ani între echipamente proprii în colocare și cloud public: ce intră în model, ce se uită și ce decide."
url: "https://nixit.ro/resurse/colocare-sau-cloud/"
lang: "ro-RO"
---
# Colocare sau cloud: cum se construiește o comparație de cost onestă

Decizia dintre echipamente proprii găzduite în colocare și cloud public se ia rareori pe baza unui calcul complet. Se compară un tarif orar cu prețul unui server, se adaugă o marjă și se anunță un câștigător. Rezultatul are forma unui calcul financiar și conținutul unei presupuneri.

Un model corect nu produce un răspuns universal. Produce un răspuns pentru o sarcină de lucru anume, în organizația dumneavoastră, pe un orizont declarat. Ce urmează este metoda, nu concluzia.

## De ce tariful orar este cifra cea mai puțin utilă

Prețul pe oră al unei instanțe și prețul de achiziție al unui server ar fi comparabile dacă ar fi singurele costuri implicate, ceea ce nu se întâmplă niciodată. În cloud, calculul este adesea partea mai mică a facturii pentru sarcinile cu multe date. În colocare, serverul este adesea partea mai mică a costului total pe cinci ani.

Există și o problemă de formă. Un tarif orar se transformă în cost anual doar printr-o ipoteză de utilizare, iar acea ipoteză, nu prețul, este cea care decide rezultatul. O instanță pornită permanent și un server care stă în rack sunt același tip de cost. O instanță pornită opt ore pe zi nu are echivalent hardware, iar de aici pornesc majoritatea concluziilor greșite, în ambele direcții.

## Ce lipsește de obicei din partea de cloud

Nimic din lista următoare nu surprinde pe cineva care a citit o factură reală, dar rareori apare integral într-o primă estimare.

**Traficul de ieșire.** Datele care părăsesc platforma către internet se tarifează pe gigabyte, iar la volume mari această linie poate depăși costul calculului. Se estimează din trafic măsurat, nu din impresie.

**Traficul între zone de disponibilitate.** O arhitectură redundantă distribuie serviciile pe mai multe zone, iar traficul dintre ele este de regulă tarifat în ambele sensuri. Un cluster de baze de date replicat sincron produce acest trafic permanent, nu ocazional.

**Instantaneele și volumele orfane.** Lanțurile de instantanee fără politică de expirare, volumele rămase de la mașini șterse și adresele IP rezervate și nefolosite nu apar în estimarea inițială pentru că nimeni nu plănuiește să le aibă. Într-un mediu de doi ani există oricum.

**Resursele tarifate pe oră care nu sunt servere.** Echilibratoare de încărcare, gateway-uri NAT, puncte de acces private, adrese publice. Fiecare are un tarif mic și un total lunar care nu mai este mic atunci când există patru medii.

**Prima pentru serviciile gestionate.** O bază de date gestionată costă mai mult decât aceeași bază de date instalată pe o instanță. Diferența cumpără operare: actualizări, copii de siguranță, comutare automată la defect. Este frecvent o cheltuială justificată, dar trebuie trecută în model ca atare, nu ignorată pentru că este comodă.

**Planul de suport.** La majoritatea furnizorilor este un procent din factură, crește odată cu ea și, pentru producție, nu este opțional.

**IOPS și debitul provizionate.** Stocarea rapidă se tarifează separat pentru capacitate și pentru performanță. O bază de date care cere performanță provizionată poate costa de câteva ori cât sugerează prețul pe gigabyte.

**Licențele aduse cu sarcina de lucru.** Windows Server și bazele de date comerciale au reguli proprii de mobilitate a licențelor deja plătite, iar tratamentul lor diferă între furnizori.

## Ce lipsește de obicei din partea de colocare

**Spațiul și energia.** Rackul se plătește lunar, iar energia fie se facturează separat, fie este inclusă până la un prag de kilowați. Pragul contează mai mult decât prețul rackului, pentru că densitatea echipamentelor a crescut constant.

**Interconectările.** Cross connect, tranzit IP, o a doua legătură de la alt furnizor. Un singur operator într-un centru de date nu înseamnă redundanță, iar a doua legătură este o linie de cost, nu o notă de subsol.

**Amortizarea reînnoirii.** Costul corect nu este prețul de achiziție împărțit la durata contabilă de amortizare, ci prețul împărțit la perioada în care intenționați efectiv să folosiți echipamentul, plus extinderea garanției pentru anii de după perioada standard.

**Piesele de rezervă.** Un disc pe raft, o sursă, uneori un server întreg pentru un cluster mic. Capital imobilizat care nu produce nimic până în ziua în care produce totul.

**Intervențiile fizice.** Mâinile la distanță se tarifează pe intervenție sau pe oră, iar deplasările echipei proprii costă timp.

**Licențele de virtualizare și de backup.** Hipervizor, soluție de backup, monitorizare, sisteme de operare. Un model pe cinci ani construit cu prețurile de astăzi presupune tacit că aceste prețuri nu se schimbă, iar ultimii ani au arătat că se schimbă.

**Timpul de inginerie.** Linia omisă cel mai des. Cineva planifică, instalează, actualizează, răspunde la alerte, testează restaurările și ajunge fizic la centrul de date. Este fie cost salarial, fie contract. Fără această linie, modelul compară un serviciu cu un echipament.

## Gradul de utilizare decide mai mult decât prețurile

Echipamentul propriu se plătește indiferent dacă este folosit. Cloudul se plătește la consum, dar la un tarif care include o primă. Prima aceea cumpără dreptul de a nu plăti atunci când nu consumați. Dacă folosiți aproape toată capacitatea, aproape tot timpul, plătiți o primă pentru un drept pe care nu îl exercitați niciodată.

De aceea rezultatul util al modelului nu este un total, ci un prag: la ce grad de utilizare se intersectează cele două variante. Un prag îl puteți verifica pe măsurătorile din lunile următoare, un total nu.

## Un exemplu ipotetic, doar pentru forma calculului

Cifrele de mai jos sunt inventate și rotunjite. Nu sunt prețuri de piață, nu provin de la un client și servesc exclusiv la a arăta unde se așază liniile.

Presupunem o platformă internă stabilă, cu un număr fix de mașini virtuale, o cantitate mare de stocare care crește lent și trafic de ieșire moderat. Totul se exprimă în unități de cost, pe cinci ani.

Varianta cu echipamente proprii: 100 de unități hardware amortizat, 60 colocare și energie, 25 licențe, 15 piese și intervenții, 100 timp de inginerie. Total 300.

Varianta în cloud: 150 calcul cu angajament pe trei ani, 90 stocare, 30 trafic de ieșire și între zone, 20 suport, 40 timpul de inginerie rămas. Total 330.

Concluzia corectă nu este că a câștigat colocarea. O diferență de zece la sută este mai mică decât eroarea oricăreia dintre estimările componente, deci modelul a demonstrat că nu costul este criteriul care decide aici. Decizia trece atunci pe criterii nefinanciare: viteza de livrare, riscul operațional, disponibilitatea oamenilor care știu să opereze fiecare variantă.

## Angajamentele reduc factura și mută riscul

Instanțele rezervate și planurile de economii reduc semnificativ costul, în schimbul unui angajament de unu sau trei ani. Merită folosite pentru sarcinile stabile, cu o observație de metodă: angajamentul consumă exact flexibilitatea pentru care se plătește prima cloudului.

Dacă justificați cloudul prin flexibilitate și apoi îl prețuiți cu angajamente pe trei ani, modelul evaluează altceva decât ce cumpărați. Onest este să calculați ambele variante: cloud angajat față de hardware propriu, unde comparați două decizii la fel de rigide, și cloud la cerere față de hardware propriu, unde plătiți vizibil pentru posibilitatea de a vă răzgândi.

Riscul angajamentului este real. Arhitectura se schimbă, familiile de instanțe se schimbă, o aplicație este înlocuită. Angajamentul rămâne.

## Cât valorează posibilitatea de a vă răzgândi

Flexibilitatea nu trebuie nici invocată ca argument decisiv, nici respinsă ca vorbă goală. Trebuie prețuită.

Metoda practică este simplă: stabiliți trei scenarii de cerere pentru anul trei, unul sub estimare, unul conform, unul peste, și calculați costul fiecărei variante în fiecare scenariu. Cu echipamente proprii, subestimarea înseamnă o achiziție de urgență, cu termen de livrare, iar supraestimarea înseamnă capital imobilizat pentru totdeauna. În cloud, ambele erori se traduc într-o factură modificată luna următoare. Diferența dintre costul mediu ponderat și costul în scenariul central este chiar prețul opțiunii. Uneori este mic și nu justifică nimic. Alteori depășește orice economie de listă.

## Costul migrării intră în model

O comparație care ignoră migrarea compară o stare de fapt cu o stare ideală. Trebuie incluse efortul de inginerie, perioada de rulare în paralel, transferul datelor, adaptarea procedurilor de operare și instruirea. Se adaugă și costul de ieșire ulterioară, care pentru un volum mare de date stocate în cloud înseamnă trafic de ieșire facturat. Nu este un argument împotriva migrării, este o linie care lipsește.

## Unde răspunsul înclină clar

Cloudul este aproape întotdeauna alegerea corectă pentru creștere impredictibilă, medii temporare de test și dezvoltare, distribuție geografică largă, vârfuri sezoniere și pentru serviciile de date gestionate pe care altfel ar trebui să angajați pe cineva să le opereze.

Cloudul este de obicei alegerea greșită pentru volume mari de stocare stabilă, trafic de ieșire susținut și calcul constant la utilizare ridicată, adică exact profilul aplicațiilor interne mature.

## Împărțirea hibridă și structura modelului

Majoritatea organizațiilor ajung la o împărțire: baza stabilă pe echipamente proprii, vârfurile, mediile temporare și recuperarea în caz de dezastru în cloud. Împărțirea este rezonabilă atunci când este decisă, nu atunci când rezultă din inerție. Are și un cost propriu: două medii de administrat, două seturi de proceduri, oameni care trebuie să le cunoască pe amândouă.

Câteva reguli pentru model. Unitatea de comparație este costul anual total al unei sarcini de lucru delimitate, la un nivel de serviciu identic declarat; dacă o variantă include redundanță în două locații și cealaltă nu, comparați două lucruri diferite. Orizontul rezonabil este de trei până la cinci ani: un an favorizează mecanic cloudul, pentru că plasează toată investiția la început, iar zece ani favorizează mecanic hardware-ul, pentru că presupune că sarcina de lucru nu se schimbă. Valoarea reziduală a echipamentelor se trece prudent, adesea la zero, pentru că valoarea realizabilă efectiv este mică și incertă. Costul capitalului se aplică explicit: o plată în avans nu este echivalentă cu aceeași sumă distribuită pe cinci ani, iar rata de actualizare se agreează cu departamentul financiar, la fel ca dobânda, dacă folosiți finanțare.

Două particularități locale merită trecute în model, nu discutate separat. Prima este procedura de aprobare: o investiție de capital cere adesea aprobare într-un ciclu bugetar anual, în timp ce o cheltuială lunară trece mai ușor, iar întârzierea de câteva luni este un cost real al variantei cu echipamente proprii. A doua este moneda: facturile de cloud sunt de regulă în euro sau dolari, iar dacă veniturile sunt în lei, expunerea la curs este o linie într-un model pe cinci ani.

## Pasul următor

Un model construit onest se termină rareori cu o diferență mare, iar când se termină, motivul este de obicei o singură linie dominantă: stocarea, traficul de ieșire sau gradul de utilizare. Merită identificată acea linie înainte de a discuta despre platforme.

Construim astfel de comparații pe cifre reale în cadrul serviciului de [consultanță IT](/servicii/consultanta-it/), iar implementarea ulterioară intră fie la [management cloud](/servicii/management-cloud/), fie la [administrare servere](/servicii/administrare-servere/), în funcție de ce arată calculul.