Ubuntu alapokon fut az Instagram milliárd dolláros üzlete

Ubuntu

Sokan felkapták fejüket a héten arra a hírre, hogy a Facebook váratlanul 1 milliárd dollárt adott az Instagram-ért. Ez a Facebook történetének legnagyobb felvásárlása volt.

A 2010-ben indult Instagram "egy mobilos fotómegosztó szolgáltatás, amely köré valódi aktív, lojális felhasználói bázis épült ki. A szolgáltatás egyedülálló abban a tekintetben, hogy a fotókat csak telefonról lehet megosztani, webes vagy asztali kliense egyáltalán nincs. Sőt, egészen múlt hétig csupán egyetlen platformra, Apple iOS-re volt elérhető az alkalmazás, ennek fényében egészen hihetetlen a több mint 30 millióra rúgó felhasználói bázis. Az Instagram sikerét jellemzi, hogy az androidos változata egy hét alatt az ötmillió telepítést is átlépte."

"Az Instagram két fővel, az alapító Kevin Systrommal és Mike Kriegerrel indult 2010 októberében, azóta fokozatosan nőttek egyre nagyobbra, de még így is rendkívül kicsi - a nyilvános információk szerint egyébként két alapító mellett néhány mérnök dolgozik, az alkalmazottak jelentős részét azonban közösségépítéssel foglalkozó munkatársak teszik ki - ők képviselik a céget eseményeken, írják az Instagram-blogokat, vagy nyújtanak alapszintű ügyfélkapcsolatot.

Az Instagram a hatalmas felhasználói tábor kiszolgálásához az Amazon EC2 infrastruktúráját használja, így a teljes rendszer üzemeltetéséhez mindössze három mérnökre van szüksége. A rendszert kipróbált és megbízható elemekből építik, néhány házon belüli fejlesztés azért így is található benne. Az Instagram Ubuntu 11.04 alapú virtuális gépeket futtat a felhőben, terheléstől függően akár több száz csúcs-instance (High-CPU Extra Large Instance) is futhat egyszerre. Az alkalmazásréteg Djangót használ, a WSGI szerver szerepében Gunicorn működik, az adatbázis tördelt (sharded) PostgreSQL."

További részletek itt. Az Instagram itt blogolt a technikai részletekről pár hónappal ezelőtt.

( trey | 2012. 04. 15., v – 13:26 )

"We run Ubuntu Linux 11.04 (“Natty Narwhal”) on Amazon EC2. We’ve found previous versions of Ubuntu had all sorts of unpredictable freezing episodes on EC2 under high traffic, but Natty has been solid. "

--
trey @ gépház

A cloud lényege, hogy egy cég létrehoz egy nagy gépparkot és kiad bérbe erőforrásokat alapvetően kétféle dologra:
- interaktivitást igénylő terhelésekhez (változó terhelésű alkalmazás vagy weboldal)
- batch módban futó terhelésekhez (több hetes matematikai/fizikai szimuláció)

Így a géppark mindig közel 100 százalékon terhelődik. Ezt a fajta terheléselosztást nem tudom elképzelni egy cégen belül.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A bérbe adás nem technikai kérdés.
Azt, hogy egy adott erőforrást külső vagy belső "ügyfél" foglalja le, szintén nem technikai kérdés.
Az, hogy tudom, hogy hol vannak az adataim, hogyan mentik, és ki fér hozzá, na ez már egy sokkal fontosabb. Szerintem.
Egy nagyobb cégen, cégcsoporton belül, a fentiek sokkal fontosabbak, mint az, hogy esetleg pár centtel olcsóbb legyen adott szolgáltatás.
Az Instagram eddig egy mikrovállakozás volt, minden paramétere alapján. Na, ők tökéletes ügyfelei egy cloud szolgáltatónak, és így a céges létszám 10%-át nem kellett IT-re allokálniuk.
De én a magam részéről _nem bízok_ egy olyan szolgáltatásban, amiről semmit nem tudok. (És a faszbuk is itt jött nálam a képbe.)
OK, mondhatod, hogy az Amazon igen nagy jószág. Igen, az. De mindíg két példát szoktam említeni.
1) Volt egy faszi a jó USÁ-ban, aki mac-ekhez remote backup szolgáltatást adott. Mint utóbb kiderül pár figilingi géppel. Na, beszart -ha jól emlékszem a mysqlje-, és minden backup ment a levesben. Gyakorlatilag olyan szolgáltatás volt ez is, mint ma egy cloud instance.
2) Volt egy másik(2) kis amerókai cég, akik okostelefonokhoz adtak háttér szolgáltatást. Valami Sidekick volt a neve. Amíg a storage-ük be nem xart. Na, akkor izzadtak ők is (Microsoft + T-Mobile), meg a storage-os cég is (Hitachi), de legfőképpen az ügyfelek.
Ezt egy mezei ügyfél vagy kis cég bevállalja, mert nem tudja másképp megoldani, de egy nagy nem biztos. És a tapasztalat azt mutatja, hogy nem is vállalják be.
És egy nagy, ahol van pár ezer szerver, szanaszét a világban, miért ne építene magának, saját felhőt. Mint ahogy teszik is.

"A bérbe adás nem technikai kérdés. Azt, hogy egy adott erőforrást külső vagy belső "ügyfél" foglalja le, szintén nem technikai kérdés."

De akkor az nem cloud, hanem sima virtualizáció. Ha pedig bérbe adják akárki gyüttmentnek a cloud egy részét, akkor honnan lesz adatbiztonság?

"Az, hogy tudom, hogy hol vannak az adataim, hogyan mentik, és ki fér hozzá, na ez már egy sokkal fontosabb. Szerintem."

Használj titkosított fájlrendszert, titkosított adatbázist és titkosított adatátvitelt... :)

"Egy nagyobb cégen, cégcsoporton belül, a fentiek sokkal fontosabbak, mint az, hogy esetleg pár centtel olcsóbb legyen adott szolgáltatás."

Persze, de akkor nem private cloud-nak hívják, hanem saját fizikai vason saját maguk által adminisztrált virtualizációval dolgoznak, mitől lesz ez cloud?

"De én a magam részéről _nem bízok_ egy olyan szolgáltatásban, amiről semmit nem tudok. (És a faszbuk is itt jött nálam a képbe.)"

Ezt értem, de ennek nincs köze a cloud-hoz.

"1) Volt egy faszi a jó USÁ-ban, aki mac-ekhez remote backup szolgáltatást adott. Mint utóbb kiderül pár figilingi géppel. Na, beszart -ha jól emlékszem a mysqlje-, és minden backup ment a levesben. Gyakorlatilag olyan szolgáltatás volt ez is, mint ma egy cloud instance.
2) Volt egy másik(2) kis amerókai cég, akik okostelefonokhoz adtak háttér szolgáltatást. Valami Sidekick volt a neve. Amíg a storage-ük be nem xart. Na, akkor izzadtak ők is (Microsoft + T-Mobile), meg a storage-os cég is (Hitachi), de legfőképpen az ügyfelek."

Ez nem tud előfordulni akkor, ha egy cég maga üzemelteti az infrastruktúrát? Nem értem, hogy ezek miért a cloud elleni érvek...

"És egy nagy, ahol van pár ezer szerver, szanaszét a világban, miért ne építene magának, saját felhőt. Mint ahogy teszik is."

Ok, akkor kezdjük az elején: szerinted mi a különbség a virtualizált szerverpark és a cloud között?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Röviden:
- az egyik csúcsidejű terhelésre tervezett központ, amely ideje jelentős részében alig van terhelve
- a másik egy egyenletesen magas terhelésre tervezett központ, amely ideje jelentős részében 100 százalékon van terhelve

Döntsd el, hogy melyik melyik. Attól, hogy egy meglévő technológiának új nevet adnunk még nem lesz újdonság.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ne mond el senkinek! Amikor nincs terhelés egy node-on, simán lekapcsolják. Miután átmigrálták egy másik node(ok)-ra a rajta futó szolgáltatásokat.
Most ez cloud vagy VPS? ;)"

Ez irreleváns a tekintetben, hogy cloud vagy VPS.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

jol vegigolvastam a szalat, de csak azt latom, hogy a cloud es a VPS kozti kulonbseg abban all, hogy mit szamlaznak a vevonek.
javaslom, hogy az egyiket nevezzuk ezutan fitymafeknek, a masikat harangnak, de ne mondjuk meg senkinek, melyik melyik. nem lesz nagy valtozas, csak vidamabbak lesznek az errol folytatott parttalan vitak.

"Persze, de akkor nem private cloud-nak hívják, hanem saját fizikai vason saját maguk által adminisztrált virtualizációval dolgoznak, mitől lesz ez cloud?"

Attol, hogy ez a "sajat maguk" nem mindig olyan egyertelmu. Pl. adott egy bank, akinek mondjuk Nemetorszagban van egy datacentere, egesz Europabol oda csatlakoznak be a leanyvallalatok, es ott futtatjak a cuccaikat - honap vegen meg hasznalat alapjan kapnak egy szamlat.

Szerk: vagy talan megjobb pelda egy kormanyzati cloud. Csinal mondjuk a Kopint egy nagy datacentert, es fel lehet ra tolni a magyarorszag.hu-tol a felvin at az egyetemi neptunokig mindent, a maradek idoben meg mondjuk az OMSZ futtathat HPC feladatokat.

--
"You're NOT paranoid, we really are out to get you!"

"Attol, hogy ez a "sajat maguk" nem mindig olyan egyertelmu. Pl. adott egy bank, akinek mondjuk Nemetorszagban van egy datacentere, egesz Europabol oda csatlakoznak be a leanyvallalatok, es ott futtatjak a cuccaikat - honap vegen meg hasznalat alapjan kapnak egy szamlat."

Attól az még nem cloud, hogy egy helyen vannak a céges virtualizált szerverek... :)

"Szerk: vagy talan megjobb pelda egy kormanyzati cloud. Csinal mondjuk a Kopint egy nagy datacentert, es fel lehet ra tolni a magyarorszag.hu-tol a felvin at az egyetemi neptunokig mindent, a maradek idoben meg mondjuk az OMSZ futtathat HPC feladatokat."

Ez már jóval közelebb van a cloud fogalmához.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A virtualizalt szerver es a cloud megoldas egeszen mas. A virtualizalt szerverek tenylegesen szerverek kivaltasara valok. Azaz arra, hogy minel tobb gepet egyesitsenek egyben. Ennek megfeleloen a gepek szamanak csokkentes a cel.
A cloud megoldasok a skalazodasrol szolnak. Azaz egy szolgaltatas szetszorasarol SOK gep kozott. A gepek szamanak novelese es azok jo kihasznalasa a cel. A lenyeg, hogy nem foglalkozol az egyedi gepekkel hanem csak a szolgaltatas egeszevvel. A gepek uzemeltetesevel foglalkozok meg a szolgaltatassal nem torodnek.
Jo pelda erre a Google. Van rengeteg szolgaltatasuk, de ugyanazon a cloud platformon fut az egesz. Nincsenek dedikalt szerverek.
Na meg meg azt is hozzatennem, hogy a cloud megoldasnak nem feltetlenul resze a virtualizacio. Lehet maskepp is csinalni.

Értem én, de akkor az egész titkosításnak nincs értelme, mert ha fut a gép, akkor egy 0day sebezhetőséget kihasználva bejuthatnak rá és ott a teljes tartalom... szóval valahol meg kell húzni az elvárható biztonság és a paranoia közötti vonalat.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Két külön problémakör.

A hagyományos fizikai gép esetében meg van a lehetőséged arra, hogy fizikai biztonsággal védd a gépet és az adatokat a külső támadástól (fizikai védelem, biztonsági őr, műgyantával kitöltött - nem használt - PCI csatolók, chassis open sensor jelzésre vagy erőszakos felnyitás esetén kulcs felülírása, adatok törlése, panic riasztás, etc.), vagy akár a CPU regisztereiben tárolt kulcs, ha mégis sikerülne hozzáférni a memóriához (lásd. TRESOR) és így lehet értelme a teljes diszk titkosításnak, mert védhetők az adatok az ilyen jellegű külső támadásoktól. Akár a hoszting cég megtámadása, vagy konspirációja esetén is védekezni lehet így (szabotázs, vagy egy hatósági szerv kötelezi a szolgáltatót közreműködésre és a géphez való hozzáféréshez, stb. stb. stb.).

Míg egy hosztolt virtuális gép esetében nincs erre lehetőséged. A szolgáltató készít egy snapshotot a háttérben a rendszered állapotáról (memória, CPU, háttértár mentés) és abból minden rekonstruálható, visszafejthető. Hiába van titkosítva a filerendszered, a mentésben benne van a futó kernel és userland teljes memória állapota, a processzor regisztereinek tartalma, stb. Nem lehet védeni az adatokat. Mitöbb, az egész műveletről akár nem is szerzel tudomást és a rendszered már be is van rootkitezve. A futó virtuális géped memóriájában könnyedén injektálható saját backdoor kód, vagy módosíthatók, kiiktathatók a biztonsági ellenőrzéseid. Ez nem paranoia, könnyedén kivitelezhető komolyabb szakértelem nélkül is, a virtualizációs megoldások lehetőséget biztosítanak erre (lásd. VMWare backdoor interface).

Van egy nagyon jó előadás is a témában hazai szakértőktől. Lásd itt.

Én ezt mind értem, csak ha árban nézzük össze az EC2-t egy fizikai géppel, akkor a fizikai gép esetén egy pukibt hosting cég salgó polcán látunk egy PC-t különösebb fizikai védelem nélkül... és ez annyira biztonságos, mint amennyire megbízol a maszekoló operátorokban vagy a biztonsági őrökben.

Értem én, hogy a használhatatlanságig fokozható a biztonság, de se a VPS, se a cloud nem annak a kategóriának az alternatívája, amelyet leírtál az első bekezdésben...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A pukibt salgó polcára is rakhatsz egy saját gépet TRESOR patchelt kernellel és teljes diszk titkosítással, aminek nincs extra költségvonzata és mégis nagyobb biztonságban lesznek az adataid, mint egy VPS/Cloud esetén, ahol egyszerűen bármit csinálhatsz, nem tudod megvédeni azokat.

Najo, akkor most dontsuk el, hogy ez - szerinted - egy felvallalhato kockazat, es akkor hagyjuk a bohockodast a titkositott filerendszerrel, vagy nem az - akkor pedig azok a vedelmi megoldasok, amiket Hunger felsorolt, teljesen adekvatak.

--
"You're NOT paranoid, we really are out to get you!"

Szerinted azonos befektetett munkával (tudással) jár egy volume adatainak egyszerű lementése, mint egy futó virtuális gépről snapshot, majd a snapshot alapján a visszakövetkeztetni a kulcsra és azzal visszafejteni a titkosított volume tartalmát? Létezik feltörhetetlen titkosítás vagy betörésbiztos oprendszer? Ha nem, akkor a fentiek alapján minek szórakozunk egyátalán bármilyen védelemmel?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

+1 A biztonsági rendszerek célja nem az, hogy ne lehessen behatolni a rendszerbe, hanem hogy ne lehessen gazdaságosan az adott idő alatt behatolni.

Szerk. Erre nagyon jó példa az RSA. Triviális módon lehet törni, csak nagyon sok idő kell hozzá. Ami még pár éve elég védelmet adott, azt már rendkívül olcsón lehetne törni, csak már lecserélték.

A biztonsági rendszerek célja nem az, hogy ne lehessen behatolni a rendszerbe, hanem hogy ne lehessen gazdaságosan az adott idő alatt behatolni.

Ez igaz, épp ezért nem értem miért pluszegyezel. :)

Ugyanis nagyon nem mindegy, hogy egy rendszernek kapásból hozzá lehet férni a memóriájához (és ezáltal az adataihoz) és akár menet közben írni/olvasni (VM guest), vagy pedig sok tényezőtől is függ, hogy egyáltalán olvasni lehessen off-line, amely ellen szintén vannak védelmi megoldások (fizikai gép).

Egyik esetben _vannak_ biztonsági megoldások az adatok védelmére, másik esetben _nincsenek_. Az egyik esetben lehet védekezni az illetéktelen adathozzáférés ellen, a másik esetben nem lehet.

Emiatt egyik esetben _biztonságról_ beszélgethetünk (fizikai gép), másik esetben csak _bizalomról_ (VPS/Cloud). Abban bízol, hogy a szolgáltatód hoszt gépéhez nem fognak hozzáférni és onnan elérni a te guest gépedet, vagy hogy a szolgáltatód nem fogja ezt megtenni, ha erre felkérik (amely bizonyos esetekben - pl. felügyeleti szerv általi megkeresés - eléggé csalfa remény). Itt a nagy különbség. Fizikai gép esetében tudsz biztonsági megoldásokkal élni, amely az adataid védelmét szolgálják, hosztolt virtuális gép esetén erre nincs lehetőséged és minden ilyen jellegű próbálkozás (titkosított filerendszer a felhőben) mondhatni teljesen felesleges. Olyan ez, mintha nagy acélajtóval és "feltörhetetlen" zárral védenéd a lakásodat, de a kulcs benne lenne a zárban.

Ha ezt a különbséget nem sikerül felfogni, akkor nincs már miről tovább beszélni.

Bocsánatot kívánok, de fizikai gépnél is csak a bizalomról van szó, mert egyrészt nem Te _építetted_ a gép minden egyes részét, másrészt nem Te _írtad_ a hardveren futó oprendszert, se az alkalmazásokat. Egy picit máshol van a vonal, de a magad által deklarált szabályok szerint ugyanúgy a bizalomról szól, nem pedig a biztonságról.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Igen, végülis az előbb még ráadásul magad ellen is beszéltél, mert fizikai gép esetén van lehetőséged a hardvert is összeválogatni hozzá, míg VPS/Cloud esetén ebbe sincs beleszólásod. :)

A rajta futó szoftver esetében pedig nincs jelentősége, hogy egy köztes független rendszerelemként a biztonsága relatív, mert az mindkét esetben ugyanaz a rendszerelem és mindkét esetben ugyanúgy van lehetőséged azt is biztonságilag fokozni (illetve ha nincs annyi lehetőséged, az megint csak engem igazol, mert a VPS/Cloud esetében erre is kevesebb lehetőséged adódik :).

Annak van jelentősége, hogy egyik esetben LEHET az adatok megszerzése és manipulációja ellen valamennyire védekezni (irreleváns, hogy szerinted mennyire, mert a lényeg az, hogy a lehetőséged meg van rá), másik esetben meg LEHETETLEN, mert nem garantálható a *titok* - amely itt titkosító kulcs formájában jelentkezik - titkossága, titokban maradása.

Ergó felesleges VPS/Cloud esetén a filerendszer titkosításról beszélni, mint szolgáltató hozzáférésének korlátozásáról, mert nem tölti be ezt a szerepét. Nem tudod a szolgáltatódtól megvédeni az adataidat.

Bocsánatot kívánok, de én arról írtam végig, hogy mindenkinél van egy vonal a paranoia és az elvárható biztonság között (szavaid szerint a bizalom és a biztonság között). Nálad ezek szerint a vonal ott van, hogy a cloud szolgáltatóban nem bízol meg, ellenben a hardvergyártókban és a szoftvergyártókban vakon megbízol. Én mindössze erre szerettem volna rámutatni több levélváltáson át, a többi hozzáképzelt dolog már mind a saját vergődésed.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A hardver és a szoftvergyártóknál tudsz a backdoor vagy hibák ellen tenni, kisebb vagy nagyobb erőforrás ráfordítással, de TUDSZ. Ha kell, akkor auditálod vagy auditáltatod a felhasználás előtt a szoftvereket és hardvereket, vagy ha kell használsz másikat, vagy építesz egyet nulláról. Meg van a lehetőséged a választás szabadságára, kezedben van a kontroll.

Cloud/VPS esetén NEM TUDSZ semmit se tenni, mert - by concept - nem a te kezedben van a kontroll, hanem a szolgáltató kezében. Ők belelátnak és vezérelni tudják a virtuális géped processzorát, írni-olvasni tudják a memóriádat és a háttértáradat. Innentől hiába van a háttértáradon a filerendszer titkosítva, mert a titkosító kulcs is szabadon hozzáférhető számukra.

Mondogathatod, hogy 'igaz hogy a páncélajtó zárjában benne van a kulcs, de a szellőzőn át is belehetne juttatni valamit', ettől még a legnagyobb gond, a zárban-lévő-kulcs problémája továbbra is megmarad és a legnagyobb biztonsági problémának számít.

Olyan ez, mintha azt mondanád, hogy minek patchelni a hibákat a szoftverekben, úgyis marad még bennük bőven... Sőt mitöbb, minek patchelni a szoftverekben lévő hibákat, amikor a hardverekben lévő hibák is kihasználhatók.

De feladom. Úgy látom a végletekben való gondolkodásmód valamiféle népbetegség itt.

"A hardver és a szoftvergyártóknál tudsz a backdoor vagy hibák ellen tenni, kisebb vagy nagyobb erőforrás ráfordítással, de TUDSZ. Ha kell, akkor auditálod vagy auditáltatod a felhasználás előtt a szoftvereket és hardvereket, vagy ha kell használsz másikat, vagy építesz egyet nulláról. Meg van a lehetőséged a választás szabadságára, kezedben van a kontroll."

Ugyanezt egy cloud szolgáltatóval miért nem tudod elképzelni? Véges ráfordítással el tudod érni ugyanezt egy cloud szolgáltatónál is és a kezedben lehet a kontroll. Valami megakadályoz, hogy auditáld vagy elfogadj egy auditált rendszert?

"Cloud/VPS esetén NEM TUDSZ semmit se tenni, mert - by concept - nem a te kezedben van a kontroll, hanem a szolgáltató kezében."

Egyszerűen nem értem, mi a lényeges módszertani különbség egy auditált oprendszer és üzemeltetési folyamat, illetve egy auditált cloud szoftver és üzemeletetési folyamat között. Mi az, ami miatt az egyikben hiszel, a másikban nem. Komolyan nem értem.

"Olyan ez, mintha azt mondanád, hogy minek patchelni a hibákat a szoftverekben, úgyis marad még bennük bőven... Sőt mitöbb, minek patchelni a szoftverekben lévő hibákat, amikor a hardverekben lévő hibák is kihasználhatók."

Bocsánatot kívánok, de te mondod ezt: minek titkosítani a fájlrendszert, amikor a memória snapshotból ki lehet nyerni a privát kulcsot... látszólag neked ez az elvi hozzáállásod: minek bezárni az ajtót, ha be akarnak törni, úgyis betörnek. Ugyanazokat az érveket hozod fel, amelyek ellen védekezel egy másik absztakciós szinten...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

igazabol te vergodsz, mivel mondtal az elejefele egy eleg nagy marhasagot (titkositott ezmegaz cloudban), es azota sem sikerult ezt beismerned, sot aztan rateteztel meg tobb marhasaggal ;). pl. most sikerult szembeallitani a cloud vs. sw/hw gyartokban torteno megbizast, mintha a cloud eseten mar el is lehetne felejteni az utobbit. hat pech, de nem lehet. amit Hunger magyarazni probalt, az arrol szol, hogy a cloud eseten eggyel tobb ismeretlen tenyezod van *es* (ami sokkal rosszabb) *nulla* kontrollod van felette, ellentetben a tobbi tenyezovel. ez a nulla kontrol az, ami miatt a titkositas *semmit* sem er.

"igazabol te vergodsz, mivel mondtal az elejefele egy eleg nagy marhasagot (titkositott ezmegaz cloudban)"

Nézd, én leírtam többször, hogy értem a problémát, ahogy azt is, hogy bármikor korlátlanul tovább lehet vinni a bizalom vs biztonság fogalmát... ez egy határvonal, amelynek fekvése láthatóan teljesen szubjektív alapokon nyugszik...

"amit Hunger magyarazni probalt, az arrol szol, hogy a cloud eseten eggyel tobb ismeretlen tenyezod van *es* (ami sokkal rosszabb) *nulla* kontrollod van felette, ellentetben a tobbi tenyezovel. ez a nulla kontrol az, ami miatt a titkositas *semmit* sem er"

Ok, most szépen bebizonyítottad, hogy _bármilyen fokú_ védelem tulajdonképpen _semmit_ nem ér, mert gyakorlatilag mindig lesz olyan komponens, amelyre ilyen szintű általánosítással _nulla_ kontrollod van.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Max a hype fog körülötte elcsendesedni, de eltűnni nem fog, mert van létalapja.
Viszont az olyan érvelések tetszenek, hogy takarítsunk meg energiát, ne üzemeltess szervertermet, tegyél mindent a felhőbe... Na igen, de oda is kell energia, tehát csak igazából máshova lokalizáltad az energiafelhasználást.
Asszem pont tegnap olvastam, hogy a Greenpeace meg pereli a nagy felhőszolgáltatókat, merthogy zabálják az energiát :).
--
Discover It - Have a lot of fun!

"Na igen, de oda is kell energia"

Csak nem mindegy, hogy mennyi. Gondolom te is lattal mar mersekelten korszeru ("amig mukodik, nem szabad hozzanyulni"), jellemzoen a p.cset logato vallalati szervert. :)

"Asszem pont tegnap olvastam, hogy a Greenpeace meg pereli a nagy felhőszolgáltatókat, merthogy zabálják az energiát :)."

A greenpeace idiotak gyulekezete. Ezzel remelem, nem mondtam ujat.

--
"You're NOT paranoid, we really are out to get you!"

De nézzük sorjában.
1) Ubuntu felhő rlz!
2) Majd lecseng.
3) De ez arra pont jó.
4) Persze, akinek mind1, hol vannak az adatai.
5) Mi köze a felhőnek a fb-hez?
6) Aki faszbukozik, pont annyira nem érdekli az adatainak a biztonsága, mint aki public cloudba hajlandó feltölteni. Én a magam részéről nem osztok meg adatot. De kinek a pap, kinek a plébános. (The End)

"Talán az lehet, hogy te sem akarod magad szopatni."

Ööö... izé... a saját (fizikai) szerveremen FreeBSD van... eléggé régóta. Így nem értem, hogy hol szopatom magam. :)

Egyébként van kész FreeBSD instance EC2-ben, használtam is arra, hogy upgrade-et próbáljak ki, de ahhoz, amire használtam, megfelelőbb volt egy RHEL.

"Az Amazon állja azt?"

Minthogy van Windows instance is, illetve mindenféle fizetős szoftverrel instance: igen, de beleépíti a használat díjába.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Arra próbáltam utalni finoman, hogy FreeBSD Amazon EC2 támogatása még eléggé kiforratlan."

Nyilván ezért használok RHEL-t EC2-ben, mert FreeBSD+EC2 nem bírta jópár hónapja az erős terhelést, nekem meg terheléses tesztekre kellett (cluster működés tesztelésre). De nem csak a FreeBSD támogatása (volt) kiforratlan:
"We’ve found previous versions of Ubuntu had all sorts of unpredictable freezing episodes on EC2 under high traffic"

RHEL és CentOS évek óta gond nélkül terhelhető EC2-ben... szóval? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Az Ubuntu ahhoz képest, hogy alig 6 éve létezik, keményen ott van a cloud bizniszben. Miközben más OS-ek / disztrók csak gyenge próbálkozások ebben a történetben."

Tehát azért, mert a RHEL, a CentOS és csomó egyéb disztribúció meg oprendszer előbb volt stabil az EC2-ben komoly terhelés alatt, az alátámasztja azt, hogy az Ubuntu nagyon ott van a cloud bízniszben, pedig tavaly még nem bírta a terhelést? Én kérek elnézést... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( ezqgtouvszfgc | 2012. 04. 15., v – 21:30 )

nem kellett felkapnia senkinek sem a fejét (lásd board tagok, és volt marketing igazgató)

( vtechun | 2012. 04. 16., h – 03:42 )

Egyebkent csak nekem nem jon at az "instagram-erzes"?

Rohadt nagy tevedesben vagytok, nem az alkalmazas vagy a ceg er 1 milliardot, hanem annak a 30-40 millio usernek a napi aktivitasa akik hasznaljak azt az alkalmazast. Ezt vette meg a Facebook, a kodbazis es az infrastruktura csak a szukseges rossz es tokeletesen irrelevans.

---
pontscho / fresh!mindworkz

+1

... és páran azt is mondják, hogy a Facebook nevetségesen primitív képkezelése mellett az Instagram tudott volna egy képmegosztás alapú social network lenni, ezért konkurens volt

...

kicsit "nyújtózkodó" elképzelés, de tény, hogy amikor kettő perc alatt át tudok regisztrálni a facebook ID-mmal egy másik network-re, és 3 perc alatt be tudom építeni a napi szokásaim közé, elég veszélyes azt hinni, hogy bármi is maradandó. Lásd még myspace.

( cadmagician | 2012. 04. 16., h – 16:33 )

valaki kiszálmolta már hogy mit érdmes kludba tárolni? ott futtatni? milyen tárhely árak vannak, esetleg forgalomért mit kérnek... szerintem annyira nem olcso az.

Cloudba olyasmit érdemes tenni, amelynek a terhelése igen változatos akár egy napon belül is, mert csak a pillanatnyilag használt erőforrásokért kell fizetni. Ha csak egy gép kell, akkor felejtős a cloud, akkor van értelme, ha legalább egy gép kell, de néha kell 10-100-1000 CPU... Tipikusan például a felvi.hu terhelésprofil cloud architektúráért kiált: normál esetben a kutya se nézi, de a felvételi időszakban kap terhelést, amely meredeken emelkedik a felvételi időszak végéig, majd a ponthatárok kihirdetése után a "végtelenbe" tart, közben a regionális hatás miatt a hajnali terhelés közel nullára esik minden nap.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home