Migracija u cloud: Hetzner, DigitalOcean i Cloudflare

Migracija u cloud premješta vaše web stranice, aplikacije i baze podataka sa mjesta na kojem su danas – shared hosting paketa, zastarjelog servera u kancelariji ili preskupog setupa kod nekog hyperscalera – na cloud infrastrukturu koja je brža, jednostavnija za održavanje i ima predvidive troškove. Kada je dobro urađena, migracija je za vaše kupce nevidljiva: jednog dana sajt se jednostavno brže učitava, a račun za infrastrukturu je manji. Kada je loše urađena, znači izgubljene narudžbe, mejlove koji ne stižu i vikend proveden u gašenju požara.

U CodeWizu planiramo i izvodimo migracije na Hetzner, DigitalOcean i druge provajdere, uz Cloudflare ispred kao sloj za performanse i sigurnost. Popisujemo sve od čega vaš sistem zavisi, za svaki dio biramo odgovarajuću platformu, uvježbavamo prelazak, prebacujemo podatke uz spreman plan za povratak i podešavamo novo okruženje tako da zaista dobijete performanse koje plaćate.

Usluga je namijenjena firmama koje su prerasle shared hosting, timovima koji plaćaju cijene hyperscalera za aplikacije kojima njihove napredne mogućnosti ne trebaju i kompanijama koje imaju jedan ključni server koji niko ne smije dirati. Niste sigurni da li selidba uopšte ima smisla? Upravo na to odgovara prva analiza.

Cloud: Svijetleća optička vlakna na tamnoj pozadini

Analiza prije migracije u cloud: znajte šta selite

Većina neuspješnih migracija propadne prije nego što se kopira i jedan fajl. Neko zaboravi cron koji u ponoć šalje fakture, SMTP relay koji prihvata samo IP adresu starog servera, putanju upisanu direktno u konfiguraciju ili eksterni API koji prima zahtjeve samo sa stare adrese. Zato naš prvi rezultat nije novi server, nego popis.

Šta mapiramo

  • Aplikacije i runtime: PHP, Node.js, Python, web server, pozadinske procese (workere) i zakazane poslove.
  • Podatke: baze i njihovu veličinu, učestalost upisa, uploadovane fajlove, sesije i indekse za pretragu.
  • Mrežne zavisnosti: DNS zapise, mejl (MX, SPF, DKIM, DMARC), IP whitelist kod partnera i dolazne webhookove.
  • Profil saobraćaja: vršne sate, lokacije posjetilaca i mjesečni protok.
  • Zahtjeve: prihvatljiv prekid rada, ciljeve oporavka (RPO i RTO) i lokaciju podataka.

Strategija migracije za svaki dio sistema

Ne treba sve seliti na isti način. Odluku donosimo za svaki dio posebno, prema poznatim „R” strategijama:

StrategijaŠta značiObim poslaKada odgovara
Rehost (lift and shift)Isti stack na novim serverima, uz prilagođenu konfiguracijuMaliStabilne aplikacije i kratki rokovi
ReplatformManje izmjene radi korištenja managed baza, object storagea ili kontejneraSrednjiVećina web aplikacija – najbolji odnos uloženog i dobijenog
RefactorPrilagođavanje arhitekture cloudu: aplikacija bez stanja, redovi poruka, autoscalingVelikiSistemi koji su prerasli jedan server
Retire ili replaceGašenje nekorištenih dijelova ili zamjena SaaS rješenjemRazličitStari administrativni alati i dupli servisi

Rezultat analize je pisani plan migracije: ciljna arhitektura, izbor provajdera i regiona, redoslijed seljenja, način prelaska za svaki servis, plan za povratak i procjena mjesečnih troškova novog okruženja u poređenju sa sadašnjim.

Hetzner setup: ozbiljne performanse za djelić cijene

Hetzner je naša podrazumijevana preporuka kada je najvažniji odnos cijene i performansi, a to je najčešće slučaj. Njihovi cloud i dedicated serveri nude mnogo procesorske snage, RAM-a i NVMe prostora za uložen novac, velikodušan uključen saobraćaj i data centre u Njemačkoj i Finskoj, što olakšava i pitanja vezana za GDPR. Cijena toga je manji izbor managed servisa nego kod AWS-a ili DigitalOceana, pa veći dio platforme gradimo i održavamo mi.

Kako gradimo Hetzner okruženje

  • Cloud ili dedicated: cloud serveri sa dijeljenim vCPU-om za web sloj i staging, instance sa namjenskim vCPU-om ili Arm (CAX) za stalna opterećenja, a dedicated root serveri za velike baze, gdje su znatno jeftiniji od istog kapaciteta u cloudu.
  • Privatna mreža i firewall: baze nikada ne dobijaju javni port, a do servera stižu samo HTTPS sa Cloudflarea i SSH sa poznatih adresa.
  • Load Balanceri i floating IP adrese za okruženja sa više aplikacionih servera ili brzim prebacivanjem u slučaju otkaza.
  • Volumes, Storage Box i Object Storage za trajne podatke i backupe van servera, uz snapshotove.

Servere kreiramo iz koda i konfigurišemo preko cloud-inita, tako da je svako okruženje ponovljivo. Tipično pokretanje uz hcloud CLI izgleda ovako:

hcloud network create --name prod-net --ip-range 10.0.0.0/16 hcloud network add-subnet prod-net --network-zone eu-central \ --type cloud --ip-range 10.0.1.0/24 hcloud firewall create --name web --rules-file web-rules.json hcloud server create --name app-1 --type cpx31 \ --image ubuntu-24.04 --location fsn1 \ --network prod-net --firewall web --ssh-key deploy \ --user-data-from-file cloud-init.yaml

Hetzner Cloud dokumentacija detaljno opisuje svaki od ovih elemenata; naš posao je da ih složimo u okruženje koje je sigurno od prvog dana i dokumentovano za vaš tim.

DigitalOcean deployment: managed servisi bez složenosti hyperscalera

DigitalOcean se nalazi između običnog VPS provajdera i hyperscalera. Dobar je izbor kada želite gotove managed gradivne blokove – baze, Kubernetes, load balancere, object storage – sa jasnim cijenama i kontrolnim panelom koji vaš tim razumije, bez dana provedenih u podešavanju IAM politika.

Šta najčešće postavljamo

  • Droplete unutar VPC mreže za aplikacione servere, sa uključenim Cloud Firewallom i monitoring agentom.
  • Managed Databases (PostgreSQL, MySQL, Valkey/Redis) sa standby nodovima, automatskim prebacivanjem, dnevnim backupom i vraćanjem na tačno određeni trenutak – veliki operativni teret manje.
  • DigitalOcean Kubernetes (DOKS) kada je aplikacija već kontejnerizovana i ima više servisa.
  • App Platform za jednostavnije aplikacije i API-je, kada želite deployment na git push bez ikakvog upravljanja serverima.
  • Spaces sa ugrađenim CDN-om za uploade i statičke fajlove, te Load Balancere ispred više Dropleta.
doctl databases create prod-pg --engine pg --version 17 \ --region fra1 --size db-s-2vcpu-4gb --num-nodes 2

Resurse smještamo u region najbliži vašim korisnicima – za evropsku publiku to su Frankfurt ili Amsterdam – a baza prihvata konekcije samo od provjerenih izvora unutar VPC-a. Širi pregled poređenja provajdera daje naš članak o strategijama deploymenta na DigitalOceanu, AWS-u, Hetzneru i bare metal serverima.

Hetzner, DigitalOcean ili AWS: izbor ciljne platforme

Ne postoji cloud koji je najbolji za sve. Pravi izbor zavisi od toga koje servise želite kao managed, gdje su vaši korisnici i koliko operativnog posla želite preuzeti na sebe.

KriterijHetznerDigitalOceanAWS / hyperscaleri
Odnos cijene i performansiOdličanDobarSlabiji za čistu procesorsku snagu; plaćate širinu ponude
Managed servisiOsnovni gradivni blokovi (load balanceri, volumeni, object storage)Managed baze, Kubernetes, App Platform, SpacesStotine servisa za gotovo svaku potrebu
Troškovi saobraćajaVelikodušan uključen saobraćajPaket protoka uključen uz svaki DropletOdlazni saobraćaj se naplaćuje po GB i lako ga je potcijeniti
Težina učenjaNiskaNiskaVisoka (IAM, mreže, naplata)
Najbolji zaProdukciju osjetljivu na troškove, baze na dedicated hardveru, podatke u EUTimove koji žele managed servise uz jednostavno održavanjeEnterprise zahtjeve, specijalizovane servise, globalnu skalu u više regiona

Kombinovana rješenja su česta i često idealna: aplikacioni serveri i baza na Hetzneru, Cloudflare na edgeu, a pojedinačni managed servis od hyperscalera samo tamo gdje opravdava svoju cijenu.

Narandžasti mrežni kablovi uključeni u označeni patch panel u serverskom ormaru

Cloudflare optimizacija: sloj koji migraciju čini sigurnom

Cloudflare u migraciji radi više od ubrzavanja gotovog sajta. Kada vaš domen ide preko Cloudflare proxyja, posjetioci se povezuju na Cloudflare, a ne direktno na vaš server, pa je prelazak na novi origin samo promjena jedne IP adrese koja djeluje za nekoliko sekundi – bez čekanja da istekne DNS keš širom svijeta i uz jednako brz povratak. Zato je prebacivanje DNS-a na Cloudflare obično naš prvi korak, sedmicama prije bilo kakve promjene servera.

Šta podešavamo

  • Zaštitu origina: novi serveri primaju web saobraćaj samo sa Cloudflare IP opsega, ili uopšte nisu dostupni sa interneta kada koristimo Cloudflare Tunnel i origin nema otvorenih dolaznih portova.
  • Full (strict) TLS sa origin certifikatima, tako da je saobraćaj šifrovan i provjeren cijelim putem.
  • Cache Rules i Tiered Cache, kako bi se statički fajlovi, a gdje je moguće i HTML, služili sa edgea.
  • WAF, rate limiting i zaštitu od botova prilagođene vašoj aplikaciji, a ne ostavljene na podrazumijevanim vrijednostima.
  • Load balancing i health checkove između više origina kada radite sa više lokacija.

Keširanje, kompresiju i podešavanja performansi detaljno smo obradili u vodiču za profesionalnu Cloudflare konfiguraciju; u projektu migracije ta podešavanja primjenjujemo na novi origin i provjeravamo cache hit ratio prije i poslije selidbe.

Prelazak bez prekida rada i migracija podataka

Trenutak prelaska je ono što se računa. Cilj nam je da ga kupci ne primijete i da se ne izgube podaci upisani tokom prebacivanja.

Kako sigurno selimo podatke

  • Baze: manje baze selimo u kratkom servisnom prozoru, uz konzistentan dump i restore. Za veće ili opterećene postavljamo replikaciju sa starog servera na novi (MySQL replikacija ili PostgreSQL logička replikacija), čekamo da se sustigne, pa novi primarni server preuzima za nekoliko sekundi.
  • Fajlovi i uploadi: početno masovno kopiranje danima unaprijed, zatim ponovljene inkrementalne sinhronizacije, pa posljednja traje minute, a ne sate.
  • Zamrzavanje upisa: u završnom koraku aplikacija nakratko prelazi u režim samo za čitanje ili u maintenance mode, kako se ništa ne bi upisalo u stari sistem nakon posljednje sinhronizacije.
  • Provjera: broj redova, checksume i smoke testovi ključnih tokova – prijava, checkout, kontakt forme, slanje mejlova – prije nego što prebacimo saobraćaj.
# Days before: bulk copy, repeated until the delta is small rsync -aHAX --delete --info=progress2 old-server:/var/www/app/ /var/www/app/ # Cutover window: maintenance on, final delta, promote new database php artisan down rsync -aHAX --delete old-server:/var/www/app/storage/ /var/www/app/storage/ # then switch the Cloudflare origin and run smoke tests

Kod online prodavnica ulog je veći, jer svaki minut nekonzistentnosti može značiti izgubljenu ili dupliranu narudžbu. Tu dodatno pauziramo ili stavljamo u red webhookove za plaćanja, a nakon prelaska usklađujemo narudžbe sa podacima iz panela payment provajdera.

Optimizacija performansi nakon migracije

Novi hardver sam po sebi ne čini aplikaciju brzom. Podrazumijevani PHP-FPM poolovi i nepodešena baza mogu ostaviti polovinu novog kapaciteta neiskorištenom, zato nakon migracije okruženje podešavamo prema stvarnom opterećenju.

Šta podešavamo i mjerimo

  • Prvo početno stanje: vrijeme odziva, propusnost i stopu grešaka mjerimo na starom sistemu prije selidbe, tako da je poboljšanje dokazano, a ne pretpostavljeno.
  • Pravu veličinu servera: procesor, RAM i disk usklađujemo sa izmjerenom potrošnjom, a ne sa nagađanjima.
  • Podešavanja runtimea i baze: broj PHP-FPM workera, OPcache, broj Node.js procesa te bafere i limite konekcija u bazi prema novoj mašini.
  • Latenciju: baza je na istoj privatnoj mreži kao aplikacija – pozivi bazi u drugom regionu su klasičan skriveni uzrok sporosti.
  • Testove opterećenja: realni scenariji u alatu k6 potvrđuju da novo okruženje podnosi vršna opterećenja sa rezervom.

Kako držati troškove clouda pod kontrolom

Mnoge firme pređu u cloud da bi uštedjele, a na kraju plaćaju više. Uzroci su predvidivi i od početka projektujemo tako da ih izbjegnemo:

  • Instance dimenzionisane za zamišljeni vrhunac i nikada ponovo pregledane.
  • Odlazni saobraćaj i saobraćaj između regiona koji se naplaćuje po GB i postane vidljiv tek na fakturi.
  • Zaboravljeni snapshotovi, volumeni i testna okruženja koja i dalje rade.
  • Managed servisi tamo gdje bi običan server obavio posao za djelić cijene.

Resurse označavamo tagovima, postavljamo upozorenja za troškove i nakon prvog mjeseca pregledamo potrošnju. Seljenje stalnih opterećenja sa hyperscalera na Hetzner ili DigitalOcean – takozvana cloud repatrijacija – često donosi najveću pojedinačnu uštedu. Za sajtove kojima treba kontrolni panel, open-source hosting panel zadržava jednostavno upravljanje bez troškova licenci.

Najčešće greške pri migraciji u cloud

  • Promjena DNS-a bez prethodnog smanjenja TTL-a, pa dio saobraćaja satima ili danima ide na stari server.
  • Zaboravljen mejl: MX zapisi, SPF zapis sa IP adresom starog servera ili kontakt forma koja je slala poštu preko lokalnog mail servera.
  • Nema plana za povratak, ili plan za povratak nikada nije testiran.
  • Nova baza „privremeno” ostavljena na javnoj IP adresi.
  • Gašenje starog servera odmah, prije nego što se potvrde backupi i nekoliko dana stabilnog rada.

Od čega zavisi cijena migracije u cloud

Fiksni obim i procjenu dajemo nakon analize. Glavni faktori su:

  • Broj aplikacija, servera i baza, kao i koliko su dobro dokumentovani.
  • Količina podataka i prihvatljiv prekid rada – replikacija bez prekida traži više pripreme od servisnog prozora.
  • Odabrana strategija: rehost je brži od replatforma ili refaktorisanja.
  • Regulatorni zahtjevi i da li želite da nastavimo održavati sistem nakon selidbe.
Laptop sa izvornim kodom na stolu i šoljom kafe u pozadini

Kako radimo

  1. Analiza: popisujemo aplikacije, podatke, zavisnosti i saobraćaj, te dogovaramo prihvatljiv prekid rada i ciljeve oporavka.
  2. Plan: biramo provajdera, region i strategiju za svaki dio sistema, projektujemo ciljnu arhitekturu i pišemo runbook za prelazak i povratak.
  3. Izrada: novo okruženje podižemo iz koda, stavljamo Cloudflare ispred i postavljamo backup i monitoring prije nego što se pomjeri ijedan podatak.
  4. Proba: izvodimo kompletnu probnu migraciju, provjeravamo integritet podataka i mjerimo performanse u odnosu na početno stanje.
  5. Prelazak: selimo u planiranom terminu, prebacujemo saobraćaj preko Cloudflarea i pažljivo pratimo sistem prvih sati i dana.
  6. Optimizacija i primopredaja: usklađujemo veličinu servera, podešavamo, pažljivo gasimo staru infrastrukturu i predajemo dokumentaciju – ili nastavljamo da održavamo sistem.

Zašto CodeWiz

  • Programeri, a ne samo administratori: Laravel, Node.js, WordPress i AI aplikacije i sami razvijamo, pa znamo šta im treba od infrastrukture.
  • Nezavisan savjet o provajderu: Hetzner, DigitalOcean, hyperscaler ili kombinacija – biramo prema vašem opterećenju.
  • Performanse uključene: Cloudflare, Varnish i podešavanje servera su naš svakodnevni posao.
  • Open-source na prvom mjestu: prenosivi alati i konfiguracija ostavljaju vam slobodu da se kasnije ponovo preselite.
  • Fer cijene: vrhunski rad bez vrhunskih cijena, iz Banje Luke, na daljinu sa klijentima iz regiona i svijeta – saznajte više o CodeWizu.

Često postavljana pitanja

Koliko košta migracija u cloud?

Zavisi od broja sistema, količine podataka i prihvatljivog prekida rada. Selidba jedne web stranice sa bazom je mali projekat, a više aplikacija sa replikacijom bez prekida je veći posao. Jasnu procjenu dobijate nakon analize, uz uporedni prikaz sadašnjih i budućih mjesečnih troškova infrastrukture.

Da li će moj sajt biti nedostupan tokom migracije?

Obično neće, ili samo nekoliko minuta. Uz Cloudflare ispred, inkrementalnu sinhronizaciju fajlova i replikaciju baze, sam prelazak traje nekoliko sekundi. Kada je kratki servisni prozor jednostavniji i prihvatljiv, zakazujemo ga u satima sa najmanje saobraćaja.

Da li je Hetzner dovoljno pouzdan za produkciju?

Jeste, za ogromnu većinu web aplikacija. Kao i kod svakog provajdera, pouzdanost dolazi iz arhitekture: backup na odvojenoj lokaciji, monitoring i redundantnost tamo gdje to poslovanje zahtijeva. To ugrađujemo od početka, umjesto da se oslanjamo na jedan server.

Koliko traje migracija?

Jedan sajt ili aplikacija se često može analizirati, probno preseliti i migrirati za sedmicu do dvije. Veći sistemi sa više servisa i velikim bazama traju duže, najviše zbog proba i provjera, a ne zbog same selidbe.

Da li da pređem sa AWS-a na Hetzner ili DigitalOcean?

Ako vaše opterećenje čine uglavnom serveri, baze i skladište, selidba može značajno smanjiti troškove. Ako se snažno oslanjate na servise specifične za AWS, djelimična selidba ili ostanak mogu biti pametniji. Analiza vam to pokazuje na stvarnim brojkama.

Spremni da isplaniramo vašu migraciju u cloud?

Recite nam šta danas koristite i šta ne funkcioniše – troškovi, brzina ili pouzdanost – a mi ćemo predložiti plan migracije sa jasnom ciljnom arhitekturom i rokovima. Kontaktirajte nas za početnu analizu ili pogledajte naše usluge migracije u cloud.