Z punktu widzenia programisty, którą platformę rozważasz w przypadku dużej aplikacji społecznościowej? Gdybyś mógł podać kilka szczegółów na temat tego, co uważasz za mocne strony tej alternatywy, byłoby świetnie.
159
Z punktu widzenia programisty, którą platformę rozważasz w przypadku dużej aplikacji społecznościowej? Gdybyś mógł podać kilka szczegółów na temat tego, co uważasz za mocne strony tej alternatywy, byłoby świetnie.
Odpowiedzi:
Napisałem tę samą aplikację na GAE (Python i teraz Java) i Azure. Prawdopodobnie będę nadal używać obu, do różnych rzeczy. Oto kilka myśli, które będę aktualizować:
Powody korzystania z GAE:
Powody korzystania z platformy Azure:
Więc nie ma oczywistych odpowiedzi. Obecnie używam App Engine ze względu na koszty i łatwość użytkowania. Mogę używać platformy Azure do aplikacji bardzo zorientowanych na MS. Używam Amazon S3 do pobierania, ale prawdopodobnie nie będę używać EC2, ponieważ wolę pozostawić wszystko poniżej poziomu aplikacji ekspertom.
źródło
Jestem wyraźnie stronniczy - pracuję w zespole App Engine zajmującym się relacjami z programistami - ale oto moje zdanie:
Nie są bezpośrednio porównywalne. Istnieje zestaw aplikacji, które możesz napisać dla dowolnej z nich, ale w każdym przypadku będziesz pisać inną rzecz. App Engine zapewnia ograniczone środowisko wykonawcze - bez zapisywania do plików, bez gniazd itp. - oraz nierelacyjny DBMS. Ale w zamian otrzymujesz środowisko wykonawcze, które skaluje się w nieskończoność, i masz wystarczającą pewność, że Twoja aplikacja będzie skalować się na tyle, na ile chcesz.
Z drugiej strony platforma Azure zapewnia nieco mniej ograniczone środowisko, które pozwala pisać szerszą gamę aplikacji, ale wymaga pisania więcej - ponieważ sam wdrażasz więcej stosów - i zapewnia znacznie mniejszą pewność skalowalności .
Wreszcie, AWS zapewnia najlepsze rozwiązanie dla majsterkowiczów. Zapewniają sprzęt, pamięć masową i niewiele więcej. Budujesz swój stos od podstaw, utrzymujesz go, ulepszasz i tak dalej. Twoja aplikacja skaluje się tylko wtedy, gdy piszesz ją w skali, co nie jest małym wyzwaniem. Ale masz pełną kontrolę nad swoim sprzętem.
Moja rada byłaby następująca: jeśli twoja aplikacja pasuje do modelu App Engine - a aplikacja sieci społecznościowej może być całkiem dobrym przykładem takich aplikacji - napisz ją na App Engine (Java lub Python, twój wybór). Jest tańszy i znacznie łatwiej jest napisać aplikację skalowaną.
Jeśli Twoja aplikacja nie pasuje do modelu GAE, wybierz Azure lub AWS, w zależności od tego, czy piszesz dla stosu MS, i od tego, ile chcesz kontroli nad środowiskiem wykonywania. Jeśli większość aplikacji pasuje do GAE, ale małe części nie, możesz rozważyć hybrydę - na przykład serwowanie na żywo na GAE, ale przechowywanie na S3 lub przetwarzanie zbiorcze na EC2.
źródło
Dla mnie decydujące znaczenie ma blokada.
Jeśli wybierzesz dla Google, Twoja aplikacja będzie działać tylko w Google. Jeśli po jakimś czasie poczujesz się mniej niż zadowolony, utkniesz.
Jeśli wybierzesz MS, aplikacja będzie działać tylko na platformie Azure. Ta sama rzecz.
W Amazon masz (a) wirtualny serwer (y), które działają dokładnie tak samo jak maszyny, do których jesteś przyzwyczajony. Niezadowolony? Podnieś aplikację, zainstaluj na prawdziwym sprzęcie, gotowe.
źródło
Teraz moim osobistym wyborem będzie Google z Javą (nawet jeśli przez większość czasu jestem .NET). Pomyśl o kosztach - ich schemat jest trudny do porównania.
Sprawdź ten artykuł - http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure
źródło
Podobnie jak Arachnid, mogę być stronniczy, będąc googlerem. Jednak jestem też akcjonariusz Amazon, tak że nastawienie może częściowo skompensowany pierwszy ;-). Brak doświadczenia na platformie Azure (chociaż mam również akcje MSFT, więc mam nadzieję, że oni też mają się dobrze - kolejna stronniczość ;-).
Moje bardzo proste podejście polega na tym, że App Engine z łatwością oferuje możliwość pracy (w ramach swoich ograniczeń) po prostu przez kodowanie - żadne zadania administracyjne systemu nie są potrzebne. AWS jest znacznie bardziej elastyczny, ale aby skorzystać z tej elastyczności , będziesz potrzebować znacznej pracy administracyjnej systemu (i wcale nie jest tak trywialny). Tak więc na koniec opowiedziałbym się za sugestią Arachnida: jeśli App Engine może zaspokoić twoje potrzeby, koniecznie idź na całość; jeśli potrzebujesz większej elastyczności, AWS wydaje się właściwym rozwiązaniem (chyba, że funkcje Azure nieznane mi powinny być lepiej dopasowane - ale myślę, że AWS będzie bardziej elastyczny bez względu na to, co Azure może zrobić, na przykład z AWS może nawet wybrać, którego systemu operacyjnego użyć, jeśli tego potrzebujesz).
źródło
Właśnie zacząłem pracować z platformą Azure i jestem pod wrażeniem, że możesz to zrobić w F #: http://code.msdn.microsoft.com/fsharpazure! Jak dotąd jest to jedyna platforma chmurowa, która pozwala na zarządzanie funkcjami w sposób zarządzany (oczywiście Haskell w EC2 ... lub Algol 68 w tym przypadku). Jestem pod wrażeniem jakości integracji Visual Studio - otrzymujesz lokalną „chmurę” do przetestowania, DevFabric, z pamięcią, która jest prawdziwym SQL Server, więc możesz grać przed przesłaniem. Czy GAE może to zrobić? Patrząc na platformę Azure, ucząc się VS z F # (pochodzącym z Linuksa i OCamla), chciałbym już dawno przeszedłbym na stos MS. Tworzenie magazynu SQL i sprawdzanie go w VS jest bardzo łatwe - jest bardzo przydatne. Open Source nie ma pasującego zestawu narzędzi i nadszedł czas, aby ludzie dobrze rozważyli stwardnienie rozsiane - wykonali tutaj świetną robotę. Z pewnością trzymam się mojej bazy Mac OSX (podwójne uruchamianie do Visty), a moje przeczucie jest takie, z możliwością lokalnej platformy Azure, otrzymam osobne pudełko Vista do programowania platformy Azure. .NET jest naprawdę przytłaczający, kiedy pochodzisz ze świata potoku Unix - PowerShell, SQL i LINQ, C # i F # (co jest moim głównym powodem) - ale okazuje się, że wszystko się sumuje i warto się tego nauczyć, a nie zamiast tego z, Linux; i we wszystkich przypadkach Azure poszerzy Twoje horyzonty.
źródło
Mimo że uwielbiam GAE, jednym z głównych powodów, dla których wybieram EC2 zamiast GAE dla mojego obecnego projektu, jest to, że muszę mieć możliwość obsługi frontonu mojej aplikacji z centrów danych zlokalizowanych w różnych częściach świata. GAE działa w jednym centrum danych na raz. Na przykład potrzebuję użytkowników w Azji, aby trafić na serwery w Azji, aby uzyskać najszybszy możliwy czas odpowiedzi mojej aplikacji. Dodaj możliwość zarządzania dns, load balancerów, wybraną bazę danych, przepychanie kanałów do S3 w celu przetwarzania danych hadoop itp., A EC2 staje się naprawdę atrakcyjnym rozwiązaniem.
źródło
Kilka rzeczy do rozważenia:
Przyspieszanie: jak szybko można uzyskać produktywność w wybranym środowisku, jakie dokumenty istnieją i czy są to przejrzyste i dobrze obsługiwane próbki widoczne i przydatne
Koszt: koszt jest czynnikiem, ale jeśli tworzysz komercyjną aplikację, która faktycznie będzie miała klientów, wszystkie są wykonalne. Jeśli założysz, że platforma Azure z jednym procesem w „małej” instancji działa za około 90 USD miesięcznie za korzystanie z usługi 24x7 ... ilu użytkowników możesz obsłużyć w tym czasie? Dodaj drugi przypadek redundancji ... nadal nie jest tak kosztowny, jeśli twój ruch to uzasadnia. Jeśli nie, dlaczego jesteś w chmurze zamiast u taniego hostowanego dostawcy? Wdrożenie tego wiąże się z większymi kosztami. AWS to rozwiązanie własne. To wiele do zrobienia, aby uzyskać rozwiązanie, które będzie stabilne i dobrze zarządzane. Azure i GAE mają to od razu po wyjęciu z pudełka. Moim zdaniem AWS jest najdroższy ze względu na pracę, którą musisz w niego włożyć. Czy naprawdę potrzebujesz kontroli nad tym poziomem szczegółowości? W takim razie,
Możliwość robienia tego, co chcesz: AWS przez całą drogę. Azure jest drugi, GAE jest trzeci. Nie ma biggie, jeśli chcesz Java i Python. Biggie, jeśli chcesz zrobić relacyjną bazę danych lub rozbudowane wielowątkowe przetwarzanie danych w C ++ (nie jesteś pewien, czy którykolwiek z nich teraz to robi?).
Co z przenośnością? Czy możesz później zabrać go z powrotem na własną farmę lub przenieść na inną farmę chmurową? Wszystkie są do pewnego stopnia przenośne.
Wiele do przemyślenia ... wciąż się o tym uczę.
źródło
Jeśli musisz ręcznie uruchomić instancje, aby zaspokoić popyt, nie jest to chmura.
Azure i EC2 to tylko wirtualne serwery z niektórymi usługami z boku.
Aktualizacja:
EC2 i Azure oferują opcje automatycznego uruchamiania nowych wystąpień pod obciążeniem, ale nadal musisz tym zarządzać. I płacisz za instancje, które działają i są bezczynne.
GAE obsługuje to automatycznie po wyjęciu z pudełka i pobiera opłatę tylko za czas działania kodu podczas żądań.
źródło
Oto kilka innych uwag.
GAE - Siedzi wyżej na platformie jako stos usług niż AWS i Azure, cały ruch jest kierowany przez ich DNS ghs.google.com, dynamicznie ładując serwowanie twojej strony przez jeden z ich komputerów, co pozwala utrzymać niskie ceny. skalowanie jest drobnoziarniste przy takim podejściu, Wady nie są statyczne ip, podatne na filtrowanie lub blokowanie. Ze względu na brak statycznego ograniczenia adresu IP nie będzie można skonfigurować żadnego certyfikatu https specyficznego dla witryny.
AWS i Azure dają prawie statyczny adres IP i dedykowaną maszynę wirtualną, co pozwala na spełnienie podstawowych wymagań, takich jak certyfikat https. otrzymasz także obsługę pamięci relacyjnej. Koszt jest również wyższy, aby odzwierciedlić ten dedykowany fakt dotyczący maszyny wirtualnej, a będziesz skalować na maszynę wirtualną, więc w kawałkach po 40 dolarów / miesiąc. Zaletą jest to, że ponieważ masz maszynę wirtualną dla siebie, nie jesteś ograniczony do 30-sekundowego ograniczenia przetwarzania procesora na GAE i możesz wykonywać większe zadania.
Więc jeśli rozważasz bazy klientów w filtrowanych krajach, chcesz, aby statyczny adres IP wykonał własną konfigurację DNS lub masz wymagania wymagające relacyjnej db lub więcej niż 30 sekundowych zadań. AWS, Azure byłby o wiele bardziej przyjazny w pracy.
źródło
Spójrz na rozwiązania oferowane przez każdą chmurę i wybierz model hybrydowy. Niektóre problemy wymagają młotka, a inne śrubokrętu. Poznaj swoje narzędzia i zastosuj je do właściwego problemu.
źródło
Nie mam wystarczającej reputacji, aby zostawić komentarz do jednej z powyższych odpowiedzi. Przydatność któregokolwiek z tych rozwiązań chmurowych zależy od wielu czynników, w tym twoich potrzeb i zestawu umiejętności.
Mam projekt sieci społecznościowej, który wymaga bazy danych nosql. AppEngine byłby dobrym rozwiązaniem, gdyby lepiej wspierał różne frameworki. Django z adapterem nonrel działa na Python GAE, ale wolę Railsy z wielu powodów. Rails3 jest dostępny od kilku miesięcy i nikt w społeczności lub w zespole GAE nie napisał jeszcze przepisu na jego poparcie. O ile nie masz zestawu umiejętności - znajomość elementów wewnętrznych rubinowych i szynowych, elementów wewnętrznych krzaczastych i GAE - do napisania własnego przepisu, jesteś na łasce innych ludzi, aby dostać się na platformę.
AWS to dużo więcej pracy, ale przynajmniej możesz wejść na platformę za pomocą dowolnych narzędzi i poradzić sobie z wieloma problemami administracyjnie, a nie jako programista wewnętrzny lub suplikant do wyższych uprawnień.
Moja skarga na Heroku i EngineYard, dla deweloperów Ruby, jest zagadką dotyczącą skalowania baz danych. Jak skalują się?
W moim przypadku wybieram rozwiązanie NoSQL i Mongo wydaje się być dobrym wyborem. MongoMachine wydaje się być zalecanym rozwiązaniem dla takich jak Heroku lub EY, ale jest szalenie drogi. 2,50 USD za GB? Pamięć masowa kosztuje tylko 0,10 GB / mc w GAE lub EBS.
źródło
Niedawno zacząłem eksperymentować z Google App Engine i sądzę, że w przypadku sieci społecznościowej spełniłaby wszystkie Twoje potrzeby. Łatwo go zrozumieć i można go używać z Pythonem lub Javą. To prawda, że nie daje ci dostępu do plików, ale dla twojej aplikacji GQL (podobny do SQL interfejs do bazy danych, którą zapewniają) prawdopodobnie będzie więcej niż wystarczający (i jest dość solidny).
Jedną z rzeczy, które warto rozważyć, jest to, że aplikacja GAE może korzystać z interfejsu, który pozwala użytkownikom z kontami Google lub kontami w domenie za pomocą Google Apps zalogować się (skrót). Wybierz jeden z nich. Jeśli już korzystasz z witryny Google Apps, Google App Engine byłby dla Ciebie doskonałym wyborem, ponieważ użytkownicy nie musieliby rejestrować nowych kont.
EDYCJA: Jak zauważył Arachnid, nie jest tak, że nie możesz kodować własnego systemu logowania. Przepraszam, jeśli cię tam zmartwiłem.
Jeśli chodzi o pozostałe dwie alternatywy, przeczytałem tylko o nich i ich nie przetestowałem. Ale wierzę, że GAE zapewnia łatwiejsze ramy, z moich badań i, jak wspomniałeś, świetne ceny.
W każdym razie możesz wypróbować GAE, korzystając z bezpłatnego limitu miejsca i przepustowości i sprawdzić, czy pasuje to do twoich potrzeb.
Powodzenia.
źródło
Azure ma Windows / SQL jako serwer „Platform as a Service” i na pewno NIE utkniesz, po prostu wróć do Windows / SQL we własnym centrum danych (bez linuksa, ale tak, obsługują Java, Python, PHP, Ruby, Tomcat , Apache itp.). Podobnie jak Amazon, będą również oferować w pełni dostępną opcję Maszyny wirtualnej, dzięki czemu możesz zainstalować / uruchomić, co chcesz.
Amazon ma tylko maszynę wirtualną, więc nadal musisz instalować, łatać, licencjonować, zabezpieczać itp. W pewnym sensie, moim zdaniem, pokonanie korzyści płynących z chmury. Właśnie przeniosłeś coś z centrum danych do innego.
Google nie ma relacyjnej bazy danych, a STUCK nie działałby. W rzeczywistości są one przeznaczone tylko dla programistów Python i mają ograniczoną obsługę Java. Moim zdaniem naprawdę nie są graczem w przestrzeni chmurowej.
źródło
Jedną rzeczą nie wymienioną tutaj, jest to, co ktokolwiek uważa za „Windows Azure AppFabric Service Bus & ACS” oprócz przerażającej nazwy…?
Wygląda na to, że jest to naprawdę potężny zestaw funkcji integracyjnych, które sprawiłyby, że Azure był atrakcyjny z perspektywy każdej firmy z inwestycją w infrastrukturę lokalną.
źródło
Po pewnym czasie eksperymentowania z Amazon EC2 i opóźnieniu zacząłem badać Google Apps podczas eksperymentów z powodu kosztów. Wolę Erlang jako język programowania, ale radzę sobie z Pythonem, więc nie było to decydującym czynnikiem. Tak było, gdy nie widziałem statycznego adresu IP. Również cała ta część, że jest wyżej na stosie, trochę mnie denerwuje pod względem wydajności.
Chciałbym, żeby AWS było tańsze, ale dopóki Google nie dostarczy statycznych adresów IP i najlepiej dodatkowych języków, takich jak Scala, JRuby i Erlang, wybór jest dla mnie jasny: AWS . Dwa pierwsze języki również powinny być proste, oba są oparte na JVM. Może nawet zostało to zrobione poprzez obejście, jak się wydaje, pamiętam coś o tym.
źródło
Myślę, że oprócz myślenia o tym, jaką platformę obsługuje porównanie, skalowalność, łatwość dostępu, wszechstronność (pod względem implementacji), może pomieścić różne platformy hostingowe, równie opłacalne ekonomicznie w przypadku biznesowym, ma wiele rozwiązań dla przedsiębiorstw aplikacje (tj. przechowywanie, dostawa, przepustowość, zasady licencjonowania itp.), wiarygodność historii jakości usług, kontrola bezpieczeństwa, przejrzystość fakturowania i kosztów itp. Jeśli spojrzysz na wszystkie powyższe wskaźniki, czuję, że wyniki AWS znacznie przewyższają . Zarządzam 10 kontami produkcyjnymi w AWS od 2 lat i jednocześnie firma / jednostka biznesowa były w stanie zaspokoić ogromne wymagania klienta dotyczące skalowalności .... Bez wątpienia w AWS należy utrzymywać infrastrukturę, Aktualizacje (jeśli takie / jeśli wymagane), bezpieczeństwo itp. Ale masz wszystkie narzędzia dostępne na rynku / netto za darmo. Istniejące zasoby IT mogą również utrzymywać całą infrastrukturę AWS.
Azure z pewnością ma zintegrowane IDE z VS 2010, ale faktyczne wyceny dowolnej chmury rozpoczną się po pomyślnym wdrożeniu aplikacji (platforma do wdrożenia). Wciąż długa droga do dojrzałości, aby zająć się scenariuszami wdrażania / skalowalnej produkcji w czasie rzeczywistym ... Jak wszyscy wiedzą, MS gra wiele ukrytych programów na kosztach .. bardzo trudno jest rozliczyć koszty poniesione lub poniesione (podczas wysyłania szacunki).
GAE jest bardzo specyficzny dla aplikacji Python / Java. Ogromny wysiłek (zarówno pod względem zasobów, jak i kosztów) w przepisaniu (istniejącej) aplikacji, przetestowaniu, wdrożeniu itp.
źródło