Tikrosios debesų platformos Lietuvoje

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.

Perpardavinėjate Amazon AWS? Ar čia tik man taip atrodo?

Perpardavinėjate Amazon AWS? Ar čia tik man taip atrodo?

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

Žodžių kratinys apie nieką.....

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

Kam kurti PaaS jei yra jau DAUG sukurtų ir tikrai labai gerų? Pradedant nuo:

AppearIQ

AppScale

AWS

Cloud Foundry

CloudControl

Google

Heroku

IBM

MC

ir DAUG DAUG kitų....o kas svarbiausia - beveik visos jos FREE.

Kad sukurti stabilę ir gerą, reikės ne vienerių metų ir LABAI DAUG finansų...

www.rackspace.com supportas pats pripažino, kad openstack'as kurį jie naudoja nėra geras sprendimas (o ten dirba profesionalų ir finansuojama tikrai ne mažai).

Be to, Lietuvoje, kad ir paleidus "cloud" tai būtų tik žodžiai....vienoje lokacijoje turint išspręsta virtualizacijos sistemą - nieko nereiškia...."cloud" tam ir yra, kad turi būti paskirstyta ne vienoje geolokacijoje o bent 2 skirtingose vietose, o dar geriau netgi kontinentuose....

Jei jau labai noras yra kažką tokio kurti, tai imti tiesiog free vmware ir daryti, su laiku susipirkti licencijas, jos tikrai nėra brangios...

Aš asmeniškai jei jau daryčiau (tikrai ne Lietuvoje) tai būtų taip:

1. PaaS sistema - jokių būdų nekurčiau savo ir neišradinėčiau dviračio - cloudstack - geresnio sprendimo kol kas nemačiau.

2. Primary storage - SolidFire (250 000lt) už ~37tb vietos, bet taip pat, geresnio sprendimo kol kas nemačiau.

3. Secondary storage - kokį tik norit

4. Serverius - pagal norą, aš asmeniškai imčiau HP tikriausiai....na bet jei tiek investuojant tai reiktų gerų analizių, gal ir IBM/DELL praeitų.

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.

Žodžių kratinys apie nieką.....

 

 

Kam kurti PaaS jei yra jau DAUG sukurtų ir tikrai labai gerų? Pradedant nuo:

 

AppearIQ

AppScale

AWS

Cloud Foundry

CloudControl

Google

Heroku

IBM

MC

 

ir DAUG DAUG kitų....o kas svarbiausia - beveik visos jos FREE.

 

Kad sukurti stabilę ir gerą, reikės ne vienerių metų ir LABAI DAUG finansų...

 

www.rackspace.com supportas pats pripažino, kad openstack'as kurį jie naudoja nėra geras sprendimas (o ten dirba profesionalų ir finansuojama tikrai ne mažai).

 

Be to, Lietuvoje, kad ir paleidus "cloud" tai būtų tik žodžiai....vienoje lokacijoje turint išspręsta virtualizacijos sistemą - nieko nereiškia...."cloud" tam ir yra, kad turi būti paskirstyta ne vienoje geolokacijoje o bent 2 skirtingose vietose, o dar geriau netgi kontinentuose....

 

Jei jau labai noras yra kažką tokio kurti, tai imti tiesiog free vmware ir daryti, su laiku susipirkti licencijas, jos tikrai nėra brangios...

 

Aš asmeniškai jei jau daryčiau (tikrai ne Lietuvoje) tai būtų taip:

 

1. PaaS sistema - jokių būdų nekurčiau savo ir neišradinėčiau dviračio - cloudstack - geresnio sprendimo kol kas nemačiau.

2. Primary storage - SolidFire (250 000lt) už ~37tb vietos, bet taip pat, geresnio sprendimo kol kas nemačiau.

3. Secondary storage - kokį tik norit

4. Serverius - pagal norą, aš asmeniškai imčiau HP tikriausiai....na bet jei tiek investuojant tai reiktų gerų analizių, gal ir IBM/DELL praeitų.

Prie ko čia Europa, JAV ir kiti kontinentai ir nepritaikytos platformos?:)

Platformos visur vienodos, o vat kad nėra point-to-point fiber'io tai čia jau tikrai ne PaaS problema:)

Kad Jūs sukursit PaaS "pritaikytą" europai (įdomu KAIP pritaikytą, ir kuo skirsis nuo visų kitų mano anksčiau išvardytų), tai dar nieko nereiškia, kadangi Jūsų redirect - elementarus CDN. Lygiai tą patį efektą galima padaryti ir su shared-hostingu ir ant viršaus "uždėjus" CloudFlare.....

Man kažkaip atrodo, kad Jūs nelabai suprantate tam tikrų terminų ir esmės.....

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.

Prie ko čia Europa, JAV ir kiti kontinentai ir nepritaikytos platformos?:)

 

Platformos visur vienodos, o vat kad nėra point-to-point fiber'io tai čia jau tikrai ne PaaS problema:)

 

Kad Jūs sukursit PaaS "pritaikytą" europai (įdomu KAIP pritaikytą, ir kuo skirsis nuo visų kitų mano anksčiau išvardytų), tai dar nieko nereiškia, kadangi Jūsų redirect - elementarus CDN. Lygiai tą patį efektą galima padaryti ir su shared-hostingu ir ant viršaus "uždėjus" CloudFlare.....

 

Man kažkaip atrodo, kad Jūs nelabai suprantate tam tikrų terminų ir esmės.....

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.

Common.....Tas pats pigiausias DigitalOcean TURI RACKUS kiekviename taške (nebūtina turėti nuosavus duomenų centrus, kad laikyti kelis šimtus serverių ir network įrangos).

Vis gi, šnekat tiek, ką perskaitėt googlėje radę. Kol kas nematau nei vieno argumento, kodėl Jūsų kuriama PaaS pranašesnė EU/USA ir t.t. :) Čia toks argumentas kad PaaS nepritaikyta Europai tai mane iš viso iš vėžių išmušė:) Kaip galima būtų pritaikyti būtent Europai?:)

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.

Common.....Tas pats pigiausias DigitalOcean TURI RACKUS kiekviename taške (nebūtina turėti nuosavus duomenų centrus, kad laikyti kelis šimtus serverių ir network įrangos).

 

Vis gi, šnekat tiek, ką perskaitėt googlėje radę. Kol kas nematau nei vieno argumento, kodėl Jūsų kuriama PaaS pranašesnė EU/USA ir t.t. :) Čia toks argumentas kad PaaS nepritaikyta Europai tai mane iš viso iš vėžių išmušė:) Kaip galima būtų pritaikyti būtent Europai?:)

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.

Prie ko čia NEPRITAIKYTA platforma Europai/Lietuvai ir kitoms šalims ir tuo labiau, specifinės šalys dėl kolokacijos - niekaip nesuprantu, prašau paaiškinti. Be to Platforma ir yra platforma, o toliau kas liečia IaaS, SaaS ir t.t. tai jau tikrai čia ne prie ko.....jei jau kuriate platformą (PaaS) tai jokio skirtumo ar tai įrankiai programuotojams ar dar kam nors. Man rodos, kad patys maišot visą *aaS.

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.

Kuom Lietuvoje skirsis platforma nuo kitų, vmware, openstack, cloudstack? Sinchronizuojami tarp JAV ir Lietuvos - wtf...Jūs 1 klientui, laikysit 2x daugiau resursų dėl tos pačios priežąsties, kurią įvardinau aukščiau (CloudFlare) naudojimo? Sinchronizuoti visą informaciją tarkim 500gb...nu čia dar nesu tokio varianto girdėjęs paprastam klientui.....Arba aš jau kažko nebesuprantu ir prašau išaiškinti, koks tikslas sinchronizuoti ir laikyti ne mažiau 2 kontinentuose tą pačią informaciją....kitaip tariant - išlaidos 2x didesnes už "nieką".

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.

Prie ko čia teikiamos paslaugos ir platforma? Lietuva labai gerai konkuruoja su visais užsienio tiekėjais, žinau ne vieną LT kapitalo įmonę, kuri dirba ir EU ir USA, bet tokio sprendimo kaip jūs teigiat - niekas nedaro ir nedarys. Tai dar kartelį pasikartosiu ir užduosiu tą patį klausimą: Kuom platforma bus pritaikyta EUROPAI ir kuo ji bus išskirtinė nuo pasaulinio žinomumo? Argumentas kad bus sinchronizuojama - tai čia tikriausiai gerai "parūkėt" kažko....

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ę.

Prie ko čia teikiamos paslaugos ir platforma? Lietuva labai gerai konkuruoja su visais užsienio tiekėjais, žinau ne vieną LT kapitalo įmonę, kuri dirba ir EU ir USA, bet tokio sprendimo kaip jūs teigiat - niekas nedaro ir nedarys. Tai dar kartelį pasikartosiu ir užduosiu tą patį klausimą: Kuom platforma bus pritaikyta EUROPAI ir kuo ji bus išskirtinė nuo pasaulinio žinomumo? Argumentas kad bus sinchronizuojama - tai čia tikriausiai gerai "parūkėt" kažko....

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ę.

Na tai paaiškinkit.

Gal aš čia kažko "apsirūkęs".....

EDIT: O gal Jūs kuriat VALDYMO PULTĄ (kitaip Jūsų vadinamą platformą)??????

O tai vienu zodziu ( na gerai, vienu sakiniu ) galite paaiskinti ka jus cia darote?

O tai vienu zodziu ( na gerai, vienu sakiniu ) galite paaiskinti ka jus cia darote?

http://www.ovh.lt/sp...rastruktura.xml

Matau čia naudojama iv.lt serveris (bent jau domenui). Ten nėra labai jau geras latency.

Bet iš esmės visai nebloga idėja. Geriau negu paprastas CDN, tačiau klausimas kaip atlaikys didesnes apkrovas.

Ypač, jeigu gerai supratau "Tereikia jiems nurodyti mūsų vardų serverius. " (citata iš puslapio) ar reikia nurodyti domeno serverio vardus? Abejoju ar sistema geriau veiks negu Cloudflare, kaip minėjo HOST321.

Taip pat klausimas, kokie portai palaikomi, ar SSL.

Ir reiktų paaiškinti plačiau ką reiškia "12 vykdymo valandų per parą."

Geriau suprasti padėtų pavyzdys. Jeigu vienam useriui dns skiriama ~200ms, tai per parą ~13k/sesijų.

Ir žinoma pamatyti esmę padėtų video klipas kaip veikai su Jūsų sistema ir be jos. Puikus pavydys -

https://www.youtube.com/watch?v=vEYKRhETy4A

Sėkmės projekte, galbūt galima ir išmėginti.

O tai vienu zodziu ( na gerai, vienu sakiniu ) galite paaiskinti ka jus cia darote?

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.

OMG, per 5000 žinučių išsiaiškinta ką ruošiamasi daryti, nu bet įvardinti "debesų platformą" čia jau AUKŠČIAU bambos šokta...Man dar klausimas kyla, ar žinoma apskritai šio termino reikšmė....

O kitas dalykas, kam kurti tai, kas jau yra sukurta? Ar bus finansų pakankamai, naudoti ištisai interneto liniją synchronizacijoms (srauto suvalgys ojojoj kiek), serverio resursų ir t.t.?

Ir reiktų paaiškinti plačiau ką reiškia "12 vykdymo valandų per parą."

Geriau suprasti padėtų pavyzdys. Jeigu vienam useriui dns skiriama ~200ms, tai per parą ~13k/sesijų.

 

Ir žinoma pamatyti esmę padėtų video klipas kaip veikai su Jūsų sistema ir be jos. Puikus pavydys -

 

Sėkmės projekte, galbūt galima ir išmėginti.

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).

O kitas dalykas, kam kurti tai, kas jau yra sukurta? Ar bus finansų pakankamai, naudoti ištisai interneto liniją synchronizacijoms (srauto suvalgys ojojoj kiek), serverio resursų ir t.t.?

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:

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:

ne pavydas, o zmogus nori issiaiskinti kodel yra naudojami zodziai ne pagal ju reiksme + ka jie cia ruosiasi daryti

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.

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.

Duomenų sinchronizacijai naudojamas eventual consistency modelis. Tai teorinė garantija, kad visi duomenų pasiekimo kanalai galiausiai gražins paskutinius atnaujinimus. Šio metodo privalumas yra, kad nevyksta skaitymo blokavimas – visos replikos išlieka pasiekiamos (high availability). Minusas, kad duomenų stebėtojui (observer) nėra garantuojama jog duomenys bus patys naujausi.

Taigi net ir aktyviai vykstant duomenų propagavimui lankytojams užkrovimo laikas nedidėja. Tai ir yra šio metodo privalumas, nes lankytojus aptarnauja serveris turintis lokalią duomenų repliką (low latency). Vienas iš tokio distributed computing modelio pavyzdžių yra DNS sistema.

Duomenų sinchronizacijai naudojamas eventual consistency modelis. Tai teorinė garantija, kad visi duomenų pasiekimo kanalai galiausiai gražins paskutinius atnaujinimus. Šio metodo privalumas yra, kad nevyksta skaitymo blokavimas – visos replikos išlieka pasiekiamos (high availability). Minusas, kad duomenų stebėtojui (observer) nėra garantuojama jog duomenys bus patys naujausi.

 

Taigi net ir aktyviai vykstant duomenų propagavimui lankytojams užkrovimo laikas nedidėja. Tai ir yra šio metodo privalumas, nes lankytojus aptarnauja serveris turintis lokalią duomenų repliką (low latency). Vienas iš tokio distributed computing modelio pavyzdžių yra DNS sistema.

Isvada tokia, kad aukojat duomenis kad pasiektumete didesni greiti... Statiniam turiniui ideja nebloga, bet dinaminiui ne tokia ir gera.

Isvada tokia, kad aukojat duomenis kad pasiektumete didesni greiti... Statiniam turiniui ideja nebloga, bet dinaminiui ne tokia ir gera.

Didžiausia šio sprendimo nauda yra dinaminiam turiniui. Statinio turinio paskirstymą galima pasiekti ir su CDN.

Šis consistency modelis yra plačiai naudojamas didžiausių pasaulio kompanijų siekiančių pasiekti highest availability. Paaiškinti kodėl joms greitis toks svarbus parašėme šį blogo įrašą.

Mūsų galutinis tikslas yra padaryti distributed computing privalumus prieinamus net ir mažiems projektams, nereikalaujant daug papildomų žinių ar kodo modifikacijų. Taip pat siekiame pateikti klientui naudingiausią utility computing kainodarą.

Didžiausia šio sprendimo nauda yra dinaminiam turiniui. Statinio turinio paskirstymą galima pasiekti ir su CDN.

 

Šis consistency modelis yra plačiai naudojamas didžiausių pasaulio kompanijų siekiančių pasiekti highest availability. Paaiškinti kodėl joms greitis toks svarbus parašėme šį blogo įrašą.

 

Mūsų galutinis tikslas yra padaryti distributed computing privalumus prieinamus net ir mažiems projektams, nereikalaujant daug papildomų žinių ar kodo modifikacijų. Taip pat siekiame pateikti klientui naudingiausią utility computing kainodarą.

Kaip ir patys paminejot, tai gali atnest naudos maziems projektams. O didesni projektai sugebes ir patys optimizuotis. Tik laikas parodis ar sugebesit ispildyt vartotoju lukescius.

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:

Gal nebejuokaujam, nebijau konkurencijos nei kiek, bet prašau naudoti terminus kurie atitinka reikšmę, o ne marketingo sumetimais. Šiuo atveju būtent apie tai ir buvo užvirusi diskusija.