Nowy cennik Google App Engine. Deweloperzy są zdesperowani: kogo będzie na to stać?

Google oficjalnie poinformowało o osiągnięciu przez chmurę App Engine pełnej dojrzałości. Oczywiście usługa działała „pełną parą” już od wielu miesięcy, jednak od połowy września zniknie z niej etykietka „preview” – i wprowadzony zostanie nowy cennik. Właśnie ta kwestia spowodowała zbiorowy płacz programistów, którzy zdecydowali się budować swoje aplikacje na chmurze Google'a. „Widziały gały co brały”? Na pewno nie, takich podwyżek cen nie spodziewał się nikt.

Google pod wodzą Larry'ego Page'a poczyna sobie śmiało. Czas na dywersyfikację dochodów, a App Engine musi stać się przynoszącą zyski usługą. W nowym modelu płatności dla GAE, zapłacimy za „instancję”, zdefiniowaną jako „małe wirtualne środowisko do uruchomienia kodu, z zarezerwowaną mocą obliczeniową i pamięcią”. Można założyć sobie Konta Premium, pozwalające na uruchomienie tylu aplikacji, ile się chce (za 500 dolarów miesięcznie) i Konta Płatne (za 9 dolarów od aplikacji). W zamian płacący dostaną umowy SLA, a abonenci kont Premium – dodatkowo „wsparcie operacyjne”.

Biedniejsi będą mogli wciąż pobawić się za darmo na GAE, ale ich aplikacje będą ograniczone do jednej instancji, z wliczonym w to gigabajtem ruchu sieciowego.

Przedstawiono także narzędzie, pozwalające policzyć, ile teraz hosting aplikacji na GAE będzie kosztował. Gigant nie owijał w bawełnę – „większość płacących klientów czekają podwyżki. Podczas fazy Preview, mogliśmy ustalić ile kosztuje utrzymanie produktu i jakie są typowe wzorce jego wykorzystania. Zmieniamy ceny, ponieważ GAE będzie teraz pełnym produktem Google'a i musi mieć możliwy do utrzymania model biznesowy na najbliższe lata”.

Reakcje programistów były w zasadzie identyczne – gniew, narzekania, zgrzytanie zębów. Niektórzy z autorów komentarzy na liście dyskusyjnej App Engine dali wręcz do zrozumienia, że zostali zmuszeni do opuszczenia GAE. Cennik Google'a jest dla nich nie do zniesienia – np. Raymond C. napisał, że po wprowadzeniu nowych cen, jego miesięczne wydatki wzrosną o 310% z 900 do 2850 dolarów. Użytkownik joakime wspomniał o podwyżce rzędu 2800%, zaś Jason Collins napisał – „koszty nam wzrosną z 5400 dolarów miesięcznie do 26500 dolarów miesięcznie (Python) – i to tylko za jedną z naszych aplikacji”.

Jak widać, określenie „czekają podwyżki” było łagodnym eufemizmem. Co deweloperzy, którzy nagle znaleźli się na krawędzi bankructwa, mogą zrobić? Wielu odgraża się, że przeniesie swoje aplikacje do Amazonu, na chmurę EC2. Sęk w tym, że taka migracja nie jest łatwa – wymaga w praktyce przepisania aplikacji z unikalnej architektury platformy Google'a na w sumie „normalne”, serwerowe instancje Linuksa, uruchamiane w chmurze Amazonu.

Najgorsze w tym wszystkim jest to, że o skali podwyżek poinformowano dopiero dwa tygodnie przed ich wprowadzeniem. Po prawdzie Google wspominało już podczas majowej konferencji I/O, że ceny na Google App Engine pójdą w górę, ale towarzyszyły temu uspokajające komunikaty, że nie będzie tak źle. Zapowiedziano, że pojawi się narzędzie pozwalające wyliczyć różnice w cenie, i że trzeba na narzędzie poczekać. Programiści pokornie czekali, czekali – i doczekali się go w momencie, w którym jeśli się nie zgodzą na nowy cennik, to praktycznie nie mają już szans, by przepisać swoje aplikacje na inne platformy i zachować ciągłość ich działania.

Niektórzy zaciskają zęby i mówią, że pozostaną na GAE, ponieważ koszty migracji byłyby ogromne, a oszczędności z przejścia na inne platformy wcale nie takie wielkie. Będą musieli się pogodzić z tym, że ich zyski tak stopnieją. Jednak cała sprawa to mocny komunikat dla nowych klientów: trzymajcie się z dala od Google App Engine. Co bowiem było największym problemem z GAE? Oczywiście vendor lock-in. Wybierając Google, zostajemy na łasce Google już na zawsze.

źródło: theregister.co.uk, code.google.com

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

57 skomentuj »

Komentarze

#1 Kamil Gałuszka 2011-09-02 09:52:33 0
Autor nieco się myli, co do sprawy, że developerzy nie mają jak się przenieść z infrastuktury Google.

Nie ma problemu nawet jutro przenieść aplikacje z GAE

Takie projekty jak:

AppScale http://code.google.com/p/appscale/

Czy Typhoonae:

http://code.google.com/p/typhoonae/

Pozwalają na hosting na SDKu Google na swoim serwerze(nie ważne czy to Amazon EC2 czy własny dedyk). To już dziś jest możliwe, że na teraz hostuje na Google App Engine a jutro na EC2 ewentualnie natkniemy się tylko na niewielkie niekompatybilności ale jako projekty OpenSource możemy sami ewentualnie szybko napisać poprawki do takich rzeczy.

Zatem sama migracja to nie jest problem. Problemem jest Google które niestety może utracić sporo użytkowników. To nie jest aż tak zamknięty ekosystem chmury jak się niektórym wydaje. Bo ludzie już wcześniej przygotowali narzędzia na ucieczkę. Tak na wszelki wypadek ;) taki jak teraz.
IP: 31.174.142.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/10.04 Chromium/13.0.782.218 Chrome/13.0.782.218 Safari/535.1
#2 that 2011-09-02 10:01:51 0
"Don`t be evil"? ;)

Zadziwiające, że są jeszcze tysiące ludzi, którzy nadal sądzą, że Google to firma inne niż wszystkie.
IP: 89.174.38.[...] Mozilla/5.0 (X11; Linux i686; rv:2.0.0) Gecko/20100101 Firefox/4.0
#3 eimi^® 2011-09-02 10:07:04 0
@Kamil Gałuszka: to opinia ludzi, którzy utrzymywali swoje projekty na GAE. Ja niewiele sam mogę powiedzieć, bo choć założyłem sobie konto tam, to tylko dla zabawy z Pythonem.

Z alternatyw: jest np jeszcze chmura PaaS Stackato od Active State dla Pythona, no ale w praktyce, jak przejrzałem materiały, nie ma za wiele udanych historii takich migracji. Pewnie można... ale może się to nie opłacać.
IP: 217.115.137.[...] Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
#4 Sceptyk 2011-09-02 10:21:32 0
Najbardziej zdumiewające w tym wszystkim nie są ceny, ale ludzie, którzy oparli modele biznesowe o bezpłatne usługi lub usługi których cen nie znali.
IP: 83.21.169.[...] Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
#5 murwazy^® 2011-09-02 13:41:01 0
Sceptyk - dokladnie! ludzie pchaja sie w wersje "beta" i "preview" a pozniej jest placz.
IP: 89.79.188.[...] Opera/9.80 (Windows NT 6.1; U; pl) Presto/2.9.168 Version/11.51
#6 WebDev^® 2011-09-02 15:06:09 0
App Engine to dobry hosting, dla kogoś kto chce małą stronę w Java Servlets/JSP ewentualnie z jakimś prostym frameworkiem typu Apache Struts. Mi do czasu pojawienia się App Engine brakowało taniego hostingu Javy, zwłaszcza że można było taki znaleźć dla PHP i Pythona. Szkoda tylko, że Google trochę zbyt mocno odeszło w App Engine od standardowego kontenera i wprowadziło API Kont Google kosztem standardowego uwierzytelniania Realm. Drugi mankament to słaby menadżer bazy danych. Myślę że tym którzy chcą odejść od języków dynamicznych w aplikacjach internetowych App Engine z Javą i Go się spodoba.
IP: 80.55.85.[...] Mozilla/5.0 (X11; Linux x86_64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
#7 HTD 2011-09-02 17:46:00 0
@WebDev®:

A w jakim celu miałby ktoś odchodzić od języków dynamicznych w aplikacjach internetowych? Niech zgadnę - wspólne fragmenty dla serwisów www i aplikacji np dla Androida? Czy jest jeszcze jakiś inny powód?
IP: 87.207.172.[...] Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 Iceweasel/5.0
#8 iga 2011-09-02 18:06:32 0
"zdesperowani"? proszę sprawdzić co to słowo znaczy.
IP: 77.65.40.[...] Opera/9.80 (Windows NT 6.0; U; pl) Presto/2.6.30 Version/10.62
#9 WebDev^® 2011-09-02 18:23:29 1
@HTD

Powodów jest całkiem sporo:

1. Języki statyczne jak Java albo C# są bardzo popularne wśród programistów. Jeśli wziąć pod uwagę ofertę firm hostingowych to hostingu dla języków dynamicznych jest nieproporcjonalnie za dużo, albo dla statycznych za mało.

2. Aplikacje napisane w języku statycznym za zwyczaj działają szybciej.

3. Statyczność języka wymusza od programisty większe skupienie się na typach danych podczas pisania aplikacji, zatem mamy więcej błędów kompilacji a mniej błędów wykonania. Wczesne wykrywanie błędów jest zatem lepiej realizowane przez języki statycznie typowane (zwłaszcza jeżeli weźmie się pod uwagę języki dynamiczne z luźną kontrolą typów jak JavaScript, podaj wynik np. var x = '4.0'/7*false)

4. Niektóre języki dynamiczne jak np. Python lub JavaScript nie mają ważnych mechanizmów ochrony np. modyfikatorów protected i private. Wiem, że można je emulować, ale po co emulować skoro mogłyby być zaimplementowane w prostszy sposób, a ten kto chce zawsze może ustawić wszystkie metody na public.
IP: 80.55.85.[...] Mozilla/5.0 (X11; Linux x86_64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
#10 jacek2v^® 2011-09-02 19:33:25 0
Mhh nie zauważyłem aż tak poważnej zmiany w cenniku - 28x!!!

Zapewne trzeba będzie zoptymalizować aplikacje. Jedyna ewentualność jaka przyszła mi do głowy co do tak wysokiej zwyżki ceny to gdy ktoś używa GAE np. do liczenia BitCoinów lub łamania haseł albo hostowania pirackich (i nie tylko) plików :)

Wg mnie niektóre koszty zmaleją, np.tych co używali backendów.
IP: 77.255.255.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.218 Safari/535.1
#11 slawek22 2011-09-03 16:25:06 -1
Co do artykułu - moim zdaniem jeśli ktoś ma do dyspozycji setki darmowych i wolnych rozwiązań a sprzęt jest za pół darmo i godzi się na to, żeby swoją aplikację wpakować w chmurę czym na zawsze uzależnia się od rozwiązań i humorów jednego dostawcy - to niech płaci podatek od głupoty.

Z resztą wystarczy spojrzeć na cenniki dostawców. 45 centów za miesięczne przechowywanie gigabajta danych. Za tyle to można mieć cały serwer z 2 TB pojemności dyskowej, 4TB transferu i 4 rdzeniami. Nic dziwnego, że jelenie płaczą skoro to co można mieć "normalnie" za 50 dolców w "chmurze" kosztuje 10 albo 20 RAZY tyle.

Dodatkowo jest drugi problem, jeśli dostawca uzna że usługa jest niezgodna z jego AUP to praktycznie oznacza śmierć usługobiorcy... bo co zrobią, przepiszą witrynę w jeden wieczór? Może będą się modlić, że zadziała jakieś automatyczne narzędzie do migracji?

Centralizacja zawsze jest zła. Gdyby google zaczynał od chmury to dzisiaj albo by go nie było albo jakiś dostawca hostingu miałby całkowitą władzę nad firmą. Zawsze można powiedzieć, że nasz projekt będzie zbyt mały, żeby kogokolwiek obchodził... ale to chyba się kłóci z założeniem chmur które podobno mają być przeznaczone na duże projekty.

@Webdev: w językach dynamicznych pisze się o wiele szybciej, podczas gdy miesięczna dzierżawa serwera kosztuje tyle ile godzina pracy programisty to nad czym się zastanawiać? Go... pisałem trochę, straszna niedoróbka. Po wysokopoziomowym C spodziewałbym się np. jednej klasy do obsługi stringów a nie 4 i ciągłego rzutowania typów. To samo tylko lepiej zrobię w zwykłym C++ / STL i mam pewność, że ktoś to będzie łatał i rozwijał.

Dzisiaj najważniejszy wskaźnik to prędkość wdrożenia. Jak ci nie pasuje prędkość kodu to piszesz te 5% które wolno działa w C.

JavaScript i modyfikatory protected / private... to jest zupełnie inny model i dawno nie czytałem takiej głupoty. To nie żadna "emulacja" prot/priv tylko inna realizacja pewnej koncepcji a jak toś nie umie to znaczy, że po prostu nie umie a nie język jest zły. To tak jakbyś stwierdził, że maluch jest lepszy od ferrari bo ci nie pasuję stare fotele.

Dziwne, że niby pracujesz z JS a nie dostrzegasz, że prot/priv służy tylko i wyłącznie do jednego... czyli realizacji enkapsulacji obieków, z resztą JS robi to o wiele lepiej i dzięki porzuceniu tego idiotycznego modelu protected/priv możesz enkapsulować praktycznie dowolny fragment kodu, nie wprowadzając w nim żadnych zmian. Pokaż komentarz
IP: 83.4.29.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.218 Safari/535.1
#12 adi_82^® 2011-09-03 16:51:22 0
Hym... A ja planowałem w całości się przenieść w sfere googla a tu taki zonk....

Nie wiem czy google nie wymanewrowal spolecznosci, bo przecierz ten caly Google Project Hosting to wrecz wykorzystanie sily i mozliwosci open source. Tam jest multum tych narzedzi Google sam nigdy by ich nie stworzyl predzej by sie zesral. I tak pewnie zrobil to z wrazenia jak szybko to sie rozroslo i jakie narzedzia developerskie stworzylo, tego jest multum, a jedyne co to to polaczyc i skleic i wszystko rzecz jasna pod App Engine ;-| dla googla.

No dobra ale gdyby tak sie wypiac na googla? Powiedzmy sobie ze przejscie do konkurencji nie dokonca wchodzi w gre bo oni tez z dnia na dzien moga to zrobic.

Zdecydowanie zbyt malo jeszcze jest tego na rynku. Skoro tak spolecznosc open source ktos tak potrafi poprowadzic to powinien juz drugi taki sie znaleźć ktory by ja skierowal na odpowiednie tory zeby ja uniezaleznic od jakis koncernow, jesli chodzi o hosting.

No bo tak mamy w OO swoje biblioteki, narzedzia, edytory(eclipsy itp), nawet system, przeniesc tego Open offica na przegladarki, jakos skleic to z sourceforge. net, skumulowac kapital pod jakas fundacja - Apache? moze, nie wiem. Ale skoro do tej pory tyle sie udalo (w tym wikipedia) to moze i to sie uda..... ta otwarta chmura technologiczna bazujaca na reklamach i przyzwoitych cenach za hosting, bo wiadomo ze z hostingiem to nikt za darmo tego nie robi....

Tylko pytanie gdzie takie cos zorganizowac ? na wyspie jakiejs? ;) trzeba tu drugiego Stelmana, szkoda ze nie ma takiej mozliwosci dobrowolnego podlaczenia swoich serwerow do takiej sieciowej wolnej chmury rozproszonej po calym swiecie, i zeby bylo to wydajne, ale i ciezkie do zorganizowania. Wiem tak sobie gdybam i bujam w oblokach... ale nie podoba mi sie to ze Google, Microsoft, Amazon i moze jeszcze ktos w przyszlosci zdominuja chmury i kiedy uzaleznia firmy od swoich produktow to podniosa ceny ....
IP: 77.253.223.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.124 Safari/534.30
#13 adi_82^® 2011-09-03 17:04:18 0
" żeby swoją aplikację wpakować w chmurę czym na zawsze uzależnia się od rozwiązań i humorów jednego dostawcy - to niech płaci podatek od głupoty".

@slawek22 Tyle ze te chmury to fajna rzecz, jest wszystko latwiej zorganizowac, masz baze uzytkownikow gmaili i aplikacje ktore uzywaja - przez GEA mozna tym dobrze zarzadzac, i łatwiej sie rozpromowac. To cholernie uzyteczna rzecz co sprawia ze nie ze wszystkim mozna sie przeniesc....
IP: 77.253.223.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.124 Safari/534.30
#14 slawek22 2011-09-03 17:33:07 -1
No widzisz, narzędzia są, sprzęt jest... nie rozumiem po co jakaś fundacja? Można sobie kupić VPSa za 50 złotych albo dedyka za 150, instalować tam co się chce a maszyna starczy przynajmniej na kilka milionów PV dziennie.

Jak ktoś jest tak głupi albo tak skąpy, że uzależnia cały swój biznes od jednego dostawcy bo nie ma paru stówek na admina albo 50 złotych miesięcznie na cpanel... to sorry. Tacy zawsze wpadną w Vendor Lock-in obojętnie czego byś im nie dawał. Jeśli ktoś wierzy, że jeśli istnieje jeden dostawca na świecie który może dostarczyć mu towar i ten dostawca będzie go traktował uczciwie i nie wykorzysta swojej dominującej pozycji - to jest skończonym idiotą. I taka opinia nikogo nie obraża, to fakt który powinny rozumieć dzieci z podstawówki!

Skończyła się (albo się kończy) era Mainframe-ów, za 5 lat się skończy era chmur. Przedtem wielu idiotów zbankrutuje, paru w porę ucieknie a ludzie przekonają się, że wolność wyboru dostawcy jest warta więcej niż jakiś świecący panel albo inna zabawka. Zawsze się docenia to co się ma dopiero wtedy kiedy się to straci.

Chmury i MF to dokładnie jedno i to samo. Wielkie, scentralizowane, kobylaste środowiska o zerowej elastyczności. Kto to widział, żeby np. logi i krytyczne dane traktować tak samo i płacić za ich obsługę 45c per GB/miesięcznie. Z resztą model biznesowy jest taki sam, czyli uniemożliwienie użytkownikom migracji, jedynie platformę zmieniono z sprzętowej na softwareową.

http://www.chip.pl/artykuly/trendy/2010/12/swiat-wedlug-microsoftu

Dziwne, że chmury jakoś tak od razu się kojarzą z MF... ale "oczywiście jest inaczej" i "są ekonomiczne korzyści"... to chyba pierwsze w historii udokumentowane ekonomiczne korzyści monopolu :)

Wiem, że taki panel do zarządzania jest dobry ale:

1. ile razy dodajesz, usuwasz, zmieniasz środowisko aplikacji? Raz rocznie?

2. Jak ci się nie chce a na admina nie masz kasy to są normalne panele dla resellerów. Jest ograniczenie do jednej maszyny ale dziś za bardzo małe pieniądze możesz mieć bardzo dobrą maszynę. Pokaż komentarz
IP: 83.4.29.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.218 Safari/535.1
#15 jacek2v^® 2011-09-04 09:48:59 0
@slawek22:"do dyspozycji setki darmowych i wolnych rozwiązań "

Jeśli chodzi o GAE to ja nie znalazłem konkurencyjnej oferty jeśli chodzi o API i dostępną moc. Czy możesz podesłać parę namiarów na porównywalne hostingi - z tych setek "darmowych i wolnych rozwiązań"?

@slawek22:"Za tyle to można mieć cały serwer z 2 TB pojemności dyskowej, 4TB transferu i 4 rdzeniami." Za 45 centów/msc!!! - nie daj się prosić koniecznie podeślij namiar !!! Za taki dyskont jestem wstanie pomęczyć się i oprogramować HA.

@slawek22:"bo co zrobią, przepiszą witrynę w jeden wieczór? "

A co zrobią jak hosting "darmowy i wolny" lub tani zwinie interes? Przepiszą witrynę - czy też przeniosą te giga-tera bajty - w jeden wieczór?

@slawek22:"Centralizacja zawsze jest zła. "

Podobno gdyby nie centralny układ nerwowy to i nas by nie było :) A co z CPU? :) Generalizujesz, a prawda - jak zawsze - jest po środku.

@slawek22:"Zawsze można powiedzieć, że nasz projekt będzie zbyt mały, żeby kogokolwiek obchodził."

Gorzej jest w zwykłym hostingu, bo mniej go obchodzi marka. Więksi mają choć SLA - chociaż to tak naprawdę niewiele.

@slawek22:Siejesz klasyczny FUD. Rozumiem, że najprawdopodobniej nie potrzebujesz chmury bo masz czas na zajmowanie się sprzętem, systemem operacyjnym, nie potrzebujesz dużej mocy i pewności działania. Dobrego API i skalowalności bez programowania. Ale nie usprawiedliwia to jednostronności i braku obiektywizmu. Są tacy co potrzebują dobrych chmur. Dzięki temu zmniejszają nakłady na administrowanie i inwestycje w sprzęt. Ja mogę się skupić na projektowaniu i programowaniu aplikacji, a nie na walkach z infrastrukturą. Jedynie muszę kontrolować koszty :) - ale to przy każdym projekcie i tak trzeba robić.
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#16 jacek2v^® 2011-09-04 10:00:59 0
@slawek22:"Dziwne, że chmury jakoś tak od razu się kojarzą z MF"

Mnie to nie dziwi. Ewidentnie mieszasz politykę (której nienawidzę:)) z technologią i biznesem.

Najlepszym lekarstwem jest wkroczenie na grunt konkretów i podanie realnych alternatyw.

Np. VPSy nie są alternatywą dla GAE. Jak pada VPS to pada Twoja cała aplikacja. Musisz zadbać o HA. W GAE jak pada Twoja instancja, podnoszona jest automatycznie nowa. Gdy potrzebujesz większej mocy przy VPS musisz sam oprogramować uruchamianie nowych VPS. W GAE dzieje się to automatycznie.

A propos vendor-lock-in, są frameworki , które umożliwiają uruchomienie aplikacji na GAE i gdziekolwiek indziej (np.web2py bez użycia API GAE). Są też podobno rozwiązanie na których można odpalać aplikacje z użyciem APIS GAE: AppScale ale nie testowałem, ktoś wspominał na forum.

Nie ma co jęczeć tylko trza się brać do roboty. Jak gugiel przestanie się podobać to znajdzie się ktoś, kto zaproponuje alternatywę i tyle - taki jest biznes. Bo biznes to nie konsumenci - tego nie będę teraz rozwijał, jakby ktoś chciał to wyjaśnię :)
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#17 slawek22 2011-09-04 11:23:40 0
Oczywiście miałem na myśli 45USD za 100GB miesięcznie.... gdzieś mi wcięło, czyli za 45USD :)

Przenoszenie jest o wiele szybsze niż przepisywanie aplikacji. Poza tym, jaka duża serwerownia ostatnio zwinęła interes.

Frameworki umożliwiające ominięcie vendor lock-in... piszesz, że podobną są i podobno umożliwiają. Niezbyt dobry sposób na podejmowanie decyzji biznesowych :) Poza tym myślisz, że jak zmienisz FW to kod będzie dalej działał? To niesłychane... tzn. zmienisz sobie np. Zenda na Cake albo MFC na WinForms i już :)

Myślisz, że ktoś ma czas na czekanie aż ktoś sklonuje jakiś idiotyczny engine cloud. No to dobra... google podwyższa ceny 20 razy, gdzie alternatywa. Można przepisać (przy tak kolosalnych kosztach to prawdopodobnie nawet zespół programistów dość szybko się zwróci). Przecież gdyby była alternatywa to 90% firm które teraz jest na GAE podkupuje innym firmom najlepszych adminów i się stamtąd wynosi w 2 dni.

Ja potrzebuję dużo mocy, dużo ramu ale TANIO. VPS-y moim zdaniem na dzień dzisiejszy nie są alternatywą dla niczego. Jak już pisałem 45-55 USD/m masz 4-8GB RAM, 4 CORE, 2 TB dysku i 2-4TB transferu. Znajdź mi taki VPS, albo taką chmurą (to już w ogóle śmiech, bo co za to dostanę? 20GB na dysku, moc obliczeniową starego celerona i pół giga ramu?). Po prostu oprogramowanie do tego jest tak cholernie drogie, że przewyższa niekiedy wartość sprzętu, stąd żaden VPS ani żadna chmura nie może konkurować cenowo z dedykiem.

Co do mocy, już nie mówiąc o tym, że w jakichś Hetznerach czy serverloftach masz więcej niż jakakolwiek średnia firma będzie kiedykolwiek potrzebować za 100-150 euro miesięcznie to na przykład w http://wwx.pl/VBr możesz mieć 6 core i 100 GB ram za parę groszy.

Fully managed masz za dodatkowe $200 miesięcznie. W firmie mamy adminów których żadna chmura nie zastąpi.

Poza tym ty siejesz FUD. Myślisz, że chmura to coś co sprawi, że wystarczy włączyć instancje i się aplikacja "przeskaluje" w locie. To totalne bzdury i tak jest potrzebny dodatkowy kod. Tak samo, z padem instancji. Jak ci padnie instancja bazodanowa to i tak będzie prawdopodobnie wymagana interwencja admina. Więc nie opowiadaj bajek. To nie jest tak, że to jakaś magiczna technologia i jeśli np. masz padnięty RAM i ci się posypie baza to dane w jakiś automagiczny sposób "naprawi chmura".

Chmury to po prostu HA, jakiś idiotyczny panel a reszta to dokładnie to samo, tylko za kilku(dziesięcio) krotnie wyższą cenę.

Mniejszy hosting mniej obchodzi marka - to pokaż mi taki który podniósł ceny 20 razy.
IP: 83.4.26.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#18 jacek2v^® 2011-09-04 15:08:55 0
@slawek22:"Frameworki umożliwiające ominięcie vendor lock-in... piszesz, że podobną są i podobno umożliwiają. "

Nie "PODOBNO", ale napisałem o frameworkach, że "SĄ" (web2py), "PODOBNO" napisałem o API GAE. Framework i API GAE to dwie różne kawałki technologii.

@slawek22:"Poza tym myślisz, że jak zmienisz FW to kod będzie dalej działał? To niesłychane... tzn. zmienisz sobie np. Zenda na Cake albo MFC na WinForms i już :) "

Nie pisałem o zmianie FW. tylko, że ten sam framework działa w GAE jak na hoście. Np. jak piszę pod web2py to mogę aplikację uruchomić pod GAE jak na własnym hoście. Będzie działać tak samo. Po przenosinach zapewne będzie potrzebował puszczenia unit testów - tak na wszelki wypadek :)

@slawek22:"Jak już pisałem 45-55 USD/m masz 4-8GB RAM, 4 CORE, 2 TB dysku i 2-4TB transferu." i "możesz mieć 6 core i 100 GB ram za parę groszy."

Znowu "literówka"? - parę groszy :)

Jak znajdę chwilę czasu - i chęci :) - to postaram się dziś policzyć koszty GAE i hostnigu, który przesłałeś ( http://wwx.pl/VBr). I wrzucę w posta.

@slawek22:"Poza tym ty siejesz FUD."

FUD - oznacza sianie zamętu i strachu, pomijając fakty i dane. Oraz granie na emocjach i nieuzasadnionych lękach. Na jakich "lękach" ja gram? Co najwyżej mogę się mylić :) Próbuję jedynie sprowadzić dyskusję do poziomu konkretów.

@slawek22: "Myślisz, że chmura to coś co sprawi, że wystarczy włączyć instancje i się aplikacja "przeskaluje" w locie. "

Nie myślę. Sprawdzałem i wiem, tak działa GAE. Z tego co się orientuję np. chmury Amazona i Microsoftu tak nie działają i bez podprogramowania nie zapewniają "prawdziwej" HA.

@slawek22:"Jak ci padnie instancja bazodanowa to i tak będzie prawdopodobnie wymagana interwencja admina. Więc nie opowiadaj bajek. "

Mam wrażenie - wybacz może mylne - że niewiele wiesz na temat GAE. To nie jest zwykły hosting z mnóstwem serwerków. I jak dobrze pamiętam nie ma tam "fizycznej" instancji bazy :)

@slawek22"np. masz padnięty RAM i"

Mylisz chmurę z VPSem. Tak właśnie może być w klasycznym VPS i dlatego uważam chmurę za lepszą :)

@slawek22:"jakiś idiotyczny panel "

Jeszcze raz. Podchodzisz do tego bardzo emocjonalnie. Panel niezależnie jak źle zrobiony nie może być głupi :).Nie rozumiem co złego mogła Ci zrobić chmura.

@slawek22:" to pokaż mi taki który podniósł ceny 20 razy."

Nie wiem skąd taka informacja, że Gugiel podniósł ceny x20? Jak to wyliczyłeś, możesz wyjaśnić? Czy opierasz się tylko na mediach? Moim zdaniem - jak już pisałem nie jest to, aż taka podwyżka. Jeśli chcesz to postaram się na liczbach wyjaśnić ile to moim zdaniem jest więcej.
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#19 jacek2v^® 2011-09-04 17:50:28 0
@slawek22:

Przeliczyłem hosting, który przesłałeś vs GAE.

Przy założeniach, które opisałeś (tylko 6GB RAM) + procki chodzą na 100% i potrzebujemy HA (czyli dwa identyczne serweki) ten hosting to ~2024$ (jeden serwer bez load balancera 617$)!!! miesięcznie, a GAE ~581$!!! Sam jestem zaskoczony :)

Nie będę się rozpisywał jak to policzyłem - powiem tyle, że w przypadku GAE można jeszcze znacznie obniżyć koszty . Mogę wrzucić arkusik lub link.

PS:Drogi adminie i wszyscy czytający bardzo przepraszam, że zarzucam takie długie posty. Nie mogłem się opanować :). Obiecuję poprawę :)
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#20 dAREuS^® 2011-09-04 17:59:59 0
Ależ dajcie spokój. My się cieszymy z długich postów. Link były jak najbardziej na miejscu ;).
IP: 188.121.0.[...] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0
#21 slawek22 2011-09-04 18:55:22 0
Dobra, jak konkret to konkret. Weźmy najtańszy serwer z Hetznera i zobaczmy ile to samo kosztuje w google. Zarzuć ten arkusz bo coś mi się wydaje, że twój serwer składa się jedynie z ramu i procesora :)

http://code.google.com/intl/pl-PL/appengine/docs/python/backends/overview.html

1,5TB - 45c per GB czyli za sam storage wychodzi...675USD!

Backend B8 - 1GB ram 0.64c / h = 460USD miesięcznie (!). Potrzebujesz tego 8, żeby mieć 8GB RAM - jak masz duży serwis to potrzeba dużej bazy a duża baza wymaga tylko i wyłącznie dużej ilości RAM. Wychodzi 3680 USD / miesiąc (!)

Dolicz 1200USD za 10TB transferu...

Teraz podlicz całość, "klaud serwer" o takiej samej mocy obliczeniowej jak najgorsza maszyna w Hetzner za 60 USD w Google kosztuje okrągłe 5555 USD! Za tyle to ja sobie mogę wydzierżawić 50 takich maszyn opłacić admina.

Jak chcesz tani HA to bierzesz 3 maszyny w hetzner za 40 ojro, instalujesz heartbeat, koszt całkowity ok 160USD + admin.

Tak więc jeśli byś mógł to może porównaj ceny instancji. Potem można się zastanawiać, co trzeba, żeby z tego zrobić HA (które w większości wypadków nie jest potrzebne, wystarczy standardowe 99,95 a markowy sprzęt awaryjny też nie jest).

Z uwagą o RAM... to mnie zaciekawiłeś. Chmurą google'a fakt się nie interesuję, raczej OVH i amazon... nadaje się to do tego, żeby przetestować dystrybucje linuxa i postawić jakiś serwer do testów... do niczego więcej bo to zbyt wolne i za drogie.

Czyli jak to jest kiedy w fizycznej maszynie jest wadliwy komponent. Twierdzisz, że kod się uruchamia 2 razy. Prosty scenariusz, w RAM znajdują się wadliwe dane które mają zostać zapisane do pamięci stałej. Co wtedy się dzieje? (Bo w chmurach Amazona i OVH te dane po prostu zostają zapisane).

Twoje szacunki odnośnie tej serwerowni ( http://wwx.pl/VBr ) są zawyżone. Za sam fizyczny serwer zapłacisz 300$, HA możesz zrealizować programowo.

Zaraz pewnie napiszesz, że procki nie chodzą non-stop na 100%, transferu całego nie zużyję, etc. Tylko jak strona się rozrośnie to co? Ja będę płacił 5k USD miesięcznie w google a konkurencja kupi 3 serwery w OVH i Hetznerze i za o wiele lepszą platformę zapłaci równowartość 300USD. Jedyna różnica będzie taka, że witryna im będzie chodziła o wiele szybciej i będzie niedostępna może parę minut w miesiącu.
IP: 83.4.26.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#22 jacek2v^® 2011-09-04 21:09:29 0
@slawek22:

Ok. Przerzucamy się na Hetzner :) Podeślij linka do cennika Hetzner, z którego korzystałeś - aby nie bylo nieporozumień. Wrzucę do arkusza wyliczenie. Jam technik i prozy nie trawię :). Wolę napuścić czystą matematykę.

W wyliczeniu korzystałem z nowego cennika GAE - odnosząc się do narzekań, że GAE x20 droższy się zrobił :)

@dAREuS:Linka zamieszczę jak uzupełnię zestawienie i posprawdzam wg sugestii @slawek22. Nieomylny nie jestem :D

@slawek22: "Zaraz pewnie napiszesz, że procki nie chodzą non-stop na 100%, transferu całego nie zużyję, etc. "

Dziękuję za podpowiedź :P. Oczywiście, że procki nie chodzą na 100%. Każda aplikacja ma piki. Czym większy pik (różnica między najmniejszą utylizacją a największą) tym większa korzyść z GAE.

@slawek22:"Chmurą google'a fakt się nie interesuję, raczej OVH i amazon"

Jak dla mnie teraz wszystko jasne :) Jesteś usprawiedliwiony - bez ironii.

@slawek22:"Twierdzisz, że kod się uruchamia 2 razy. "

Tak. A nawet kod się uruchamia N razy:P. Zależnie od tego ile instancji potrzebujesz. I najfajniejsze, że to się dzieje automagicznie :)

@slawek22:"w RAM znajdują się wadliwe dane które mają zostać zapisane do pamięci stałej."

Co to "wadliwe dane"? Na poziomie sprzętu (aplikacji, czy bazy?), OS(aplikacji, czy bazy?), czy softu(aplikacji, czy bazy?)? Do bazy nie zapisuje się wadliwych danych - no przynajmniej ja nie zapisuję :) W GAE wszystko jest sterowane programowo. Zaproponuj test przeprowadzę.

@slawek22:"HA możesz zrealizować programowo."

Czyli opcja bez load balancera? Jeśli tak to odpada 395$ od każdego serwera. Ale nadal są dwa (i jest drożej od Gugla :)) i programista musi się napisać, a potem trzeba to utrzymywać :) HA programowe, które ma naprawdę zadziałać to nie prosty kawałek kodu, wierz mi - synchronizacja danych, wyczucie padu, przerzucenie ruchu itp.

@slawek22:"Ja będę płacił 5k USD miesięcznie"

Znowu liczby z chmur? :P

@slawek22:"Tylko jak strona się rozrośnie to co? "

No właśnie co? W GAE klikam jeden guzik (no może ciut więcej :P) i mogę na dowolny okres (bodajże minimum 24h) odpalić setki "serwerków" bez programowania :) Odpalić, ale nie zużywać, czyli przygotować się na zwiększoną utylizację, ale jeśli nie nastąpi zapłacić mniej. Elastyczność jakiej potrzebuje, bo potem zmniejszam :)

@slawek22:"będzie niedostępna może parę minut w miesiącu."

Ile wynosi dostępność w Hetzner?

PS: Cholera zaczynam pisać jak marketingowiec :P, zaraz ktoś pomyśli, że te GAE chcę komuś wcisnąć :D i nie daj Boże żem z gugla wyskoczył. Ja tak z dobroci serca. Po prostu GAE mi leży, a polityka i FUD nie :P
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#23 jacek2v^® 2011-09-04 21:24:52 0
@slawek22:"http://code.google.com/intl/pl-PL/appengine/docs/python/backends/overview.html

1,5TB - 45c per GB czyli za sam storage wychodzi"

Jeszcze na szybko nie wiem co miało być w tym linka, ale tam nie ma 45c/GB. Może chodziło o ten link: http://code.google.com/intl/pl/appengine/docs/billing.html

HRD rzeczywiście po 0,45$, ale zwykły Storage po 0,15$. A rożnica jeno taka, że zwykły ma dostępność ~99,95% a HRD 99,999999999999% :)

Patrzmy w przyszłość nowy cennik: http://www.google.com/enterprise/cloud/appengine/pricing.html

Storage HRD kosztuje: $0.24 / G / month, czyli 1,5TB kosztuje (=1024*1,5*0,24): ~369$. Wszystko na samą bazę i zreplikowane. Pamiętaj, że w VPS musisz pomnożyć x2 (RAID1), zarezerwować miejsce na OS, pliki aplikacji bazy itp.
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#24 jacek2v^® 2011-09-04 21:39:45 0
Przegapiłem:

@slawek22:"Backend B8 "

Backend nie po to by go w ciemno kupować :) Frontend po to jest.

Oczywiście jak potraktujesz GAE jak zwykły VPS to wychodzą róźne krzaki. Ale GAE "inaczej działa" i inaczej się tego używa.

Przykład: załóżmy, że potrzebuję 300 serwerów codziennie na 2h.

Ile to w VPS będzie kosztować? Na miesiąc trzeba by wziąć (chyba tak jest w Hetzner?). 300x60=18000$ (zdejmę połowę bo zakładając, że wydajniejsze od GAE ), 18000/2=9000$ o kurde, jakie drogie :) Zaraz a ile czasu zajmie odpalanie 150 OS :P i mamy WIELKIE WDROŻENIE!! :) A w GAE kilka kliknięć i koszty: 0,08$x2x30x300=1440$ LOL
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#25 jacek2v^® 2011-09-04 21:59:57 0
@slawek22:

Dla mnie Hetzner to jacyś naciągacze, nawet redundantnych zasilaczy nie ma w standardzie - trzeba kupić High Availability Option Pack:)

Ale - jeśli dobrze odczytałem cennik, bo mają nieźle zakręcony :) - to wygląda, że mają tani transfer 10TB w cenie serwera za 49E. Chyba, że to 6,90E za GB ?
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#26 jacek2v^® 2011-09-04 22:26:43 0
Nie wiem czy dam radę dziś długo siedzieć, a jutro robota :) Dlatego wrzucam obiecany link do zestawienia - zrobiony na szybko:

https://docs.google.com/spreadsheet/ccc?key=0AsyMLVCqrt92dDl0WHlSOXlWUXF1NHV2RmFxRFc4TVE&hl=pl

Kto chce niech zaciąga, za jakiś czas zapewne go wytnę z sieci :)

Hetzner zabija "darmowym" transferem :)
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#27 slawek22 2011-09-04 23:04:05 0
Nie lol bo dziennie po 2h to żadne założenie, tzn. nie będziesz miał ruchu który je spełnia. Poza tym po raz kolejny pominąłeś pozostałe koszta. Tzn. np. transfer. W ten sposób nie dojdziemy do niczego, bo po raz kolejny zaniżyłeś koszty usługi.

Poza tym co ty porównujesz? Instancje z GB RAM, marną mocą procesora i sieciowym dyskiem do dedyka quadcore? To ma się jak 1/2... nie bądź śmieszny. Moim zdaniem współczynnik ze względu na wirtualizację i to o czym wspomniałem będzie bliższy 1/10 jeśli nie 1/20.
IP: 83.4.26.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#28 jacek2v^® 2011-09-05 21:43:42 0
@slawek22:"Tzn. np. transfer."

Jak chcesz udostępnić coś a'la rapodshare to rzeczywiście potrzebuje dużo transferu, jak aplikację webową to znacznie mniej. Mnie interesuje to drugie - 2GB/dzień mi wystarczy.

@slawek22: "Moim zdaniem współczynnik ze względu na wirtualizację i to o czym wspomniałem będzie bliższy 1/10 jeśli nie 1/20."

Znowu liczby z chmur :)

@slawek22:

Podaj konkrety, inaczej nie ma sensu dyskutować. Poproszę o konkretną konfigurację - o którą już wcześniej prosiłem. Nie chce mi się już pingować na pseudo argumenty z Twojej strony :P
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#29 slawek22 2011-09-06 00:25:51 0
Sam wymyśliłeś sobie przelicznik 1/2. Dla "serwera" który ma jeden rdzeń, zewnętrzny storage, jedną ósmą RAMu a całość jest zwirtualizowana! Przecież laik spostrzeże, że sam siebie oszukujesz i aktualnie jesteś w fazie zachwytu nad chmurą :) Każdy wie, że środowiska wirtualne ustępują środowiskom natywnym jeśli chodzi o wydajność, już nawet pomijając aspekty sprzętowe a zewnętrzne przechowywanie danych to koszmar.

Ruch dwie godziny dziennie, 300 instancji, 2GB dziennego transferu? Co to jest za aplikacja? Tester nieskończonej pętli for który dostał wykop-efekt? :) Przecież to śmieszne. Jak już chcesz udowadniać, że coś co kosztuje, jak wynika z moich wyliczeń 92 RAZY drożej niż zwykły serwer - jest tanie - to podawaj konkretne dane.

Google liczy za instancje, storage, BW out... możesz olać BW in. Sam wyciągasz niepełne dane nie wiadomo skąd a mnie się czepiasz :P

Jeśli chodzi o konfigurację serwera to już wcześniej policzyłem ile w GAE kosztuje analogiczny storage, RAM, transfer i CPU. Wyszło 5555USD w GAE vs 49 euro w Hetzner.

Cennik google... jak nie umieją zrobić takiego cennika, żeby osoba z wyższym wykształceniem zrozumiała to problem leży po ich stronie, może jest aktualny, może nie. Mają to na witrynie, na podstawie tego określam, czy się opłaca migracja. Do firmy też nie jestem uprzedzony - bardzo ją lubię, no ale bez przesady. Nie tak bardzo, żeby płacić 5k USD za coś co jest warte 90 razy mniej. Albo jak kto woli, nie tak, żeby płacić 5500 USD za HA i panel pod małą aplikację.

Że nie zużyję transferu. No dobra, ale może być lepszy miesiąc albo potrzeba zahostowania jakiegoś pliku. I zamiast 120USD za 1TB zapłacę 0USD bo w umowie mam 10TB limitu.

Chyba ja jestem człowiekiem, który po prostu lubi jak wszystko działa oraz z góry wie ile za to zapłaci, ty lubisz włączać i wyłączać instancje czy jakieś inne dziwne kombinacje.

Ja wolę żyć w niepewności czy witryna będzie niedostępna w miesiącu minutę czy 10 minut, ale mieć pewność, że mi usługodawca nie wydrenuje portfela. Z resztą każdy kto mówi małej czy średniej firmie, że 99,95% to za mało i potrzebują HA próbuje ludziom robić wodę z mózgu i im sprzedaje jakieś marketingowe bzdety.

Wiadomo - HA kosztuje. Z tym się w 100% zgodzę i nawet jak zapłacisz 600 USD miesięcznie za platformę o marnych parametrach - to bardzo tanio. Tylko z tym jest jeden problem. Tak na prawdę to HA nikt za bardzo nie potrzebuje. No chyba, że jest głupi i cały biznes przeniósł z desktopów na chmurę i jak się "gubi" internet to cała firma mu siada. Często sklepy internetowe, które mogłyby być adresatem takich usług i mają miliony PLN obrotów rocznie chodzą na składakach z OVH albo Hetznera. Choć mogłyby dzierżawić markowe maszyny HP albo Della, ale mają to gdzieś, bo działa dobrze. My mamy w firmie witryny z milionami PV dziennie... każdy pojedynczy system się mieści na jednej, góra 2-ch wydajnych maszynach. Zamiast uruchamiać pierdylion instancji i płacić za każdą pierdylion zielonych my możemy robić co chcemy bo cały backend jest za darmo, sprzęt za pół darmo a kolokacja czy dzierżawa praktycznie nic nie kosztuje.

Konkret?

http://www.hetzner.de/hosting/produkte_rootserver/eq10

110 euro.

Ile zapłacę za to samo w "chmurze" (jakiejkolwiek)... albo GAE... z HA i panelem które moim zdaniem są zupełnie zbędne, godząc się na zamknięcie w klatce z napisem "Google"?

Bo mam wrażenie, że głównym argumentem jest to, że można sobie włączać i wyłączać te instancje a przez to ma być "taniej".
IP: 83.27.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#30 jacek2v^® 2011-09-06 17:54:07 0
@slawek22:

Sporo zarzutów do mnie: "Sam wymyśliłeś sobie przelicznik 1/2", "Google liczy za instancje, storage, BW out... możesz olać BW in. Sam wyciągasz niepełne dane nie wiadomo skąd a mnie się czepiasz :P"

Nic takiego nie wymyśliłem - możesz wskazać, gdzie to zauważyłeś?

@slawek22:"Chyba ja jestem człowiekiem, który po prostu lubi jak wszystko działa oraz z góry wie ile za to zapłaci, ty lubisz włączać i wyłączać instancje czy jakieś inne dziwne kombinacje."

Myślę, że GAE jest po prostu Tobie nie potrzebna - z jakieś powodu. Czy to SLA, czy też wolisz mieć własne pokrętełka, czy też potrzebujesz serwera do masywnego przetwarzania danych (liczenie Bitcoinów, łamanie haseł). GAE jest sprofilowane na ograniczenie zajmowania się właśnie "włączaniem i wyłączaniem instancji" i "jakieś dziwne kombinacje", które występują przy VPS. GAE nie jest VPS i mam nadzieję, że nigdy nie będzie. Backendy to nie VPS. GAE służy do odpalania aplikacji, a nie do zabawy w admina.

@slawek22:"że 99,95% to za mało" i ak na prawdę to HA nikt za bardzo nie potrzebuje.

99,95 to już ~20min/msc 99 to już ~7h/msc - a najfaniej jak trafi w koniec miesiąca lub gdy prezes klika :)

Jeśli nie potrzebujesz to szanuję to, ale zapewniam Cię, gdy padnie Twój provider dostarczający internet lub pocztę to przypomnisz sobie o HA.

@slawek22:

"Zamiast uruchamiać pierdylion instancji i płacić za każdą pierdylion zielonych my możemy robić co chcemy bo cały backend jest za darmo, sprzęt za pół darmo a kolokacja czy dzierżawa praktycznie nic nie kosztuje."

2000$ za miesiąc to nie za darmo !! :)

@slawek22:

"http://www.hetzner.de/hosting/produkte_rootserver/eq10"

Dodałem do mojego zestawienia. Rzeczywiście GAE wychodzi znacznie drożej, czyli jak potrzebujesz takiego potwora cały czas to zapomnij o GAE :) 430vs2300 (GAE) - główny koszt to transfer. Ja mimo to wybrałbym GAE :P
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#31 slawek22 2011-09-06 19:44:52 0
To nie zarzuty, nie bierz tego osobiście :)

Skąd ... no przecież napisałeś

"Na miesiąc trzeba by wziąć (chyba tak jest w Hetzner?). 300 ... (zdejmę połowę bo zakładając, że wydajniejsze od GAE )"... czyli sobie wymyśliłeś przelicznik 1/2. 1 dedyk = 2 instancje :P Co jest zupełnie kuriozalne.

Może by to było fajne, ale nie będę płacił 90 razy więcej za tę samą "moc"... poza tym vendor lock-in. To nie do przyjęcia.

Nie uważasz, że świadomość, że możesz w każdej chwili powiedzieć usługodawcy "idźcie się pier**ić", odpowiadasz jedynie przed powołanymi do tego organami państwowymi a dane są w 100% twoje i jak nie chcesz to możesz nawet nie wpuszczać techników do systemu jest po prostu... miła. Tak samo jak stałość rachunku. I sprawia, że firma będzie się starać, żebyś nie wybrał lepszej oferty. Tzn. 20 razy się zastanowi zanim podniesie ceny.

Jak sobie google ubzdura, że im się nie podobasz, to cię wywalą i tyle. Zostaniesz z kupą niedziałającego kodu. A jak będą chcieli podnieść ceny to to zrobią od tak... bo co im szkodzi :P

Gdyby normalny usługodawca podniósł ceny jedynie 2 razy to na trzeci dzień mnie tam nie ma... a tak to co możesz zrobić? Zacisnąć zęby i płacić ile ci każą :P Albo biadolić jak devsi z newsa... co oni w życiu z monopolem nie mieli do czynienia? :)

99,95 to jest 40 sekund dziennie. Wiem, że te pozostałe 0,05% kosztuje ogromne pieniądze, ale jeśli nie "jesteś" bankiem to nie jest tego warte.

Jakie $2000 za miesiąc, podałem linka do serwera który kosztuje 60 USD a ma takie możliwości jak byś nabrał tych instancji w GAE za 5555 USD. Jedyna różnica to brak HA i panelu. Za to możesz robić co chcesz. Wolność dla mnie jest warta więcej niż (hipotetyczne) 7 minut miesięcznie a takie "świetne" usługi jak GAE to zagrożenie dla otwartego internetu.

Każdy DEV który pracuje z otwartymi technologiami powinien to odradzać komu się da, no chyba, że jest wielkim fanem pańszczyzny, feudalizmu albo niewolnictwa... bo programista pisząc kod dla takich zamkniętych systemów ma takie same prawa jak średniowieczny chłop.
IP: 83.27.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#32 jacek2v^® 2011-09-07 13:32:28 0
@slawek22:

Odniosę się tylko do konkretów, polityka i gdybanie mnie nie interesuje. Resztę okryję zasłoną milczenia :P

@slawek22:""Na miesiąc trzeba by wziąć (chyba tak jest w Hetzner?). 300 ... (zdejmę połowę bo zakładając, że wydajniejsze od GAE )"... czyli sobie wymyśliłeś przelicznik 1/2. 1 dedyk = 2 instancje :P Co jest zupełnie kuriozalne."

Ok rozumiem. A jak przeliczyć 2GHz na 1,2GHz - taką wydajność ma instancja Google:)? Czy masz na myśli, że powinienem zamiast 1:2 wziąć 1,2:2? :)

@slawek22:"Jakie $2000 za miesiąc," Przeliczenie na podstawie Twojego pierwszego linka.
IP: 77.255.50.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#33 slawek22 2011-09-08 13:01:13 0
No to jeszcze raz. Zobacz sobie parametry obu "instancji" a później zaproponuj przelicznik :)

Już mówiłem, że mi nie zależy na HA... podobnie jak 99,9% klientów wystarczy mi 99,95. Więc twoje wyliczenia to niestety bujda bo liczysz koszty hardware'owego HA. Jak już chcesz tak liczyć - licz softwareowo. Równie dobrze możemy policzyć ile kosztuje przejście z takiej chmury do alternatywnego dostawcy (przepisanie i powtórne wdrożenie projektu).

Polityka... to nie jest polityka. To że zajmujesz się technologią a mylisz kwestie techniczne z polityką jest co najmniej dziwne. Vendor lock-in to nie polityka tylko kwestia ściśle techniczna.
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#34 slawek22 2011-09-08 13:29:11 0
Dodam jeszcze, że instancje zwirtualizowane, choć parametry wyglądają OK są po prostu SŁABE. Zarówno na OVH jak i na Amazon. System, pomimo np. 2GB RAM i procka (podobno) 8GHZ się potwornie ślimaczy.

Nawet z tanim kimsufi na słabym procku i nie najlepszych dyskach nie ma porównania.

Kiedyś w ramach testu przekierowałem na ten cloud w OVH 10-20% ruchu z serwera na starym C2D w tej samej serwerowni. Nie dość, że odpowiedzi apache były koszmarnie wolne (jakieś 2x-3x) to jeszcze zużycie procesora nie wyglądało za ciekawie (20-30%) podczas gdy na zwykłym serwerze 10-15% to "jadła" cała witryna (100% ruchu).

To są moje obserwacje (może ci co siedzą na chmurach się od razu przenieśli z VPS-ów, dlatego im się wydaje, że to dobre rozwiązanie?). Podsumowując, albo GAE to jakiś super wynalazek i miałem pecha testując inne chmury które moim zdaniem są całkowicie zjexxne jeśli chodzi o wydajność, albo nie miałem szczęścia i w tych super-HA środowiskach trafiłem na uszkodzone node-y, albo to co oferuje najpopularniejsza platforma cloud + jedna z największych serwerowni w dziedzinie cloud jest po prostu do dupy.

Tak czy inaczej, pewnie nie rozstrzygnie to sporu o sens wykorzystywania GAE ... platformy która wiąże użytkownika... w dodatku z Google, nie mam raczej zamiaru wykorzystywać :) Subset bibliotek starej wersji Pythona też nie bardzo mi odpowiada :)
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#35 slawek22 2011-09-08 14:30:59 0
Przyznam, że twoje posty i tak zacięta obrona platformy zaciekawiły mnie GAE... więc założyłem sobie konto... podczas szukania danych FTP / SFTP czy czegoś takiego trafiłem na zakładkę system.

http://code.google.com/status/appengine/detail/serving-java/2011/07/14#ae-trust-detail-helloworld-get-java-latency

Podsumowując, uptime na poziomie 98,5%, najpodlejszą serwerownię byłoby wstyd... ty twierdzisz, że to HA. Widać, że co nóż mają problemy z usługami. A to wysiada java, a to MC. Zamiast plików userzy otrzymują komunikaty błędów z serwera.

Latency jest kosmiczne po prostu... kosmicznie żałosne. 300ms na odpowiedź z skryptu pythona? U nas na normalnych serwerach staramy się nie wychodzić poza 200/250 dla requestu kompletnej witryny.

>Measures the latency, in milliseconds, of one call to datastore.get() on a 2kB entity

50-100ms. Dodaj to sobie do latency HTTP... Dla głupiego mySQL-a masz poniżej milisekundy przy tabelach z milionami wierszy. Dla put i delete to wygląda jeszcze gorzej. W postgre się robi connection pooling, bo połączenie do bazy zajmujące 10-20ms to zbyt dużo (pomimo, że każdy kolejny prosty request typu get/put to zwykle mniej niż milisekunda).

Patrzę w te logi uptime i widzę problem... requesty się wywalają, albo to co zajmowało 300ms zamuje teraz po 4 sekundy... Google prowadzi "App Engine scheduled maintenance"... na systemie HA... co prawda to tylko pół godziny, ale czy z tym HA to ty sobie kpisz? Dla mnie to się w tym momencie zrobiło już śmieszne :)

Super-cloud od gugli, najnowsza i najdroższa technologia... niezniszczalne i bezbłędne node'y... a głupi maintenance położył monstrum na pół godziny.

Później poczytałem trochę o eksplodujących indeksach (problemie nie do pomyślenia w jakiejkolwiek klasycznej bazie danych).

Do tego całość działa niestabilnie... ciągłe piki w czasach odpowiedzi.

Jak ty wpadłeś na to, że to jest równoważne z sprzętowym albo nawet programowym HA na którym bez problemu osiągniesz 99,99%?

Datastore... zamiast ACID jest eventually consistent więc wyśmiewany przez wszystkich myisam który każdy odradza wyprzedza to o dekady jeśli wziąć pod uwagę spójność danych... a indeksy nie "wybuchają". Nie mówiąc o "normalnej" bazie czy innoDB.

Muszę przyznać, że jako przeciwnik cloud, mainfamów i innych własnościowych technologii wymyślonych jedynie w celu dojenia kasy jestem zszokowany. Gdybym zobaczył uptime 99,8 to bym napisał... a nie mówiłem? HighAV? Bullshit! Ale 98%? Przecież to kpina, to wyższy uptime będziesz miał w serwerowni prowadzonej przez jakiegoś dzieciaka w szopie dziadka.

Czego tu nie rozumiem...? To może jakaś wersja beta albo preview i "już za X lat" ma działać porządnie?
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#36 Jan 2011-09-08 22:26:01 0
@slawek22: Przekonałeś mnie!
IP: 80.239.242.[...] Opera/9.80 (Windows NT 6.1; U; pl) Presto/2.9.168 Version/11.50
#37 jacek2v^® 2011-09-09 19:28:37 0
@slawek22: "300ms na odpowiedź z skryptu pythona", "Później poczytałem trochę o eksplodujących indeksach", "Do tego całość działa niestabilnie... ciągłe piki w czasach odpowiedzi. " "a głupi maintenance położył monstrum na pół godziny.", "Datastore... zamiast ACID jest eventually consistent więc wyśmiewany przez wszystkich myisam ","dzieciaka w szopie dziadka.",

Jestem pełen podziwu dla Twoich umiejętności, inteligencji, szybkości uczenia i wnioskowania z małej ilości faktów. W tak krótkim czasie (1h ?! co sugeruje wpis "albo GAE to jakiś super wynalazek ":)) przygotowana tak autorytatywna analiza działania GAE !!! :)

Oszczędzę Ci mojej analizy pracy, dostępności serwerów fizycznych - popartej ciut dłuższym okresem testów i pracy produkcyjnej bo ponad 20letnim:)

@slawek22:" Zarówno na OVH jak i na Amazon" "albo GAE to jakiś super wynalazek "

Może nie taki SUPER, ale wynalazek. Masz przeżycia z VPS, a ja cały czas piszę o GAE - po raz n-ty, to coś innego. Ciężko się rozmawia z kimś, kto nie słucha:) - a włożyłem trochę pracy w przygotowanie zestawienia (link, który zamieściłem).

Rozumiem, że nie chcesz zaakceptować opuścić fizycznego serwera i nie zamierzam Cię przekonywać byś to zrobił :)

Jeśli chcesz pogadać merytorycznie nad różnymi aspektami GAE vs serwer fizyczny to chętnie porozmawiam. Ale wycieczki emocjonalno-spekulacyjne mnie nie interesują.
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#38 slawek22 2011-09-09 19:54:52 0
No właśnie pytałem co z tego nie rozumiem. Dla mnie odpowiedź skryptu na poziomie 300ms czy bazy na poziomie 150ms, kiedy średnia witryna potrzebuje 5-10 kwerend na podstronę wygląda koszmarnie.

Zwłaszcza jeśli to taka prostacka kwerenda jak get czy put po kluczu.

To OK, dajmy na to masz średnich rozmiarów forum na jakimś prostym skrypcie. Średni czas odpowiedzi - dla PHP ... 20-40ms. jakieś 10-30ms dla bazy (10-20 kwerend) i 5-15ms dla PHP. Jak to wygląda w GAE i jak się mają do tego wykresy czasów odpowiedzi.

Co do wnioskowania... jedyne co z tego wywnioskowałem na 100%, to fakt, że ten system to żaden HA.

Czasy odpowiedzi serwera bazodanowego powyżej sekundy które nie są uważane za błąd to pomyłka... bo takie coś jest nie do przyjęcia. A przeglądałem te wykresy i zdarza się to dość często. Dodajmy błędy w działaniu usług, które już są ujęte na wykresach.

To co przytoczyłem na początku to czyste fakty. Eventually consistent się nie nadaje do zastosowań gdzie musisz mieć pewność, że dane są poprawne.

Przecież mogłeś od razu napisać merytoryczny post. Jak się mają te wykresy do rzeczywistości? Zarzuć w ogóle URL'em aplikacji która na tym chodzi... forum, sklep... cokolwiek...

>Oszczędzę Ci mojej analizy pracy, dostępności serwerów fizycznych

Dlaczego, to mogłoby być bardzo ciekawe.
IP: 83.4.27.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#39 jacek2v^® 2011-09-10 09:30:30 0
@slawek22:"To OK, dajmy na to masz średnich rozmiarów forum na jakimś prostym skrypcie. Średni czas odpowiedzi - dla PHP ... 20-40ms. jakieś 10-30ms dla bazy (10-20 kwerend) i 5-15ms dla PHP. Jak to wygląda w GAE i jak się mają do tego wykresy czasów odpowiedzi."

Zaczynasz pisać z sensem :)

Na początek trochę off topic: Mi nie chodzi o aplikacje typu forum - tu nie potrzebujesz wysokiego HA i możesz na maitenance parę nocnych godzin przeznaczyć bo najprawdopodobniej dla jednej strefy czasowej będzie. Mi chodzi o aplikacje biznesowe (np. wystawianie faktur, zarządzanie projektami, portale ), za które się płaci i wymaga. Od których oczekuje się wysokiej dostępności i często SLA.

1."300ms" - wczoraj zrobiłem test z helloworld.py uzyskałem czasy 8ms,6ms,4ms - nie wiem jak testowałeś i jak mierzyłeś czas, ja testowałem wg tego: http://code.google.com/intl/pl/appengine/docs/python/gettingstarted/helloworld.html i mierzyłem Dashboardem GAE :).

2."A przeglądałem te wykresy i zdarza się to dość często. " Czy masz na myśli linka, którego zamieściłeś? Zakładam, że jak wgrywasz nową wersję aplikacji (a ten problem właśnie wtedy się pojawił) to NIGDY Ci się nie zdarzyło i nie zdarzy, że coś poszło nie tak. W takim razie GAE rzeczywiście nie dla Ciebie, nad nim pracują ludzie, którzy są wstanie przyznać się do błędu :)

Przyznam, że nie wiem jak latency jest liczone. Latency na aplikacji helloworld.py to kilka ms, a wczorajsze latency dla GAE to średnio ~150ms. Dlatego podejrzewam, że to jest średnia do której zaliczane są też skomplikowane obliczeniowo skrypty, a nie proste strony zrzucające coś z bazy. Słyszałem o przypadkach wykorzystania GAE do łamania haseł :) - może to daje takie wyniki.

No i tak trochę offtopic: jedynie ten nie popełnia błędów co nic nie robi :P

3."Przecież mogłeś od razu napisać merytoryczny post." Cały czas staram się merytorycznie odnosić do Twoich wątpliwości. Przygotowałem zestawienie i źródła - olałeś, podajesz liczby - brak sposobu wyliczenia i źródeł.

@slawek22:"Zarzuć w ogóle URL'em aplikacji która na tym chodzi... forum, sklep... cokolwiek..."

Sorry, nie mam takiego URLa. Parę widziałem, ale nie zapisałem :P Przed chwilą pogooglowałem (leniwy jesteś, nie chciało Ci się :P), nie wiem ile to warte : http://blog.louisgray.com/2008/12/15-useful-google-app-engine.html

Jest jeden problem z GAE, który mi przeszkadza w odpaleniu swojej aplikacji. To brak możliwości postawienia certyfikatów https we własnej domenie. Ale gugiel pracuje nad tym :)

@slawek22:">Oszczędzę Ci mojej analizy pracy, dostępności serwerów fizycznych

Dlaczego, to mogłoby być bardzo ciekawe."

Nie chcę iść w stronę przepychanki. Powiem tylko tyle, że sprzęt bez dobrego admina gówno wart jest :) A jak chcesz robić webapp dla całego świata to musisz mieć co najmniej 2 adminów, aby zapewnić 24h obsługę.
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#40 slawek22 2011-09-11 00:17:22 0
1. Baza eventually consistent się nie nadaje do aplikacji finansowych. To zupełnie odmienny model od ACID, chyba nie muszę tłumaczyć dlaczego się nie nadaje. Może tylko taki mały hint: nie ma transakcji, commit ani rolback. Nie możesz zdefiniować jakiegokolwiek poziomu izolacji. Atomic i Isolation odpadło z pozostałymi literami też nie trudno :)

Pewnie zaraz będzie że nie ma konkretów... no to zrealizuj transfer pieniędzy z konta A na konto B przy użyciu bazy eventually consistent. Czekam na pseudo-kod.

Transakcje można co prawda emulować ale też do pewnego stopnia. No i brakuje nam literki D, więc dane nie koniecznie będą zapisane poprawnie. Dla jakiejś aplikacji społecznościowej to żaden problem ale aplikacje finansowe? Po paru godzinach będziesz miał masę niespójnych danych, ujemne stany kont i inne kwiatki. Dobre, jeśli ktoś chce mieć proces o oszustwa skarbowe.

2. 6-8ms dla hello world to raczej kiepsko, ale wynik da się zaakceptować. PHP / Apache => poniżej 1ms.

3. Jak to wypada z dostępem do danych? (put / get z datastore)... w milisekundach?

4. To bez znaczenia do czego są w stanie się przyznać ludzie z Google. Przez to niestabilna usługa stabilniejsza nie będzie. Od testowania kodu jest staging a nie serwery produkcyjne i nie rozumiem dlaczego dalej rozmawiamy o HA przy 98% dostępności (!!), którą Google samo podaje.

Na prawdę tutaj mnie zdziwiłeś bo gadasz jak dziecko... sorry. Jak płacę tysiące dolarów za usługę która ma być "HA" to gxxo mnie za przeproszeniem obchodzi kto i co przy tym grzebie, ma być minimum 99,9% (to w sumie nie jest dalej żadne HA... ale poniżej tego to już żenada).

Co powiesz klientowi, który ci płaci 2,3 albo 10k USD miesięcznie za "HA"... no sorry, panie ktoś w Google się bawi, ale uczciwie przyznają, że nie działa? To on pójdzie do Hetznera, da 80 ojro i będzie działało lepiej bo tam nikt się serwerami nie "bawi", nie "konserwuje", ani w nich nie grzebie co dwa tygodnie.

Przed chwilą pisałeś o poważnych aplikacjach finansowych, teraz twierdzisz, że usługa Google działa jak chce ale jest "OK" bo sami się przyznają, że jest kiepsko?

Nie no zdecyduj się na coś. Albo gadamy o poważnych projektach i przyznajemy, że HA google to żadne HA a uptime jest nie do przyjęcia albo gadamy o rzeczach niepoważnych, wtedy 98% wystarczy.

5. Czy ty w ogóle, kiedykolwiek wdrażałeś cokolwiek na fizycznym serwerze? Dzisiaj serwery chodzą 1-2 lata bez rebootu na linuksie a zdarza się, że 3-4 albo jeszcze dłużej na BSD. Nawet systemy desktopowe microsoftu mogą chodzić miesiąc bez przerwy (!).

Co ten admin ma tam robić? Gapić się w konsole? Jakieś przedziwne liczby podajesz. Technologia jest dzisiaj tak niezawodna, że instalujesz, stawiasz i działa przez najbliższy rok. Ewentualnie raz na pół roku jakieś patche albo optymalizacja wydajności.

Instaluje się monitor a jak coś nie działa to admin dostaje mail albo SMS. Co ci biedni ludzie mają robić przy jednym serwerze 24/h na dobę. HA polega na tym, że się wszystko dzieje automatycznie bo żaden człowiek nie jest w stanie odpowiednio szybko zareagować.

A nie, że budujesz miasto na 30000 mieszkańców koło serwerowni, stawiasz mieszkańców każdego dnia o 7 rano przed 30000 ekranów i każesz im patrzeć na ping.
IP: 83.27.69.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#41 jacek2v^® 2011-09-11 16:04:03 0
Ad.1.@slawek22:"Baza eventually consistent się nie nadaje do aplikacji finansowych"

Krótko: Błędne założenie, bo to nie jest baza "eventually consistent" :) Podpowiedź do guglowania : BigTable

@slawek22:"To zupełnie odmienny model od ACID"

Nie odmienny bo ACID to nie baza tylko zbiór zasad. Krótko: to nie baza relacyjna - ACID został stworzony w kontekście baz relacyjnych. Wydaje mi się, że mimo to ACID jest w dużej części spełniony, ale nie analizowałem tego. ACID i rzeczywistość baz relacyjnych to temat na całkiem inną opowieść :)

Zauważyłem, że przerzucasz się z krytyką z kosztów na features - taktyka partyzancka czy jak? :)

Ad.2.@slawek22:"PHP / Apache => poniżej 1ms."

Mhh, poprzednio pisałeś, że 5-15ms (albo nawet 20-40ms wybrałem na Twoją korzyść:)) - ok rozumiem zoptymalizowałeś :) Ale serio, liczby z chmur :)

Ad.3.@slawek22:"Jak to wypada z dostępem do danych? (put / get z datastore)... w milisekundach?".

Ad.4.@slawek22:"To bez znaczenia do czego są w stanie się przyznać ludzie z Google. "

O i tu się bardzi mylisz. To ma kolosalne znaczenie :)

@slawek22:"Przy 98% dostępności (!!), którą Google samo podaje."

98% gdzie to przeczytałeś? Poproszę linka.

@slawek22:"ale poniżej tego to już żenada"

Żyjesz w świecie ułudy. Stawiam złotówki przeciwko orzechom, że każdy serwer którego dotknąłeś nawet nie zbliża się do 98%. Kiedyś (przełom XXwieku) nowy szef IT w Microsoft zapytał swoich aminów jaki jest ich zdaniem poziom dostępności usług w firmie (MS). Stwierdzili 80-90%. A potem szef zarządził mierzenie wyszło 60-70% :) - też żyli w świecie fantazji :)

@slawek22:"2,3 albo 10k USD"

Skąd wyliczenie z chmur? - nieweryfikowalne.

@slawek22:" teraz twierdzisz, że usługa Google działa jak chce ale jest "OK"

Nigdzie nic takiego nie napisałem. Zaczynasz naginać rzeczywistość pod swoje potrzeby.

Stwierdziłem jedynie: rozumiem, że ktoś może popełnić błąd i szanuję szczegolnie tego co się potrafi do niego przyznać. W relacjach z klientami to bardzo ważna rzecz, daje mi możliwość reakcji i wytłumaczenia - jeśli takie będzie potrzebne. Np. nie widziałem lepszego panelu z dostępnością niż w GAE. Trudno mi by było wytłumaczyć klientowi, że przez kilka godzin aplikacja nie działała bo admin był u dentysty :)

Ad.5."Czy ty w ogóle, kiedykolwiek wdrażałeś cokolwiek na fizycznym serwerze? Dzisiaj serwery chodzą 1-2 lata bez rebootu na linuksie a zdarza się, że 3-4 albo jeszcze dłużej na BSD"

Wdrażałem - nie wypada się chwalić:P. Mylisz UPTIME (czas włączenia) z AVAILABILITY (dostępnością).Moje doświadczenia są inne (Linux i Windows, BSD nie znam): każdy OS trzeba paczować; aplikacje trzeba rozwijać, wgrywać nowsze wersje; sprzęt psuje się, prądu brakuje, kable rozwajają złe koparki itd. Jeśli uważasz inaczej to żyjesz w bajce :). Miałem dokładnie tak samo myślącego klienta, kilka dni (w tym weekend) trwało odtworzenie usługi.

@slawek22:"Co ten admin ma tam robić? Gapić się w konsole? Jakieś przedziwne liczby podajesz."

Te liczby wynikają z mojego doświadczenia. Jak chcesz mieć HA 24h tak musi być - tak naprawdę najlpiej, aby zawsze admin był dostępny (3adminów po 8h), ale dwóch w niektórych przypadkach wystarczy. Gorzej jak mamy 24/7d. Jak admin jest daleko od konsoli lub sprzętu (zależnie co padło) to zamin do niego dojedzie mogą minąć godziny. Co będzie robił admin poza byciem dostępnym :

a.okresowy monitoring OS i aplikacji pod kątem poprawnego działania i wydajności

b.testowanie i wgrywanie nowych poprawek OS oraz wsparcie testowania i wgrywania nowych wersji aplikacji.

c.monitoring + okresowe audyty - pod kątem bezpieczeństwa

d.konserwacja i utrzymanie procedur Disaster Recovery

e.okresowe przeglądy backup + dostosowanie procedur do zmian (w aplikacji i OS)

f.okresowe testy przełączania (symulacje padów sprzętu) i load balancing

g.wsparcie helpdesk w rozwiązywaniu problemów uzytkowników - czasami należy zweryfikować, czy rzeczywiście jest problem z usługą, czy też użytkownik nie umie klikać :)

itd. Ogólnie PREWENCJA - słowo mi to się źle kojarzy :)

Oczywiście wszystko może rozbić się o pieniądze. Możesz sobie powiedzieć: "e tam ryzyk-fizyk i strachy na lachy, nic się nie stanie, teraz robią niezawodny sprzęt" i też jechać, ale wtedy nie mów o HA, profesjonalnej i uczciwej usłudze.

@slawek22:"HA polega na tym, że się wszystko dzieje automatycznie bo żaden człowiek nie jest w stanie odpowiednio szybko zareagować."

Nie kolego, HA polega na tym, że przygotowujesz infrastrukturę i aplikację uwzględniając wszystkie możliwe (jakie przyjdą do głowy) scenariusze katastrof, padów, awarii, głupoty itd. Czym więcej możliwych scenariuszy przewidzisz i zabezpieczysz się przed nimi (na różne sposoby) tym wyższe HA uzyskasz. HA to nie tylko niskie czasy reakcji w sieci, to patrzenie realnie na świadczenie usługi w całości.

Przykład1: nie możesz mówić o HA 99.9% jeśli zakładasz, że dojazd admina + naprawa awarii to 8h. Bo to oznacza, że zakładasz jedno wyłączenie usługi na rok, a to jest realistyczne podejście.

Będziesz się podniecał milisenkundami, a olejesz duże prawdopodobieństwo sytuacji w której usługa wogóle nie będzie dostępna przez godziny :)
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#42 slawek22 2011-09-11 18:15:16 0
@Jacek: bez jaj poprzednio to był kompletny skrypt forum. Mam porównywać działające forum z wynikami twojego hello world? Moż od razu porównajmy prędkość oscommerce w PHP i hello world w GAE. Oczywiście ty byś pewnie wywnioskował że GAE działa szybciej :)

Chcesz porównać z poprzednimi założeniami - to daj wyniki dla forum.

2. In order to increase data availability, you can set the datastore read policy so that all reads and queries are eventually consistent. While the API also allows you to explicitly set a strong consistency policy, in the High Replication Datastore non-ancestor queries are always eventually consistent

Bez ACID baza danych nie nadaje się do aplikacji finansowych. Obojętnie czy jest EC czy nie i czy to BigTable czy nie. Nie da się realizować ACID bez transakcji, bo ci już na wstępie odpada atomowość i izolacja.

Ogólnie spoko - możesz się upierać. Jak ktoś ma jakiekolwiek pojęcie o tym co mówi to gdybyś mu zaproponował wdrożenie aplikacji biznesowej na bigtable to by cię wyśmiał. Gdybyś to przez przypadek jakimś cudem wdrożył i ta osoba dowiedziałaby się po fakcie to albo byś miał rozprawę albo by cię wezwała do siebie po kontroli skarbówki i wyrzuciła przez okno (obojętnie czy byś to wdrażał na GAE czy na dedykowanych serwerach).

3. Przecież koszty już chyba sobie wyjaśniliśmy dostatecznie dobrze. Mam po raz setny powtórzyć, ile kosztuje transfer i sprzęt w Hetzner czy OVH. Wiem, że ciebie nie przekonam - każdy kto umie liczyć sobie weźmie tabele opłat i pomnoży co trzeba.

4. Jak wdrażasz coś w budżetowej serwerowni co ma jedno źródło zasilania i jedno łącze to sorry... masz rację. Ale to twoja wina - po prostu nie potrafisz wybrać dostawcy. Sprzęt się psuje, to fakt, bardzo nieczęsto i głównie dyski które i tak są w RAID... ale łącza i zasilanie są zwykle zdublowane (2 źródła) to tego masz agregaty i UPSy.

Myślisz, że jak to jest? Przychodzi burza i wyłączają serwerownię? :) To już nie te czasy.

Pochwal się gdzieś to wdrożenie robił... chyba w serwerydedykowane.pl 5 lat temu. Dzisiaj standardem nawet w budżetówkach są redundantne łącza i zasilanie. Jak ci koparka "walnie" łącze to BGP wszystko załatwia.

Kod się testuje na serwerach developerskich. Po raz kolejny, to, że podejmujesz złe decyzje nie znaczy że się nie da.

5. Posłuchaj. Masz HA, zdublowane łącze, zasilanie i maszyny. Jak jedna maszyna pada druga przejmuje ruch automatycznie. Przełączenie przy rozwiązaniach softwareowych zajmuje 2-3 sekundy... długo mam jeszcze to tłumaczyć? Mylisz utrzymanie serwerów z utrzymaniem aplikacji. W każdej poważnej firmie jest profesjonalny admin od tego, żeby "hardware" i wszystkie apache, etc. działały a do tego zespół programistów który zajmuje się aplikacją.

Chyba, że gadamy o firmie, gdzie jest pan Miecio złota rączka, który się zna na linuksie, SQL-u, PHP i photoshopie. I on robi wszystko sam... w takim wypadku fakt strach pomyśleć jaka jest dostępność i jakość oferowanych usług.

Po cholerę ci w ogóle HA jak z góry zakładasz, że będziesz na serwery pakował niedziałający/nieprzetestowany kod a administrator serwera będzie zajmował się utrzymaniem kodu aplikacji?

Może prościej, jak ci wypadnie dysk z RAID1 to też admin musi dojeżdżać? Nie bo serwer działa bez przerwy? Magia :) Jak nie wierzysz to przyjmij po prostu, że tak właśnie jest.

6. Linka podałem parę postów temu

http://code.google.com/status/appengine/

7. Mylisz prędkość działania usługi z dostępnością, przecież do czegoś takiego nawet odnieść się nie można. Czas odpowiedzi i dostępność ma się do siebie dokładnie NIJAK.
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#43 slawek22 2011-09-11 18:24:53 0
Aha co do uptime, to chyba jest Daily... dzisiaj jak widać 100% ale zobacz sobie na przykład na 9 września. Zarówno backend Pythona jak i Javy tego dnia się im wywala, co pewnie jest ujęte w statystykach uptime'u jednak w podsumowaniu widać "no significant issues".

Widać, że błędy pokrywają się z peakami w odpowiedziach - prawdopodobnie system ulega przeciążeniom i dropuje requesty.
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#44 jacek2v^® 2011-09-11 19:53:39 0
@slawek22:"to był kompletny skrypt forum. "

Otóż to, "bez jaj" nie napisałeś jaki skrypt, dlatego się nie obruszaj.

@slawek22:"to daj wyniki dla forum."

Wydaje mi się, że wszystkie wyniki i założenia podałem. O jakie pytasz?

@slawek22:"In order to increase data availability..."

Niezależnie od tego skąd on jest, oznacza on tyle, że zapytania są "eventually consistent" a nie baza.

@slawek22: "Nie da się realizować ACID bez transakcji, bo ci już na wstępie odpada atomowość i izolacja."

Chyba nie rozmawiamy o tym samym ACID :) Są inne sposoby na osiągnięcie ACID bez transakcji (rozumianej tak jak w bazach relacyjnych) - jak już wspominałem dużo by pisać i nie ten wątek.

@slawek22:

"Jak ktoś ma jakiekolwiek pojęcie o tym co mówi to gdybyś mu zaproponował wdrożenie aplikacji biznesowej na bigtable to by cię wyśmiał."

Będę złośliwy: to rzeczywiście całkowicie obiektywny, techniczny i mierzalny argument :D

@slawe22:"każdy kto umie liczyć sobie weźmie tabele opłat i pomnoży co trzeba."

Po co się męczyć już to wyliczyłem i zamieściłem link :)

@slawek22"Jak jedna maszyna pada druga przejmuje ruch automatycznie. "

Aha czyli musisz mieć wykupione dwa serwery :)

@slawek22:"Mylisz utrzymanie serwerów z utrzymaniem aplikacji. "

Nie mylę, tylko biorę pod uwagę wszystkie elementy. Interesuje mnie TCO, a nie wybiórczo ekscytowanie się, tanim serwerkiem.

@slawek22:"W każdej poważnej firmie jest profesjonalny admin od tego, żeby "hardware" i wszystkie apache, etc. "

Czyli jednak miałem rację, admin będzie miał co robić :)

@slawek22:"Po cholerę ci w ogóle HA jak z góry zakładasz, że będziesz na serwery pakował niedziałający/nieprzetestowany kod a administrator serwera będzie zajmował się utrzymaniem kodu aplikacji?"

Nie zrozumiałeś. Nie zakładam, że wrzucam nieprzetestowany kod, znam życie i wiem, że mimo testów coś pójdzie "nie tak". Programiści są od aplikacji, admini najwyżej od wsparcia przy wdrożeniu - znowu naginasz rzeczywistość pod swoje potrzeby, nic takiego jak sugerujesz nie napisałem.

@slawek22:Może prościej, jak ci wypadnie dysk z RAID1 to też admin musi dojeżdżać?"

Oczywiście, że musi. Nie musi się spieszyć, ale dojechać i wymienić dysk powinien niezwłocznie. RADI1 może też mieć dysk spare, wtedy może się mniej spieszyć. Nie powinno się dopuszczać do sytuacji, gdy RAID1 działa z jednym dyskiem. Często dyski są z tej samej serii i lubią padać w tym po podobnym czasie :)

@slawek22:"Linka podałem parę postów temu http://code.google.com/status/appengine/"

I co Ci chodzi jest 100% 2011-09-11 godz.19:00 :)

@slawek22:"Mylisz prędkość działania usługi z dostępnością, przecież do czegoś takiego nawet odnieść się nie można. Czas odpowiedzi i dostępność ma się do siebie dokładnie NIJAK."

Nie rozumiem co chciałeś powiedzieć. Że UPTIME to prędkość działania?

@slawek22:"ale zobacz sobie na przykład na 9 września."

Nie podniecaj się :P w pythonie było 100%.
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#45 jacek2v^® 2011-09-11 20:03:35 0
@slawek22:"Przecież koszty już chyba sobie wyjaśniliśmy dostatecznie dobrze."

Ja starałem się wyjaśniać, Ty podawałeś nowe serwerownie i jakieś liczby bez wyliczeń.

PODSUMUJMY OSTATECZNIE i KONKRETNIE:

Na drugiej zakładce w tym dokumencie https://docs.google.com/spreadsheet/ccc?key=0AsyMLVCqrt92dDl0WHlSOXlWUXF1NHV2RmFxRFc4TVE&hl=pl zamieściłem czego potrzebuję i symulację kosztów dla Hetzner i dla GAE.

TOTAL Hetzner : 1148 USD/msc

TOTAL GAE : 81,36 USD/msc

Chcę odpalić - jak to się popularnie mówi - startup będący aplikacją biznesową do przetwarzania danych. Na początku nie przewiduję dużego obciążenia. Po okresie początkowym wzrośnie obciążenie serwerów (CPU), ale nie będę potrzebował dużych transferów i storage (100GB to z zapasem) - nie będzie przenoszenia filmów, muzyki i obrazków :)

W tym kontekście powiedz co Twoim zdaniem byś zmienił w tym wyliczeniu. Jeśli mógłbyś mnie przekonać, dlaczego Twoim zdaniem mam wydać miesięcznie ponad 10x więcej? :)
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#46 slawek22 2011-09-11 21:07:33 0
1. Przecież pisałem o skrypcie forum. Masz założenia, ile czasu na SS, ile na bazę i ile kwerend. Taka rozmowa jest po prostu irytująca. Ja ci piszę, 10-20 kwerend, średnie forum... ty mi dajesz benchmark helloworld.py i twierdzisz, że szybsze bo zajmuje 8 ms zamiast 30 :/

2. Jakim cudem zapytania są eventually consistent przy bazie która nie jest eventually consistent? Albo baza i zapytania są spójne (ACID) - (C)onsistency, albo nie.

Podaj sposób na osiągnięcie ACID w bazach rozproszonych, skoro twierdzisz, że taki jest to chyba ma to jakąś nazwę?

3. Co ma TCO do modelu dzierżawy serwera? Jeśli wykupujesz usługi managed to aplikację i tak ktoś musi utrzymywać.

4. No będzie miał co robić, tylko że jeden admin ma pod sobą 20-50 serwerów a nie siedzą w trójkę ludzi na 3 zmiany przy jednej konsoli. Jak u ciebie w firmie się tak pracuje, dodatkowo w serwerowni macie jedno łącze i jedno źródło prądu (to "serwerownia" u kumpla w domu na neostradzie?)... to serio bierz darmowe konto GAE... na pewno od czegoś takiego będzie działać lepiej.

5. W RAID1 nie ma najmniejszego sensu stosowanie dysków hot spare. Możesz dane replikować od razu i macierz wytrzyma awarię N-1 dysków. Czyli na przykład dwóch albo trzech... mam nadzieję, że chociaż powyższe zdanie ma dla ciebie sens.

6. Pisałem że dostępność jest prawdopodobnie daily. Nawet ci podałem konkretną datę kiedy backend Javy się wywalił, 3 dni temu a ty dalej udajesz, że nie umiesz czytać a wykresów nie ma:) Z resztą 2 dni temu też się wywalał, podobnie jak cały poprzedni tydzień.

7. To sobie zobacz na 8 września, masz spadek wydajności obsługi + błędy i Javy i Pythona. Jak ty możesz robić wdrożenia czegokolwiek, skoro kliknięcie wstecz i analiza prostego wykresu to dla ciebie taki problem?

Słuchaj, chcesz wdrażać poważną biznesową usługę, a próbujesz udawać, że backend który co nóż się wykrzacza działa stabilnie. Przecież to nie jest nawet dziecinne tylko po prostu śmieszne. Nawet Google daje wykresy backendu, żeby jelenie które nie mogą inaczej ocenić stabilności nie zrobiły sobie krzywdy... przecież prościej już się nie da. Ty dalej twierdzisz, że chcesz Google dla HA chociaż peaki w czasach odpowiedzi i błędy masz na wykresach dla krytycznych usług niemal codziennie.

8-ego masz kilkukrotnie dla pojedynczej usługi 4 krotny wzrost latency i 20% błędów HTTP. Uważasz, że to jest OK?

8. Przecież w tych twoich wyliczeniach masz

Hetzner: 80

GAE: 728 / 2323

Co do wyliczenia to i tak jest bez sensu i zawyżone dla dedykowanych serwerów. Bo Google żadnego HA nie daje. To jest główny problem, jak przy liczeniu czegoś masz błędne założenie, to całe wyliczenie jest błędne.

Co bym zmienił? Jak już tak się uparłeś żeby przepłacać za cloud to bym to wdrożył ma serwerach Amazonu a nie na nieskończonym i niestabilnym backendzie google'a. Jak z klientami będziesz gadał tak jak ze mną a błędy w systemie HA będziesz traktował w kategoriach "podniecania się" to po 5 minutach pomyślą, że jesteś niepoważny.
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#47 jacek2v^® 2011-09-11 23:44:54 0
@slawek22:

Postaram się odnieść tylko do konkretów i na temat. Pominę milczeniem prozę i wycieczki osobiste.

@slawek22:"No będzie miał co robić, tylko że jeden admin ma pod sobą 20-50 serwerów"

Ale ja nie zamierzam kupować 20-50 serwerów dla mojego startupu.

@slawek22:"Jak u ciebie w firmie się tak pracuje, dodatkowo w serwerowni macie jedno łącze i jedno źródło prądu (to "serwerownia" u kumpla w domu na neostradzie?)."

A co ma prąd i łącze do ilości adminów? :)

@slawek22:"W RAID1 nie ma najmniejszego sensu stosowanie dysków hot spare. Możesz dane replikować od razu i macierz wytrzyma awarię N-1 dysków. "

To zależnie od szkoły. Minus jest taki, że masz N-1 więcej kosztów za dysk. Dla mnie takie podejście jest bez sensu - no cóż, ale można :)

@slawek22:"Pisałem że dostępność jest prawdopodobnie daily."

Tak to prawda napisałeś to, ale później. Wcześniej bardzo autorytatywnie twierdziłeś, że dostępność jest 98% nie wspominając, że to daily - klasyczny FUD albo pomyłka. Jak pomyłka to "przepraszam" z Twojej strony nie padło.

@slawek22:"Jak ty możesz robić wdrożenia czegokolwiek, skoro kliknięcie wstecz i analiza prostego wykresu to dla ciebie taki problem" i "Ty dalej twierdzisz, że chcesz Google dla HA chociaż peaki w czasach odpowiedzi i błędy masz na wykresach dla krytycznych usług niemal codziennie."

Dałeś już przykłady, że nie potrafisz czytać tych wykresów. Zatem przestań się pogrążać. Nie jest moim celem pogrążenie Cię :P, chociaż wydaje mi się, że Ty celujesz Ciągle we mnie, zamiast rozmawiać merytorycznie.

@slawek22:"Przecież w tych twoich wyliczeniach masz ..."

Wydawało mi się, że wyraźnie napisałem: patrz na zakładkę drugą, mhh? :) Cały czas zakładałem Twoją dobrą wolę, ale chyba się myliłem - manipulujesz liczbami.

@slawek22:"Bo Google żadnego HA nie daje."

Moim zdaniem daje bo:

a.automatyczny load balancing i skalowalność - zarządzalne, z możliwością sterowania poprzez koszty

b.automatyczne przenoszenie obciążenia z "niedziałającej poprawnie" instancji

c.rozproszona baza danych

d.SLA

@slawek22:"Amazonu" tego co niedawno przez parę godzin wogóle nie działał :) - to było złośliwe :P

@slawek22:

No to jak zerkniesz na tę drugą zakładkę arkusza, czy też dalej będziesz się pienił jaki to GAE drogi, niestabilny, niekonsystentny i taki w ogóle beee? :)
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#48 slawek22 2011-09-12 02:29:02 0
Tak czy inaczej Amazon to stabilna usługa, która ma określone SLA. Czytałeś SLA Google? Każdemu się może fuckup zdarzyć, ale ciągłe maintenance, peaki i nie działające usługi to co innego.

Tak na prawdę to żadne SLA. Bo według warunków wolne działanie usługi i maintenance pod SLA nie podchodzi (stąd chyba nie branie pod uwagę wolnego działania usług w wykresach dostępności).

Masz "obiecane" 99,95% - maintenance (max 1h miesięcznie - 0,14%)...

Wychodzi 99,95-99,81.

GAE SLA tak na prawdę to na chwilę obecną nie ma:

Please note that this is a draft of proposed SLA terms only. These proposed terms are not applicable to existing Google products and services in any way. Google reserves the right to modify these SLA terms at any time at its discretion.

App Engine for Business is no more, but don't worry. Almost all the features you wanted in App Engine for Business will now be available to all App Engine developers in an upcoming release, including an SLA. App Engine's draft SLA model is available
http://code.google.com/intl/pl-PL/appengine/sla.html

http://code.google.com/intl/pl-PL/appengine/business/sla.html

Ja muszę zobaczyć, żeby uwierzyć. Jak zobaczę wiążącą umowę z określonymi czasami odpowiedzi skryptów testowych - to się zgodzę, że SLA jest :) Jak będę musiał przesiedzieć pół godziny, żeby znaleźć okres w którym usługa sypie błędami HTTP to się zgodzę, że jest HA (na razie to zajmuje 30 sekund).

Amazon ma SLA które obowiązuje od 2008 więc to "stabilna" umowa a nie draft, którym można się za przeproszeniem podetrzeć. No i pełne 99,95% więc, sorry moim zdaniem lepsza jest usługa, która będzie niedostępna parę godzin rocznie niż taka, która sprawia problemy przez kilkadziesiąt minut co drugi dzień albo codziennie a dostawca nie bierze za te problemy odpowiedzialności i otwarcie to przyznaje.

Chyba ci się hotspare pomylił z hotswap. Jak masz hot spare to cała koncepcja polega na tym, że dysk jest cały czas podłączony a kiedy któryś z dysków nawala zostaje włączony do macierzy za ten konkretny dysk. W R0 się po prostu nie da a w R1 nie ma sensu, lepiej żeby dysk był w macierzy skoro i tak jest w systemie.

Co do dostępności to już nie wiem co oni tam pokazują. Raz jest 100% raz 94... słowo "current" nic mi nie mówi. Może to dzienne, może godzinne... Nie zmienia to faktu, że czas odpowiedzi testów powinien być wpisany w wiążące SLA. Jeśli to ma być poważne HA dla poważnego biznesu, na razie poważna to jest cena usługi.

Co do drugiej zakładki to polecam serwery Managed, albo jak szybko łapiesz - z preinstalowanym panelem. Do jednego serwera się nie bierze administratora fulltime (ani tym bardziej trzech) tylko albo to zleca firmie która się zajmuje obsługą serwerów albo wykupuje usługę u dostawcy (wychodzi 200-400PLN miesięcznie). Jak nie potrzebujesz całego serwera to możesz wziąć managed VPS, ale widzę, że jesteś totalnym fanem chmury i to tej konkretnej więc i tak póki się nie sparzysz albo nie przekonasz, że bazy rozproszone (czy "HA na gębę") się średnio nadają pod biznes to będziesz robił po swojemu :)
IP: 83.10.79.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#49 ale 2011-09-12 09:44:32 0
tak sie zaczytalem w tych postach,depilacja opoleze nie zdazylem sie ogolic do pracy
IP: 213.238.123.[...] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
#50 slawek22 2011-09-12 13:48:48 0
Poczytaj sobie:

http://www.carlosble.com/2010/11/goodbye-google-app-engine-gae/

The reason why we left the GAE platform is solely because of its unreliability as of september-octuber-november 2010. The last 3 months we saw the site down more times that we considered reasonable and we couldn't find a way to avoid it so eventually we decided to abandon the platform.

You might agree or not with me on this post but there is one certain reality: developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule.

Since the last update they did in september 2010, we starting facing random 500 error codes that some days got the site down 60% of the time. 6 times out of 10, users visiting the site couln't register or use the site.

http://3.14.by/en/read/why-google-appengine-sucks

Więc to nie jest tak, że mi się coś "wydaje".

http://www.zdnet.co.uk/news/cloud/2011/01/07/google-updates-app-engine-datastore-after-outages-40091338/

Cloud architect JP Morgenthal told ZDNet UK he had experienced problems with applications he wrote for Google App Engine. "When I first deployed I saw strange messages coming to me about timeouts and performance implications, and I had to go back and modify my code to specifically handle the case where I was getting timeouts," he said.

Google's datastore "is nothing more than a basic MapReduce algorithm", Morgenthal said. "A Hadoop cluster on Rackspace is a better value proposition than on Google datastore.

"I don't particularly see where Google is really offering a tremendous service to attract customers when competing against the scalable cloud environments like Azure, Rackspace and AWS, where I can buy redundant storage and manage my cluster with guaranteed rights of redundancy," he said.

http://news.cnet.com/8301-30685_3-20079701-264/google-app-engine-suffers-availability-problems/

No faktycznie, cholernie stabilna platforma HA.
IP: 83.10.79.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#51 jacek2v^® 2011-09-13 18:05:08 0
@ale: hehehe
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#52 jacek2v^® 2011-09-13 18:35:14 0
@slawek22:

Tradycyjnie postaram się skupić Twoją rozproszoną uwagę i tendencję do skakanie z wątku na wątek :)

@slawek22:"Do jednego serwera się nie bierze administratora fulltime (ani tym bardziej trzech)"

Bierze się, jeśli potrzeba.

@slawek22:"Jak nie potrzebujesz całego serwera to możesz wziąć managed VPS"

To nie zmienia zbytnio kosztów, nadal potrzeba admina.

Podsumowując analizę kosztów: Czy mogę rozumieć, iż przyznajesz mi rację i zgadzasz się, że koszty utrzymania wynajętego serwera są wyższe niż GAE?

@slawek22:"Chyba ci się hotspare pomylił z hotswap. Jak masz hot spare to cała koncepcja polega na tym, że dysk jest cały czas podłączony a kiedy któryś z dysków nawala zostaje włączony do macierzy za ten konkretny dysk. W R0 się po prostu nie da a w R1 nie ma sensu, lepiej żeby dysk był w macierzy skoro i tak jest w systemie"

Nie pomylił się. Spare dyski można włączyć w dowolnej konfiguracji, jest to niezależne od typu RAID. Sens przy R1 jak najbardziej jest - po padzie dysku automatycznie kontroler podłącza spare dysk odbudowuje macierz i po jakimś czasie, bez ingerencji admina mamy w pełni sprawną macierz. Zaleta taka, że admin może się zbytnio nie śpieszyć :). Przy R0 też się da podłączyć spare, jeno czasami nie ma po co, bo i tak już po danych :).

@slawek22:"ale widzę, że jesteś totalnym fanem chmury i to tej konkretnej więc i tak póki się nie sparzysz albo nie przekonasz, że bazy rozproszone (czy "HA na gębę") się średnio nadają pod biznes to będziesz robił po swojemu :)"

Fanem to może nie, ale sporo lat mam do czynienia z serwerami. Znam wysiłek i koszt jaki trzeba włożyć w ich utrzymanie. Dlaczego GAE? Reszta chmur to zwykłe VPS, czasami z dodatkowymi opcjami :) W GAE widzę duże możliwość ograniczenia kosztów i efektywności działania i tyle.

@slawek22:

Myślę, że odniosłeś błędne mniemanie, iż zamierzam używać produkcyjnie wersję PREVIEW GAE. Otóż chciałbym wyprowadzić Cię z błędu, czekam na wersję PRODUKCYJNĄ GAE. I liczę, że pojawi się SLA, nowy cennik itd. Zresztą w kontekście nowego cennika jest cała ta dyskusja. Dlatego też nie ma co dyskutować o SLA do wersji PREVIEW.

@slawek22:

Dzięki za linki. Poczytam dokładnie, na razie przejrzałem je pobieżnie. Wyłapałem parę dziwnych stwierdzeń np. tu http://3.14.by/en/read/why-google-appengine-sucks "I haven't noticed any DDOS protection, " z tego co mi wiadome jest w GAE zabezpieczenie DDOS oraz autor chyba niezbyt dobrze zrozumiał zasadę działania GAE w kontekście uzyskania większej szybkości dla jednego zapytania. Na szczęście są źródła do testów :)
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#53 jacek2v^® 2011-09-13 18:57:44 0
@slawek22:Przeczytałem to:

http://www.carlosble.com/2010/11/goodbye-google-app-engine-gae/

No cóż, gość cierpi na "chorobę" informatyków, na którą ja też czasami choruję :). A zwie się ona: NieCzytamDokumentacji :) Wszystkie minusy są w dokumentacji. Nie leżało mu NoSQL - to też rozumiem, mi leży i uważam SQLe za ... "niepasujące" do realiów. I to nie tylko w chmurze.

Co do tego stwierdzenia :"if the application can't load into memory within 1 second, it might not load and return 500 error codes" to nie rozumiem i postaram się sprawdzić o co chodzi.
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#54 jacek2v^® 2011-09-13 19:12:39 0
@slawek22:@ http://www.zdnet.co.uk/news/cloud/2011/01/07/google-updates-app-engine-datastore-after-outages-40091338/

eśli dobrze zrozumiałem, pan Cloud Evangelist JP Morgenthal jest zdziwiony, że chwilę po deployu aplikacja wolno działała i że musi system najpierw ja skonsumować :)? A może chodziło mu o coś innego?

Zresztą ja jakoś nie lubię Evangelist-ów :). Ewangelist to taki "byt" nastawiony na krytykę konkurencji i bezkrytycznie wychwalanie swego :). Chociaż gość ma doświadczenie: http://www.cloudbook.net/community/contributors/jp-morgenthal. Poza tym podał ogólniki.
IP: 77.254.47.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#55 slawek22 2011-09-13 19:40:21 0
Nie, nie przyznam ci racji bo jak wynika z mojego wyliczenia koszty są o 90razy niższe niż GAE. Doliczasz do serwerów koszty hardawreowego load-balancera i bierzesz 3 maszyny a to według ciebie jest to samo co niestabilna usługa Google z nieistniejącym SLA (chociaż i tak dalej jest taniej :)

Mogę się zgodzić z tym: GAE jest tańsze od dedyka jeśli do każdego dedykowanego serwera zatrudniasz administratora na pełny etat i umowę o pracę.

Po co ci admin do serwera czy VPS-a managed, gdzie zwykle nie masz nawet dostępu root? To jest usługa stworzona po to, żebyś nie płacił za admina i w wielu przypadkach roota to nawet nie masz, żebyś adminom w pracy nie przeszkadzał.

Dobrze, że dopisałeś przedostatni akapit bo miałem wrażenie że na tym co jest teraz chcesz wdrażać biznesową usługę co sugerowałoby, że jesteś szalony. Różnice w poglądach wzg. GAE wynikają chyba jedynie z tego, że ja odnoszę się do tego co "jest teraz" a ty swoje poglądy opierasz na wyobrażeniach tego, co "ma być".

Ja potrzebuję stabilnych rozwiązań teraz, a nie za 3 lata.

Więc przyznam, że może być SLA 99,99%, może to zacząć działać stabilnie i w przyszłości może być taniej niż klasyczny "dedyk". Obecnie wszystkie te 3 założenia są nie spełnione. A usługę (słusznie) do poważnych zastosowań się ogólnie odradza (z resztą sam stwierdziłeś, że preview, nikogo nie powinno to dziwić).

SQL nie pasuje do chmury bo się nie da automatycznie skalować. noSQL nie pasuje do biznesu bo gubi dane i nie ma ACID (jeśli jest namiastka ACID to kosztuje dużo więcej jeśli chodzi o zasoby w porównaniu z klasycznymi bazami). Do zwykłych serwerów też nie bardzo pasuje, bo na 1 node to szybciej chodzi "klasyczna" baza. Proste.

Podsumowując. Kiedy google upora się z ciągłymi problemami dostępności, peakami w dostępie do usług, wprowadzi ostateczny cennik i wiążące SLA - będziemy sobie mogli pogadać co jest "taniej" (może będzie SLA 99,99%?). Na razie jak na ciągle sypiącą się betę jest cholernie drogo i jak już wspomniałem serwer z gwarantowanym, o wiele lepszym uptime możesz mieć 90x taniej.

Moim zdaniem... albo całkowicie zmienią model działania tej usługi albo to nigdy dobrze działać nie będzie. Nie da się zapanować nad takim ogromnym homogenicznym systemem, gdzie każda aplikacja ma do dyspozycji całą platformę. To po prostu taki duży, wirtualny shared-hosting.

Chciałem jeszcze napisać, żebyś mi podał numer kontaktowy do profesjonalnego zespołu techników kiedy coś tam się wysypie (bo sypie się często), ale skoro już zauważyłeś, że to preview to sobie daruję :) I lepiej zwróć na to uwagę bo w przeciwnym razie (jak już to wejdzie w taką fazę, że się nada na produkcję)... to i tak może tobie coś się wysypać a ty będziesz słał maile do Google i 2 miesiące czekał na odpowiedź (obecna usługa nie ma żadnego modelu supportu, jak coś się spieprzy to można "napisać na forum")
IP: 83.27.74.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#56 slawek22 2011-09-13 19:47:49 0
Panu JP chodziło o to, że część żądań np. do engine BD może skończyć się błędem albo timeoutem, dlatego trzeba dodawać obsługę błędów do kodu przy komunikacji z bazą (te błędy które wyskakują na ich wykresach dostępności co 2 dzień).

Po prostu przyzwyczaił się facet do tego, że bazy SQL są w tym względzie niezawodne. Jeśli już uzyskasz połączenie do bazy to nie ma mowy o tym, żeby kwerendy losowo się wywalały (mam na myśli błędy komunikacji z bazą)
IP: 83.27.74.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
#57 jacek2v^® 2011-09-14 22:07:03 0
@slawek22:"Nie, nie przyznam ci racji bo jak wynika z mojego wyliczenia koszty są o 90razy niższe niż GAE. Doliczasz do serwerów koszty hardawreowego load-balancera i bierzesz 3 maszyny a to według ciebie jest to samo co niestabilna usługa Google z nieistniejącym SLA (chociaż i tak dalej jest taniej :)"

Widzę, że racjonalnym podejściem Cię nie przekonam :), a pyskować nie mam zamiaru :P

@slawek22: Piszesz po prostu demagogicznie (oraz FUDycznie):

"A usługę (słusznie) do poważnych zastosowań się ogólnie odradza" - kto?, co?, gdzie?

"Po co ci admin do serwera czy VPS-a managed, gdzie zwykle nie masz nawet dostępu root?" - wyjaśniłem, olałeś moje wyjaśnienie, ale nie zaprzeczyłeś :)

"albo całkowicie zmienią model działania tej usługi albo to nigdy dobrze działać nie będzie." - bardzo autorytatywnie, ale takie sobie gadanie :P

"Ja potrzebuję stabilnych rozwiązań teraz, a nie za 3 lata." - pisałem cały czas w kontekście moich potrzeb, teraz wyjeżdżasz ze swoimi potrzebami, na zasadzie odwrócenia uwagi.

"Kiedy google upora się z ciągłymi problemami dostępności, peakami w dostępie do usług,"

i głupoty:

"noSQL nie pasuje do biznesu bo gubi dane"

"dlatego trzeba dodawać obsługę błędów do kodu przy komunikacji z bazą" - sugerujesz, że obsługi błędów nie trzeba pisać.

" bazy SQL są w tym względzie niezawodne." - :)

Informatyka dla mnie to nie pisanie prozy, dlatego chciałbym skończyć tę długą dyskusję. Nie udało mi się skłonić Cię do bardziej inżynierskiego podejścia do tematu, a szkoda. Dziękuję i dobranoc.
IP: 77.255.60.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.