Të blini server, ta merrni me qira apo të përdorni renë? Vendosni për çdo aplikacion

Katër modele që ofertat duhet t'i dallojnë qartë

Blerja e një serveri fillimisht do të thotë pronësi mbi një pajisje. Ajo mund të vendoset në dhomën tuaj të pajisjeve ose në një qendër të dhënash me tarifa për vendosjen. Energjia, pjesët e këmbimit dhe i gjithë cikli i jetës ende duhen organizuar. Blerja mund të ketë kuptim për ngarkesa të qëndrueshme afatgjata, por lidh kapital dhe kërkon pritshmëri realiste për kapacitetin dhe jetëgjatësinë e përdorimit.

Me një server të dedikuar me qira, një ofrues furnizon makinën fizike. Kontrata përcakton sa shpejt zëvendësohen pjesët e prishura, çfarë mbështetjeje ofrohet dhe nëse sistemi operativ administrohet. Ndërsa një server virtual ndan një platformë fizike me sisteme të tjera. Performanca e garantuar dhe kufijtë e paketës duhet t'i përshtaten aplikacionit.

Cloud mund t'u referohet këtyre makinave virtuale, por përfshin edhe baza të dhënash të administruara, ruajtje objektesh dhe shërbime të orientuara nga aplikacionet. Prandaj ndryshimi është më shumë se një pagesë mujore. Ai lidhet me punën teknike që bëni vetë dhe atë që shërbimi merr realisht përsipër. Një term marketingu si ‘i administruar’ nuk e sqaron këtë pa përshkrim konkret të shërbimit.

Gjashtë pyetje përpara krahasimit të parë të çmimeve

• Si është ngarkesa? Përdorimi i qëndrueshëm i brendshëm, kulmet sezonale dhe projektet e përkohshme kërkojnë rezerva të ndryshme.
• Ku krijohen vëllimet e mëdha të të dhënave? Nëse të dhënat video përpunohen çdo ditë në zyrë, rruga drejt fuqisë llogaritëse ka po aq rëndësi sa vetë fuqia.
• Çfarë duhet të vazhdojë të punojë gjatë ndërprerjes së internetit? Shkruani konkretisht rrjedhat lokale thelbësore të punës.
• Kush e operon sistemin? Disponueshmëria, zëvendësimi i personelit dhe ekspertiza janë pjesë e vendimit.
• Sa ndërprerje dhe humbje të dhënash tolerohen? Kjo përcakton kopjet rezervë dhe rikuperimin.
• Si mund të nxirren përsëri të dhënat dhe aplikacioni më vonë? Eksporti, formatet, identitetet dhe rindërtimi duhet të funksionojnë së bashku.

Dokumentoni përgjigjet për çdo aplikacion. Një shërbim skedarësh, një sistem administrimi biznesi dhe një portal publik shpesh kanë kërkesa të ndryshme. Zhvendosja e të treve për të njëjtën arsye mund të anashkalojë lehtë një varësi lokale ose të paguajë për fleksibilitet që një shërbim me punë të qëndrueshme nuk e përdor.

Një matricë vendimi me kundërargumente reale

Peshoni kriteret vetëm pasi të keni plotësuar fletën e kërkesave. Nëse një makinë prodhimi duhet të vazhdojë të punojë kur ndërpritet lidhja e internetit, ky është kusht i detyrueshëm, jo një rezultat i ulët në renditjen e përgjithshme. Mes opsioneve që mbeten mund të peshohen puna, kostoja dhe përshtatshmëria. Një renditje matematikore nuk duhet të fshehë papërshtatshmërinë.

Tre aplikacione, tre vendime të mundshme

Shembulli i parë: një zyrë projektimi trajton skedarë të mëdhenj projektesh pothuajse vetëm në një lokacion. Gjatë testimit, transferimi i të dhënave te shërbimet në distancë është faktori që harxhon më shumë kohë. Mund të përshtatet një shërbim lokal skedarësh me një kopje rezervë jashtë lokacionit, e cila rikthehet në mënyrë të pavarur. Kjo kërkon ambient të përshtatshëm, mirëmbajtje dhe plan zëvendësimi. Vendimi do të ndryshonte nëse ekipi do të punonte kryesisht nga lokacione të shpërndara.

Shembulli i dytë: një portal publik rezervimesh ka kulme të parregullta dhe ekip të vogël të brendshëm IT-je. Një platformë e administruar aplikacionesh me bazë të dhënash mund të marrë përsipër detyra, nëse softueri është projektuar për të. Duhet të kontrollohen kostot për rezervim, eksporti i të dhënave dhe kufijtë e shërbimit. Një server virtual me madhësi të pandryshueshme që punon pa ndërprerje do të ishte gjithashtu cloud, por nuk do ta shfrytëzonte automatikisht këtë mundësi.

Shembulli i tretë: një aplikacion i brendshëm punon vazhdimisht me kërkesë të kuptuar mirë. Kompania nuk dëshiron të mbajë dhomë serverësh, por ka ofrues për sistemin operativ dhe aplikacionin. Një server i dedikuar me qira ose një server virtual me garanci të përshtatshme mund ta mbajë punën të menaxhueshme. Ende duhen kontrolluar rikuperimi real, lidhja e punonjësve dhe fusha kontraktuale e zëvendësimit të harduerit.

Kush merret me përditësimet, kopjet rezervë dhe rikuperimin?

Për EC2, AWS ia cakton klientit, ndër të tjera, sistemin operativ mysafir dhe aplikacionin e instaluar. Ofruesi operon infrastrukturën bazë. Ndarja ndryshon për shërbimet e tjera. Zbatojeni këtë parim për çdo ofertë dhe kërkoni që përgjegjësia të emërtohet në çdo shtresë. AWS: modeli i përgjegjësisë së përbashkët ↗

Një fletë e mirë operimi përcakton rol përgjegjës për harduerin, sistemin operativ, bazën e të dhënave, aplikacionin, aksesin e përdoruesve dhe kopjet rezervë. Ajo mbulon edhe zëvendësuesit, kohët e përgjigjes dhe procedurat e ndryshimit. Shmangni formulime si ‘ndoshta e bën hostuesi’. Përndryshe, boshllëku del në pah vetëm kur duhet rikthyer një bazë të dhënash dhe secila palë është përgjegjëse vetëm për një pjesë.

RTO përshkruan kohën e synuar të rikuperimit; RPO përshkruan humbjen e tolerueshme të të dhënave të shprehur në kohë. Këta objektiva rrjedhin nga nevojat e biznesit. Në përputhje me këtë, dokumentacioni AWS dallon disponueshmërinë e komponentëve të veçantë nga rikuperimi i një aplikacioni të plotë pas një dështimi të madh. AWS: planifikimi i rikuperimit pas katastrofës ↗

Fleksibiliteti ka vlerë; angazhimet kanë pasoja

Një mjedis testimi që mund të fiket brenda pak kohe nuk duhet blerë me të njëjtën llogaritje si një bazë të dhënash që punon për vite. AWS përshkruan modele të ndryshme çmimi për ngarkesa të ndryshueshme, përdorim afatshkurtër dhe angazhime afatgjata përdorimi. Një angazhim mund të ulë kostot, por vetëm nëse përdorimi i premtuar ndodh realisht. Ulja e çmimit nuk zëvendëson parashikimin e kërkesës. AWS: përshtatni modelin e çmimit me ngarkesën ↗

Për çdo opsion kërkoni llogaritje me të njëjtat vëllime të dhënash, kohë pune, afate ruajtjeje dhe detyra mbështetjeje. Llogaritni edhe një muaj me kërkesë më të lartë dhe përfundimin e kontratës. Sistemet në pronësi duhet të përfshijnë zëvendësimin e harduerit; shërbimet e jashtme duhet të përfshijnë eksportin, transferimin dhe rindërtimin. Një çmim fillestar në dukje i ulët mund të duket ndryshe gjatë gjithë periudhës.

Provoni bartshmërinë me një test të vogël eksporti

Një buton shkarkimi nuk provon se kalimi është i mundur. Gjatë testit, eksportoni një grup përfaqësues të dhënash me konfigurimin e nevojshëm dhe importojeni në një mjedis tjetër të veçantë. Kontrolloni nëse ruhen lidhjet, lejet, bashkëngjitjet dhe vulat kohore. Për një aplikacion kjo përfshin edhe skemën e bazës së të dhënave, shërbimet e kërkuara dhe lidhjen e llogarive të përdoruesve.

Matni edhe kohëzgjatjen. Një eksport hipotetik prej 2 TB përmes një lidhjeje me shpejtësi efektivisht të disponueshme prej 100 Mbit/s kërkon rreth 44.4 orë vetëm për transferim, duke përdorur njësi dhjetore. Përgatitja, kontrollet dhe ndërprerjet shtohen mbi këtë kohë. Kjo mund të jetë e pranueshme për zhvendosjen e një arkivi, por jo për rikuperim të shpejtë. Prandaj mundësia e eksportit dhe ajo e rikuperimit kërkojnë teste të veçanta.

Vendosni me një pilot të kufizuar

Zgjidhni një aplikacion përfaqësues dhe provoni opsionin e parapëlqyer në kushte realiste. Piloti ka nevojë paraprakisht për kritere të matshme: kohë përgjigjeje për një numër të dakorduar përdoruesish, kopje rezervë të plotë, rikuperim brenda objektivit dhe raport mujor kostosh të kuptueshëm. Përcaktoni edhe rrugën e kthimit para se të lëvizni të dhënat e prodhimit.

Pas testit regjistroni vendimin në një dokument të shkurtër: modeli i zgjedhur, përgjegjësitë e pranuara, supozimet e kostos, kufizimet e pranuara dhe rishikimi i ardhshëm. Arkitektura më e mirë është ajo që ekipi mund ta operojë me besueshmëri dhe ta ndryshojë më vonë. Kjo mund të nënkuptojë model tjetër për çdo aplikacion, për sa kohë kalimet dhe përgjegjësitë mbeten të qarta.