ManoDebesis

Video paaiškinantis kaip jūsų interneto svetainė pasiekia lankytoją
 
Eksperimentuojame su edukaciniais video programuotojams. Labai laukiame pasiūlymų ką programavimo srityje jums sunku įsivaizduoti ir kam praverstų toks paaiškinimo formatas :)

ManoDebesis labai puikiai atsakė į trolių klausimus, tačiau lietuviška terminologiją (net ir su nuorodomis į wiki) pakišo koją ir nepadėjo suprasti apie ką visas šitas reikalas.
 
Aš tik gal dėl pačio puslapio pastebėjimą turėčiau, kad jums dabar į ką reikėtų investuoti, tai gražų dizainą (dabar atrodo kaip monochrome) ir turinį, nes kaip paaiškėjo net ir patys kiečiausi hostingo ekspertai nieko nesuprato.
 
Iš tikro paskaičius tokią diskusiją, darosiu liūdna, nes į tokias rankas niekados neatiduočiau talpinti savo projekto.

Peržvelgiau diskusiją ir noriu pritarti Augustinui – tiesiog šlykšti tulžis iš kai kurių oponentų liejasi. Gal susiturėkit ir energiją verčiau skirkite savo teikiamų paslaugų tobulinimui, m?
 
Dar viena pastaba dėl kalbos (kultūros), kurią ne vienam reikėtų patobulinti. Kaip pas besikeikiantį bei nuo pirmos akimirkos tujinantį verslininkėlį, taip ir pas savo kalbą angliškais (ar kokia kita kalba) intarpais „paįmantrinantį“ provincialą rimtas klientas niekada neateis. Galvokit.
 
ManoDebesies darbas atrodo įdomus. Linkiu augti ir tobulėti, ateityje bus smalsu išbandyti.

ManoDebesis, nepamirškite nuolat atnaujinti informacijos apie vykdomą projektą. Kad ir nenusiseks - vis tiek pagirtina iniciatyva ir ryžtas. Sėkmės projekte.
 
P.S. Kas liečia standartinius šio forumo hostingTrolius (hostingTrolis - tulžingas, neadekvatus asmuo siekiantis pažeminti kitus hostingo paslaugų teikėjus ir tokiu būdu tapti hostingo lyderiu šiame forume.) - mažiau veliantis su jais į "diskusijas" daugiau laiko sutaupysite.

Pridėsiu ir aš savo trigrašį -
ManoDebesis reiktų išmokt priimt kritiką, kuri beje yra gana pagrįsta, nes kol kas svetainėje debes.is tik manipuliuojama garsiomis frazėmis ...
 
Frazė "Naujos kartos hostingas modernioms svetainėms" skamba rimtai, bet taip pat akivaizdu, kad čia kol kas labiau tik svajonės ... Nebent tą nauja karta - tai lyginant su kokiu nors garažiniu superduperhosting.lt ..;)
 
Kaip ir rašė HOST321, "Tam reikia milijoninių investicijų " ir dar pridėčiau - Rimtos IT specų komandos su 10+ m. patirtimi dirbant su tartautiniais Enterprise lygio klientais ...
 
Na o dėl debes.is - tai tikiuosi, kad jums kas nors vis dėlto pavyks ir kokiais 2020 m. jūs būsit IT kompanija su milijonine apyvarta ;) ir stipriais produktais ;)

Sveiki,
 
pažeidžiamumų metas - vėl naujas pažeidžiamumas apie kurį galite pasiskaityti čia (taip pat ir pasitikrinti ar pažeidžiama jūsų svetainė):
 
http://poodlebleed.com/?utm_source=Email&utm_medium=email&utm_campaign=Namecheap+SSL+V+3.0+POODLE+Vulnerability
 
PS. uzdarbis.lt taip pat turi galimybe šiam pažeidžiamumui
 
kaip susitvarkyti savo serverį ar naršyklę ar kokį kitą klienta/serverį kuris naudoja ssl aprašyta čia:
 
http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566

Kiekvienam programuotojui neišvengiamai tenka susidurti su vartotojo identifikacijos problema. Tradiciškai lankytojo tapatybės nustatymui naudojama vartotojo vardo ir slaptažodžio kombinacija. Vartotojo vardas ir slaptažodis dažniausiai saugomi duomenų bazėje.
 
Tačiau pradedantiesiems dažnai vis dar iškyla klausimų kaip saugiai išsaugoti slaptažodį. Apžvelkime įvairius būdus, kurie dažnai taikomi saugojant slaptažodžius.
 
Saugojimas taip kaip įvedė vartotojas
 
Įvedus vartotojui savo slaptažodį jis tiesiog išsaugojamas duomenų bazėje tiesiai iš $_POST masyvo. Prisijungimo metu atliekamas palyginimas:
 
Išbandyti veikimą

if ($_POST["password"] == $password) { prisijungimas(); } else { neteisingai(); }
 
Toks būdas yra labai paprastas ir dažnai pasirenkamas pradedančiųjų programuotojų. Taip pat jei nenorima kurti slaptažodžio pakeitimo modulio, tuomet galima vartotojui lengvai priminti slaptažodį.
 
Tačiau tai yra pats pavojingiausias saugojimo mechanizmas!
 
Dažnai vartotojai naudoja tą patį slaptažodį įvairiuose puslapiuose. Jeigu duomenų bazė bus pavogta įsilaužėlių arba kenkėjų darbuotojų, jūsų klientų tapatybės kituose portaluose gali būti perimtos! Taip nutikus ir šiam faktui išlindus į viešumą jūsų reputacija bus nepataisomai sužlugdyta.
 
Kartais yra manoma, kad duomenų bazė niekada nebus pavogta ir ši problema yra ignoruojama. Tačiau kiekvienais metais net ir didžiausių kompanijų portalai yra kompromituojami ir jų duomenys paviešinami.
 
MD5 hash saugojimas
 
Šį būdą dažniausiai pasirenka pradedantys programuotojai nesenai sužinoję apie slaptažodžių hashing (http://lt.wikipedia.org/wiki/Santraukos_funkcija).
 
Šiuo būdu bet kokio ilgio įvestas slaptažodis konvertuojamas į visuomet tiek pat skaitmenų turintį skaičių. Šis dvejetainis skaičius tuomet konvertuojamas į šešioliktainį skaičių ir jis išsaugojamas kaip simbolių eilutė (angl. string). Jeigu slaptažodis bus visuomet toks pat, tuomet gautas hash rezultatas taip pat bus visuomet toks pat.
 
MD5 yra tiesiog viena iš labiausiai paplitusių hash funkcijų. Šiuo būdu duomenų bazėje niekada nesaugomas vartotojų įvestas slaptažodis, o saugomas tik hash rezultatas. Prisijungimo metu vartotojas įveda savo tikrą slaptažodį, o serverio dalyje jis transformuojamas su MD5 funkcija ir palyginamas su duomenų bazėje esančiu MD5. Jeigu MD5 hash sutampa tuomet vartotojas įvedė tikrai savo slaptažodį.
 
Išbandyti veikimą
 
Į duomenų bazę patalpinama:

$hash = md5($_POST["slaptazodis"]);
 
Prisijungimo metu:

$hash = $vartotojas["hash"]; if (md5($_POST["slaptazodis"]) == $hash) { prisijungimas(); } else { neteisingai(); }
 
Šis metodas remiasi tuo, kad iš hash rezultato neįmanoma išgauti tikro slaptažodžio. Taip pat hash reikšmė bus unikali ir niekada nebus gauta įvedus kitą slaptažodį.
 
Tačiau MD5 hash funkcija nebėra saugi! Ji yra labai greita ir su šiuolaikinėmis vaizdo plokštėmis galima išbandyti labai daug slaptažodžių itin greitai. Taip pat visos MD5 reikšmės jau suskaičiuotos ir galima atlikti paprastą patikrinimą lentelėje norint sužinoti slaptažodį.
 
Šis metodas yra ne ką saugesnis nei saugojant slaptažodį tokį patį kaip įvedė vartotojas! Naudojant šį būdą jūs rizikuojate savo reputacija.
 
SHA1 hash saugojimas
 
Šis metodas yra panašus kaip ir MD5. Duomenų bazėje taip pat saugojamas tik hash rezultatas gautas su SHA1 funkcija. Tokį metodą naudoja pradedantieji programuotojai, kurie girdėjo, kad MD5 funkcija yra nesaugi.
 
SHA1 hash funkcija sugeneruoja daugiau simbolių turintį rezultatą nei MD5. Tai sumažina tikimybę, kad kitas slaptažodis sugeneruos tokį pat rezultatą.
 
Išbandyti veikimą
 
Tačiau SHA1 funkcija šiuolaikiniais standartais yra pakankamai greita. Praradus duomenų bazę įsilaužėliai gana greitai aptiks tikrus vartotojų slaptažodžius. Daugelis saugumo ekspertų nerekomenduoja naudoti šios funkcijos saugojant slaptažodžius. Naudojant šį būdą jūs rizikuosite savo reputacija!
 
Saugojimas naudojant PHP5.5
 
PHP5.5 versijoje pridėtos slaptažodžių saugojimo ir patikrinimo funkcijos labai su paprastinančios programuotojo darbą. Jos savyje turi pačias naujausias saugumo praktikas. Naudojant šį metodą net ir praradus duomenų bazę jūsų vartotojų slaptažodžiai išliks saugūs. Įsilaužimo atveju jūsų reputacija bus pažeista, tačiau pataisoma.
 
Slaptažodžio saugojimas:

$hash = password_hash($_POST["slaptazodis"], PASSWORD_DEFAULT);
 
Slaptažodžio patikrinimas:

$hash = $vartotojas["hash"]; if (password_verify($_POST["slaptazodis"], $hash)) { prisijungimas(); } else { neteisingai(); }
 
password_hash() funkcijai perduodamas PASSWORD_DEFAULT parametras nurodo, kad naudoti bcrypt kriptografinį algoritmą. bcrypt buvo sukurtas dabar Google dirbančio Niels Provos ir paremtas Blowfish šifru. bcrypt priklauso "key derivation" funkcijoms ir yra skirtas saugoti slaptažodžiams.
 
Bcrypt rezultatas atrodo šitaip: "$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a"
Pradžioje esantis "$2y$10$" nurodo bcrypt versiją ($2y) ir cost ($10$). Cost nurodo kiek kartų reikia kartoti funkciją (10 reiškia kartoti 2^10 kartų).
 
Taip pat bcrypt algoritmas savyje inkorporuoja "salt" mechanizmą. Salt sugeneruojamas atsitiktinai ir pridedamas kartu į bcrypt rezultatą. Algoritmo vykdymo metu visuomet panaudojama salt reikšmė. Kiekvienas bcrypt rezultatas turi turėti skirtingą salt. Tai išsprendžia problemą, kuri dažnai sutinkama MD5 ir SHA1 algoritmuose, dar kitaip vadinamą Rainbow tables attack. Tai reiškia, kad esant net ir tam pačiam slaptažodžiui su bcrypt rezultatas bus skirtingas kiekvienam vartotojui. Įsilaužėliai turės kiekvieno vartotojo slaptažodį spėti iš naujo.
 
Tikimybė, kad bcrypt rezultatas bus neunikalus yra labai maža. Taip pat šios funkcijos cost parametras užtikrina, kad rezultato gavimas bus lėtas. Įsilaužėliams atspėti slaptažodžius pasinaudojant serverių fermomis bus labai sunku.
 
Rekomenduojama parinkti cost parametrą tokį, kad vieno bcrypt rezultato gavimas jūsų serveryje užtruktų 100 ms. Surasti tinkamą cost parametrą galite šitaip:

<?php $timeTarget = 0.1; // 100 milliseconds $cost = 8; do { $cost++; $start = microtime(true); password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]); $end = microtime(true); } while (($end - $start) < $timeTarget); echo "Cost parametras: " . $cost . "\n"; ?>
 
Perduoti cost parametrą:

$hash = password_hash($_POST["slaptazodis"], PASSWORD_BCRYPT, array("cost" => 10));
 
Jeigu slaptažodžius saugosite šiuo būdu, jūsų reputacija bus saugi.
 
Saugojimas naudojant PHP5.3.7+
 
Būdas yra identiškas PHP5.5, tačiau tinka ir senesnėms PHP versijoms.
Panaudoję šią biblioteką pasinaudosite tomis pačiomis funkcijomis:
https://github.com/ircmaxell/password_compat
 
Vartotojų identifikacija naudojant Laravel 4.2
 
Jei esate Laravel framework naudotojas saugus vartotojų valdymas yra itin paprastas.
 
Slaptažodžio saugojimas:

$password = Hash::make(Input::get('slaptazodis'));
 
Vartotojo prisijungimas:

$username = Input::get('vartotojas'); $password = Input::get('slaptazodis'); if (Auth::attempt(array('username' => $username, 'password' => $password))) { prisijungimas(); } else { neteisingai(); }
 
Išvados
 
Jeigu norima užtikrinti savo klientų duomenų saugumą tuomet privaloma naudoti saugius slaptažodžių saugojimo būdus. To neatlikus jūs rizikuojate savo reputacija. Patirtis rodo, kad praradus reputaciją ją susigrąžinti klientų akyse yra labai sunku.
 
Taigi jeigu rašote savo aplikaciją naudokite PHP5.5 funkcijas password_verify() ir password_hash(). Jeigu naudojate Laravel pasinaudokite siūlomais vartotojų identifikavimo mechanizmais.
 
Sėkmės kuriant saugias aplikacijas!
 
Blogas

hash'u (message digest), nesvarbu su kokiu algoritmu jie padaryti, neimanoma atokoduoti. Kad atkoduot (decrypt), pirma reikia uzkoduot (encrypt). Hash'as tai tiesiog 'unikalus' identifikatorius, kuris isgaunamas apdorojus turimus duomenis su tam specializuotais algoritmais.
 
bcrypt tiesiog yra mandras tuom, kad jis automatiskai sukuria salt'a ir naudoja kelis ciklus, kad sugeneruoti hash'a (ta pati galima pasiekti ir su kitais algoritmais, kaip pvz. SHA**, taciau tai reikalaus daugiau kodo). Ir nesvarbu, ar slaptazodis buvo hash'intas su bcrypt, ar SHA ar dar kokiu kitu algoritmu, ji teoriskai galima atrasti, taciau praktiskai tai truks per daug laiko.

HOST321 – gėda, atrodo teikiate talpinimo paslaugas, tačiau nesuprantate fundamentalių principų.
 
Pagal tavo logiką, didieji tiekėjai tokie kaip Google Cloud Platform, Amazon Web Services, Facebook turėtų veikti nepatikimai, nes naudoja commodity serverius? Vienas iš PaaS tikslų ir buvo padaryti nepatikimus komponentus patikimais.
 
Taip, mūsų atveju kol kas žemiausias commodity komponentas yra VPS. Jam sutrikus, lankytojai nukreipiami į kitą repliką. Tačiau fundamentaliai platforma nėra pririšta prie būtent tokio virtualizacijos mechanizmo. Scalinant teks neišvengiamai talpinti savo serverius. Mažesniu mastu logiškiau turėti ne didžiulį serverį, o daugiau mažų virtualizuotų replikų, tuomet patikimumas didesnis.
 
Sugrįžkite į 21 amžių. Čia nebereikia prisukinėti varžtų ir važiuoti į DC, kad paleisti savo platformą.

Sveikas Ensom,
 
Kiek esu matęs tokių sprendimų jie būna dažniausiai paruošti kaip aplikacijos veikiančios ant jau egzistuojančios operacinės sistemos. Vienur tai būna Android operacinė sistema ir ant viršaus veikianti aplikacija, kitur Windows operacinė sistema ir atidaryta svetainė.
 
Jeigu nori nuo pagrindų suprasti kaip veikia kompiuteris ir proceso metu parašyti savo OS, siūlau šį nemokamą kursą - Nand2Tetris. Jo metu sukursi savo procesorių, kompiuterio architektūrą, operacinę sistemą ir ant jos veikiančias aplikacijas. Šis kursas dėstomas Izraelio universitete, tačiau jo medžiaga yra nemokama ir prieinama visiems.

asmeninis kompiuteris naudoja TEO dns serverius kuriuos pasiema per dhcp
 
serveris 1 naudoja baltnet dns serverius
 
serveris 2 naudoja parašysiu pm

Sveikas Ensom,
 
Kiek esu matęs tokių sprendimų jie būna dažniausiai paruošti kaip aplikacijos veikiančios ant jau egzistuojančios operacinės sistemos. Vienur tai būna Android operacinė sistema ir ant viršaus veikianti aplikacija, kitur Windows operacinė sistema ir atidaryta svetainė.
 
Jeigu nori nuo pagrindų suprasti kaip veikia kompiuteris ir proceso metu parašyti savo OS, siūlau šį nemokamą kursą - Nand2Tetris. Jo metu sukursi savo procesorių, kompiuterio architektūrą, operacinę sistemą ir ant jos veikiančias aplikacijas. Šis kursas dėstomas Izraelio universitete, tačiau jo medžiaga yra nemokama ir prieinama visiems.

Man tai nelabai aišku, ką aš realiai gaunu, pasirinkęs tą vienintelį planą...
http://debes.is/talpinimo-planai
 
Ir kaip man suprast, palyginus su kitais - kokie čia privalumai ...
 
Čia bandymas kurt kažką panašaus kaip RedHat OpenShift ..?

Kiek reikia uzklausu i abu serverius, kad nebespetu sinchronizuot duomenu tarp serveriu ? Nespejant sincronizuot duomenu ilgeja svetaines uzkrovimo laikas? Ar islaikomas nuoseklus duomenu bazes uzklausu vykdymas ir failu kurimas, atnaujinimas, nespejant sincronizuot duomenu? Mano poziuriu islostas laikas del serveriu lokacijos gali baigtis tik padidejusiu uzkrovimo laiku kai nebebus spejama sincronizuot duomenu tarp serveriu.

Nes visada galima padaryti geriau :) Aš čia nešališkas ir nelabai ką suprantu, bet iš tavęs jaučiasi kažkoks pavydas, ar konkurencijos baimė.. Nežinau kaip tiksliai pasakyti net :)
Haters Gonna Hate :lol:

Ačiū už pasiūlymus!
 
Lankytojo užklausos metu puslapio generavimas užtrunka laiko. Pavyzdžiui HTML svetainei užtrunka 10 ms, o PHP turiniui 1000 ms. Visų užklausų generavimo laikas yra sumuojamas. Jeigu dienos suma neviršija 12 val. tuomet papildomai neapmokestinama. Pavyzdžiui per dieną būtų galima aptarnauti 43200 lankytojo užklausas (jei kiekviena būtų 1000 ms).

PHP aplikacijų hostinimas dvejuose regionuose vienu metu ir apmokestinamas dinamiškai.
 
Developeris gauna platformą ant kurios gali leisti savo PHP aplikaciją. Jam nereikia rūpintis infrastruktūra didėjant resursų panaudojimui. Tai atitinka PaaS apibrėžimą.
 
Taip pat siekiant, kad aplikacija greitai veiktų lankytojams iš Amerikos ir Lietuvos platforma automatiškai palaiko dvi aplikacijos kopijas. Taip gedimo viename regione metu lankytojai ir toliau galės naudotis svetaine nors ir generuojamas dinamiškai turinys. Ateityje bus galima pasirinkti kiek ir kokiuose regionuose aplikacijos kopijų saugoti.

Siūlau pasitikslinti PaaS apibrėžimą. Teiginiai nepagrįsti ir paremti klaidingu suvokimu.
Kartojantis įžeidinėjimams diskusija tapo neproduktyvi. Ačiū už išsakytą nuomonę.
 

Buvo paminėta labai daug skirtingų PaaS platformų. Teigimas, kad skirtumų tarp jų nėra yra tiesiog netiesa. Kiekviena platforma aptarnauja tam tikrą rinkos segmentą. Vienos platformos akcentuoja specifinius įrankius programuotojams, kitos siūlo atvirą platformą. Tiekėjai taip pat pasirenka specifines šalis, kuriose bus kolokuojami serveriai. Aprėpti viso pasaulio rinką yra tiesiog nepraktiška.
 
Mūsų kuriama platforma yra orientuota Lietuvai. Kol kas pritaikyta standartiniam PHP+MySQL stack. Duomenų bazė replikuojama, failai sinchronizuojami tarp JAV ir Lietuvos. Naudotis galima analogiškai kaip ir standartiniu hostingu ir nereikia rūpintis high-availability problema, tai atliekama automatiškai.
 
Vadovaujantis kolegos logika galima teigti, kad Lietuvos įmonių teikiamos hostingo paslaugos yra bevertės. Juk egzistuoja pakankamai užsienio tiekėjų, kurie siūlo identiškas ar geresnes paslaugas. Tačiau tai yra paprasčiausiai netiesa. Lietuviškos įmonės gerai supranta savo auditoriją ir gali konkuruoti su užsienio tiekėjais labai specializuotais sprendimais.
 

Net ir turint point-to-point fiber neapeinami fizikos dėsniai. Atstumtas besąlygiškai pridės latency. Kalbant apie PaaS tiekėjus jie tiesiog neturi lokalių duomenų centrų visuose taškuose.
 
Mūsų platforma nėra paprastas reverse-proxy kaip CloudFlare. Duomenys pilnai replikuojami tarp duomenų centrų, nodes gali veikti nepriklausomai.
 

Ačiū HOST321 už tavo nuomonę.
 
Mūsų platforma yra paremta geolokacijos principu, lankytojai iš LACNIC ir ARIN nukreipiami į JAV, o iš kitų regionų nukreipiami į Lietuvoje esantį duomenų centrą.
 
Minėti PaaS sprendimai nėra visiškai nemokami, tačiau gana patrauklūs. Jų trūkumas yra, kad jie nepritaikyti rytų Europos rinkai, susiduriama su dideliu latency.
 

Ne, kuriame unikalią Lietuvišką debesų platformą.

Hostingas – tai bene viena pirmųjų paslaugų atsiradusių sparčiai pradėjus plisti internetui. Iš tiesų, vos tik internetas išaugo iš šaltojo karo metu karinių užduočių vykdymui skirto DARPA tinklo į paprastam piliečiui prieinamą tinklą, atsirado poreikis dalintis informacija. Svetainių kiekis ir dydis pradėjo eksponentiškai kilti, šį fenomeną stebime iki šiol.
 
Informaciniame amžiuje kiekvieną puslapį reikia patalpinti serveryje. Vyresni kolegos ko gero prisimena 1995 metais veikusią GeoCities talpinimo paslaugą, su nostalgiją keliančiais animuotais paveiksliukais ir lankytojų skaitliukais. Deja, technologijų srityje viskas žaibiškai kinta ir po dot-com burbulo sprogimo šią monopolinę Kalifornijos bendrovę pakeitė daugelis mažų.
 
Praėjus 2 dešimtmečiams nematome jokių esminių pasikeitimų. Hostingo tiekėjai įdiegia standartines valdymo sistemas (DirectAdmin, Plesk, cPanel) ir siūlo atgyvenusią platformą, o inovacijos užstrigusios praeitame amžiuje. Marketingo sumetimais, žodelius hostingas ir svetainių talpinimas pakeitė debesų kompiuterija su neribotais resursais. Taigi, kaip iš tiesų turėtų atrodyti tas vadinamas debesų kompiuterija paremtas hostingas?
 
Mūsų požiūris į debesų platformą – tai darniai veikiantis orkestras, o ne individuali mašina su instaliuotomis standartinėmis Apache+PHP+MySQL tarnybomis. Duomenų centrams ir kolokacijos tiekėjams patiriant vis daugiau sutrikimų reikalinga darni platforma, kuri perimtų veikimą sutrikus bet kuriai sistemos daliai. Svetainės lankytojai geolokacijos principu turi būti nukreipiami į artimiausią regioną.
 
Tik tokiu būdu yra išsprendžiamos esminės problemos – latency, high availability. Projektuojant serverį kaip individualią mašiną, puslapis niekada nebus greitas ir patikimas. Kolegos, tikimės iš Lietuviškų tiekėjų sulaukti daugiau inovacijų nei kad s/hostingas/debesis/g žodžių žaismo.

Ačiū už pasiūlymus!
 
Lankytojo užklausos metu puslapio generavimas užtrunka laiko. Pavyzdžiui HTML svetainei užtrunka 10 ms, o PHP turiniui 1000 ms. Visų užklausų generavimo laikas yra sumuojamas. Jeigu dienos suma neviršija 12 val. tuomet papildomai neapmokestinama. Pavyzdžiui per dieną būtų galima aptarnauti 43200 lankytojo užklausas (jei kiekviena būtų 1000 ms).

PHP aplikacijų hostinimas dvejuose regionuose vienu metu ir apmokestinamas dinamiškai.
 
Developeris gauna platformą ant kurios gali leisti savo PHP aplikaciją. Jam nereikia rūpintis infrastruktūra didėjant resursų panaudojimui. Tai atitinka PaaS apibrėžimą.
 
Taip pat siekiant, kad aplikacija greitai veiktų lankytojams iš Amerikos ir Lietuvos platforma automatiškai palaiko dvi aplikacijos kopijas. Taip gedimo viename regione metu lankytojai ir toliau galės naudotis svetaine nors ir generuojamas dinamiškai turinys. Ateityje bus galima pasirinkti kiek ir kokiuose regionuose aplikacijos kopijų saugoti.