Jaka jest różnica między Google App Engine a Google Compute Engine?

Zastanawiałem się, jaka jest różnica między App Engine a Compute Engine. Czy ktoś może mi wyjaśnić różnicę?

App Engine to platforma jako usługa. Oznacza to, że po prostu wdrażasz swój kod, a platforma robi wszystko za Ciebie. Na przykład, jeśli Twoja aplikacja odniesie duży sukces, App Engine automatycznie utworzy więcej instancji, aby obsłużyć zwiększoną głośność.

Przeczytaj więcej o App Engine

Silnik obliczeniowy jest infrastrukturą jako usługa. Musisz utworzyć i skonfigurować własne wystąpienia maszyny wirtualnej. Daje to większą elastyczność i ogólnie kosztuje znacznie mniej niż App Engine. Wadą jest to, że musisz samodzielnie zarządzać aplikacją i maszynami wirtualnymi.

Dowiedz się więcej o Compute Engine

W razie potrzeby możesz łączyć zarówno App Engine, jak i Compute Engine. Oba działają dobrze z innymi częściami Google Cloud Platform .

EDYCJA (maj 2016):

Jeszcze jedno ważne rozróżnienie: projekty działające w App Engine mogą zostać zmniejszone do zera instancji, jeśli nie przychodzą żadne żądania. Jest to niezwykle przydatne na etapie programowania, ponieważ możesz pracować przez tygodnie, nie przekraczając hojnego bezpłatnego limitu godzin instancji. Elastyczne środowisko wykonawcze (tj. „Zarządzane maszyny wirtualne”) wymaga co najmniej jednego wystąpienia do ciągłego działania.

EDYCJA (kwiecień 2017 r.):

Funkcje w chmurze (obecnie w wersji beta) to kolejny poziom w stosunku do App Engine pod względem abstrakcji - żadnych przypadków! Umożliwia programistom wdrażanie fragmentów kodu o rozmiarze kęsa, które są wykonywane w odpowiedzi na różne zdarzenia, które mogą obejmować żądania HTTP, zmiany w chmurze itp.

Największą różnicą w App Engine jest to, że funkcje są wyceniane na 100 milisekund, podczas gdy instancje App Engine zamykają się dopiero po 15 minutach bezczynności. Kolejną zaletą jest to, że funkcje w chmurze są uruchamiane natychmiast, podczas gdy wywołanie App Engine może wymagać nowej instancji - a zimne uruchomienie nowej instancji może potrwać kilka sekund lub dłużej (w zależności od środowiska wykonawczego i kodu).

To sprawia, że ​​Funkcje w chmurze są idealne do (a) rzadkich połączeń - nie trzeba utrzymywać instancji na wypadek, gdyby coś się wydarzyło, (b) szybko zmieniających się obciążeń, w których instancje często się obracają i wyłączają, i ewentualnie więcej przypadków użycia.

Przeczytaj więcej o funkcjach chmury

Podstawowa różnica polega na tym, że Google App Engine ( GAE ) to platforma jako usługa ( PaaS ), natomiast Google Compute Engine ( GCE ) to infrastruktura jako usługa ( IaaS ) .

Aby uruchomić aplikację w GAE, wystarczy napisać kod i wdrożyć go w GAE, bez innych problemów. Ponieważ GAE jest w pełni skalowalny, automatycznie pobierze więcej wystąpień w przypadku wzrostu ruchu i zmniejszy liczbę wystąpień, gdy ruch spadnie. Zostaniesz obciążony za zasoby, których naprawdę używasz , to znaczy, że naliczone zostaną opłaty za godziny wystąpienia , przesłane dane , przechowywanie itp., Z których naprawdę korzystała Twoja aplikacja. Ale ograniczenie polega na tym, że możesz utworzyć aplikację tylko w języku Python, PHP, Java, NodeJS, .NET, Ruby i ** Go .

Z drugiej strony GCE zapewnia pełną infrastrukturę w postaci maszyny wirtualnej . Masz pełną kontrolę nad środowiskiem i środowiskiem wykonawczym tych maszyn wirtualnych, ponieważ możesz tam pisać lub instalować dowolny program. W rzeczywistości GCE jest sposobem wirtualnego korzystania z centrów danych Google. W GCE musisz ręcznie skonfigurować infrastrukturę do obsługi skalowalności za pomocą modułu równoważenia obciążenia .

Zarówno GAE, jak i GCE są częścią Google Cloud Platform .

Aktualizacja: w marcu 2014 r. Google ogłosił nową usługę w ramach App Engine o nazwie Managed Virtual Machine . Zarządzane maszyny wirtualne oferują aplikacjom aplikacji nieco większą elastyczność w stosunku do platformy aplikacji, procesora i opcji pamięci. Podobnie jak GCE, możesz stworzyć niestandardowe środowisko wykonawcze na tych maszynach wirtualnych dla aplikacji silnika aplikacji. Rzeczywiście zarządzane maszyny wirtualne App Engine do pewnego stopnia zacierają granicę między IAAS i PAAS.

Krótko mówiąc: silnik obliczeniowy daje serwer, nad którym masz pełną kontrolę / odpowiedzialność. Masz bezpośredni dostęp do systemu operacyjnego i instalujesz całe oprogramowanie, które chcesz, zwykle jest to serwer WWW, baza danych itp.

W silniku aplikacji nie zarządzasz systemem operacyjnym żadnego z bazowych programów. Przesyłasz tylko kod (Java, PHP, Python lub Go) i voila - po prostu działa ...

Silnik aplikacji oszczędza mnóstwo bólu głowy, szczególnie dla niedoświadczonych ludzi, ale ma 2 istotne wady: 1. droższe (ale ma darmowy przydział, którego nie ma silnik obliczeniowy) 2. masz mniejszą kontrolę, więc niektóre rzeczy po prostu nie są możliwe lub możliwe tylko w jeden określony sposób (na przykład zapisywanie i zapisywanie plików).

Lub jeszcze bardziej upraszczając (ponieważ czasami nie rozróżniamy GAE Standard od GAE Flex):

Compute Engine jest analogiczny do wirtualnego komputera, na którym można na przykład wdrożyć małą stronę internetową + bazę danych. Zarządzasz wszystkim, w tym kontrolą zainstalowanych napędów dysków. Jeśli wdrażasz witrynę internetową, jesteś odpowiedzialny za konfigurację DNS itp.

Google App Engine (Standard) jest jak folder piaskownicy tylko do odczytu, w którym przesyłasz kod do wykonania i nie martwisz się resztą (tak: tylko do odczytu - jest dla ciebie zainstalowany zestaw bibliotek i nie możesz go wdrożyć Biblioteki stron trzecich do woli). DNS / Subdomeny itp. Są o wiele łatwiejsze do zmapowania.

Google App Engine (elastyczny) jest w rzeczywistości jak cały system plików (nie tylko zamknięty folder), w którym masz więcej mocy niż silnik standardowy, np. Masz uprawnienia do odczytu / zapisu (ale mniej w porównaniu do silnika obliczeniowego ). W standardzie GAE masz zainstalowany zestaw bibliotek i nie możesz wdrożyć bibliotek stron trzecich do woli. W środowisku elastycznym możesz zainstalować dowolną bibliotekę, od której zależy Twoja aplikacja, w tym niestandardowe środowiska budowania (takie jak Python 3).

Mimo że GAE Standard jest bardzo uciążliwy (chociaż Google upraszcza go), skaluje się naprawdę dobrze, gdy znajduje się pod presją. Jest to uciążliwe, ponieważ musisz przetestować i zapewnić zgodność ze zablokowanym środowiskiem oraz upewnić się, że używana biblioteka innej firmy nie korzysta z żadnej innej biblioteki innej firmy, której nieświadomość może nie działać w standardzie GAE. Konfiguracja zajmuje więcej czasu, ale w dłuższym okresie może być bardziej satysfakcjonująca w przypadku prostych wdrożeń.

Oprócz notatek App Engine vs. Compute Engine powyższa lista zawiera także porównanie z Google Kubernete Engine i kilka notatek opartych na doświadczeniu z szeroką gamą aplikacji od małych do bardzo dużych. Aby uzyskać więcej punktów, zobacz dokumentację Google Cloud Platform opis wysokiego poziomu funkcji App Engine Standard i Flex na stronie Wybieranie środowiska App Engine . Inne porównanie wdrożenia App Engine i Kubernetes znajduje się w poście Daz Wilkin App Engine Flex lub Kubernetes Engine .

App Engine Standard

Plusy

• Bardzo ekonomiczny w przypadku aplikacji o niskim natężeniu ruchu pod względem kosztów bezpośrednich, a także kosztów utrzymania aplikacji.
• Automatyczne skalowanie jest szybkie. Automatyczne skalowanie w App Engine opiera się na lekkich klasach instancji F1-F4 .
• Zarządzanie wersjami i podział ruchu są szybkie i wygodne. Funkcje te są wbudowane w App Engine (zarówno standardowy, jak i Flex) natywnie.
• Minimalne zarządzanie, programiści muszą skupić się tylko na swojej aplikacji. Programiści nie muszą się martwić o zarządzanie maszynami wirtualnymi w niezawodny sposób, jak w GCE, ani o uczenie się na temat klastrów, jak w przypadku GKE.
• Dostęp do magazynu danych jest szybki. Kiedy App Engine został wydany po raz pierwszy, środowisko wykonawcze znajdowało się w tej samej lokalizacji co Datastore. Później Datastore został wydzielony jako samodzielny produkt Cloud Datastore, ale kolokacja App Engine Standard obsługująca Datastore pozostaje.
• Dostęp do Memcache jest obsługiwany.
• Piaskownica App Engine jest bardzo bezpieczna. W porównaniu z programowaniem na GCE lub innych maszynach wirtualnych, w których musisz zrobić wszystko, aby maszyna wirtualna nie została przejęta na poziomie systemu operacyjnego, piaskownica App Engine Standard jest domyślnie stosunkowo bezpieczna.

Cons

• Ogólnie bardziej ograniczone niż w innych środowiskach. Instancje są mniejsze. Chociaż jest to dobre w przypadku szybkiego automatycznego skalowania, wiele aplikacji może korzystać z większych instancji, takich jak rozmiary instancji GCE do 96 rdzeni.
• Sieć nie jest zintegrowana z GCE
• Nie można umieścić App Engine za modułem równoważenia obciążenia Google Cloud. Ograniczone do obsługiwanych środowisk wykonawczych: Python 2.7, Java 7 i 8, Go 1.6-1.9 i PHP 5.5. W Javie istnieje pewna obsługa serwletów, ale nie pełny standard J2EE.

App Engine Flex

Plusy

• Może korzystać z niestandardowego środowiska wykonawczego
• Natywna integracja z siecią GCE
• Zarządzanie wersjami i ruchem jest wygodne, podobnie jak Standard
• Większe rozmiary instancji mogą być bardziej odpowiednie dla dużych złożonych aplikacji, zwłaszcza aplikacji Java, które mogą zużywać dużo pamięci

Cons

• Integracja sieci nie jest doskonała - brak integracji z wewnętrznymi modułami równoważenia obciążenia lub współdzielonymi wirtualnymi chmurami prywatnymi
• Dostęp do zarządzanego Memcache nie jest ogólnie dostępny

Google Kubernetes Engine

Plusy

• Natywna integracja z kontenerami umożliwia niestandardowe środowiska wykonawcze i większą kontrolę nad konfiguracją klastra.
• Uosabia wiele najlepszych praktyk pracy z maszynami wirtualnymi, takich jak niezmienne środowiska uruchomieniowe i łatwa możliwość przywrócenia poprzednich wersji
• Zapewnia spójne i powtarzalne ramy wdrażania
• Oparty na otwartych standardach, zwłaszcza Kubernetes, dla przenośności między chmurami a lokalnymi.
• Zarządzanie wersjami można osiągnąć za pomocą kontenerów Docker i rejestru kontenerów Google

Cons

• Podział ruchu i zarządzanie nim jest zrób to sam, prawdopodobnie wykorzystując Istio i wysłannika
• Niektóre koszty ogólne zarządzania
• Trochę czasu na rozwinięcie koncepcji Kubernetes, takich jak strąki, wdrożenia, usługi, wejście i przestrzenie nazw
• Musisz ujawnić niektóre publiczne adresy IP, chyba że korzystasz z klastrów prywatnych , teraz w fazie beta, eliminujesz tę potrzebę, ale nadal musisz zapewnić dostęp do lokalizacji, z których będą uruchamiane polecenia kubectl.
• Monitorowanie integracji nie jest idealne
• Podczas gdy wewnętrzne równoważenie obciążenia L3 jest obsługiwane natywnie w silniku Kubernetes Engine, wewnętrzne równoważenie obciążenia L7 jest zrób to sam, prawdopodobnie wykorzystując Envoy

Silnik obliczeniowy

Plusy

• Łatwe uruchamianie - nie ma potrzeby zwiększania wydajności w Kubernetes lub App Engine, wystarczy ponownie wykorzystać wszystko, co wiesz z poprzednich doświadczeń. Jest to prawdopodobnie główny powód bezpośredniego korzystania z silnika obliczeniowego.
• Pełna kontrola - możesz bezpośrednio korzystać z wielu funkcji silnika obliczeniowego i instalować najnowsze ze swoich ulubionych rzeczy, aby pozostać na czele.
• Nie potrzeba publicznych adresów IP. Niektóre starsze oprogramowanie może być zbyt trudne do zablokowania, jeśli coś jest ujawnione w publicznych adresach IP.
• Możesz wykorzystać system operacyjny zoptymalizowany pod kątem kontenerów do uruchamiania kontenerów Docker

Cons

• Przeważnie zrób to sam, co może być trudne do zrobienia w celu zapewnienia niezawodności i bezpieczeństwa, chociaż możesz ponownie używać rozwiązań z różnych miejsc, w tym z Cloud Launcher.
• Więcej kosztów zarządzania. Istnieje wiele narzędzi do zarządzania dla Compute Engine, ale niekoniecznie zrozumieją, jak wdrożyłeś swoją aplikację, tak jak robią to App App i Kubernetes Engine
• Automatyczne skalowanie opiera się na instancjach GCE, które mogą być wolniejsze niż App Engine
• Tendencja polega na instalowaniu oprogramowania w instancjach GCE typu snowflake, co może wymagać pewnego wysiłku

Jak już wyjaśniono, Google Compute Engine (GCE) to infrastruktura jako usługa (IaaS), natomiast Google App Engine (GAE) to platforma jako usługa (PaaS). Możesz sprawdzić poniższy schemat, aby lepiej zrozumieć różnicę (wzięto z i lepiej wyjaśniono tutaj ) -

Google Compute Engine
GCE to ważna usługa świadczona z Google Cloud Platform (GCP), ponieważ większość usług GCP korzysta z instancji GCE (VM) pod warstwą zarządzania (nie jestem pewien, która z nich nie korzysta). Obejmuje to silnik aplikacji, funkcje chmury, silnik Kubernetes (wcześniejszy silnik kontenera), chmurę SQL itp. Wystąpienia GCE są najbardziej konfigurowalną jednostką, dlatego należy ich używać tylko wtedy, gdy aplikacja nie może działać na innych usługach GCP. Przez większość czasu ludzie używają GCE do przesyłania swoich aplikacji On-Prem do GCP, ponieważ wymaga to minimalnych zmian. Później mogą wybrać inne usługi GCP dla osobnego komponentu swoich aplikacji.

Google App Engine
GAE to pierwsza usługa oferowana przez GCP (na długo przed Google przyszedł do biznesu w chmurze). Automatycznie skaluje od 0 do nieograniczonej liczby instancji (używa GCE pod spodem). Pochodzi z 2 smakami Standardowe środowisko i Elastyczne środowisko.

Standardowe środowisko jest naprawdę szybkie, skaluje się do zera, gdy nikt nie korzysta z Twojej aplikacji, skaluje się w górę i w dół w ciągu kilku sekund i ma dedykowane usługi Google i biblioteki do buforowania, uwierzytelniania itp. Zastrzeżenie dotyczące Standardowego środowiska polega na tym, że jest bardzo restrykcyjne ponieważ działa w piaskownicy. Zarządzanych środowisk wykonawczych należy używać tylko dla określonych języków programowania. Najnowsze dodatki to Node.js (8.x) i Python 3.x. Starsze środowiska wykonawcze są dostępne dla Go, PHP, Python 2.7, Java itp.

Elastyczne środowisko jest bardziej otwarte, ponieważ umożliwia korzystanie z niestandardowych środowisk wykonawczych, ponieważ wykorzystuje kontenery dokerów. Dlatego jeśli środowisko wykonawcze nie jest dostępne w podanych środowiskach uruchomieniowych, zawsze możesz utworzyć własny plik docker dla środowiska wykonawczego. Zastrzeżenie to wymaga, aby działała co najmniej 1 instancja, nawet jeśli nikt nie korzysta z Twojej aplikacji, a skalowanie w górę i w dół wymaga kilku minut.

Nie myl GAE elastycznego z Kubernetes Engine, ponieważ ten ostatni wykorzystuje rzeczywisty Kubernetes i zapewnia znacznie więcej możliwości dostosowywania i funkcji. GAE Flex jest przydatny, gdy chcesz kontenerów bezstanowych, a Twoja aplikacja korzysta tylko z protokołów HTTP lub HTTPS. W przypadku innych protokołów jedynym wyborem jest Kubernetes Engine (GKE) lub GCE. Sprawdź moją drugą odpowiedź, aby uzyskać lepsze wyjaśnienie.

App Engine daje programistom możliwość kontrolowania rdzeni Google Compute Engine, a także zapewnia dostęp do Internetu dla aplikacji do przetwarzania danych Google Compute Engine.

Z drugiej strony Compute Engine oferuje bezpośrednie i pełne zarządzanie systemem operacyjnym maszyn wirtualnych. Aby zaprezentować swoją aplikację, będziesz potrzebować zasobów, a Google Cloud Storage idealnie nadaje się do przechowywania zasobów i danych, bez względu na to, do czego służą. Otrzymujesz szybki dostęp do danych dzięki hostingowi na całym świecie. Niezawodność jest gwarantowana przy czasie działania wynoszącym 99,95%, a Google zapewnia również możliwość tworzenia kopii zapasowych i przywracania danych oraz, jeśli wierzysz lub nie, pamięć jest nieograniczona.

Możesz zarządzać swoimi zasobami za pomocą Google Cloud Storage, przechowując, pobierając, wyświetlając i usuwając je. Możesz także szybko odczytywać i zapisywać w płaskich arkuszach danych przechowywanych w chmurze. Kolejnym w składzie Google Cloud jest BigQuery. Dzięki BigQuery możesz analizować ogromne ilości danych, mówimy o milionach rekordów w ciągu kilku sekund. Dostęp jest obsługiwany za pomocą prostego interfejsu użytkownika, reprezentatywnego transferu stanu lub interfejsu REST.

Przechowywanie danych nie jest, jak można podejrzewać, problemem i skaluje się do setek TB. BigQuery jest dostępny za pośrednictwem wielu bibliotek klienckich, w tym bibliotek Java, .NET, Python, Go, Ruby, PHP i JavaScript. Dostępna jest składnia podobna do SQL o nazwie NoSQL, do której można uzyskać dostęp za pośrednictwem tych bibliotek klienckich lub interfejsu sieciowego. Na koniec pomówmy o opcjach bazy danych platformy Google Cloud, Cloud SQL i Cloud Datastore.

Jest duża różnica. Cloud SQL jest przeznaczony dla relacyjnych baz danych, głównie MySQL, natomiast Cloud Datastore jest przeznaczony dla nierelacyjnych baz danych korzystających z noSQL. Dzięki Cloud SQL masz do wyboru hosting w USA, Europie lub Azji, ze 100 GB pamięci i 16 GB pamięci RAM na instancję bazy danych.

Cloud Datastore jest dostępny bezpłatnie dla maksymalnie 50 000 instrukcji odczytu / zapisu na miesiąc i 1 GB danych przechowywanych również na miesiąc. Jednak przekroczenie tych kwot jest płatne. App Engine może również współpracować z innymi mniej znanymi, bardziej ukierunkowanymi członkami platformy Google Cloud, w tym z punktami końcowymi chmury do tworzenia zaplecza interfejsu API, interfejsem API Google Prediction do analizy danych i prognozowania trendów lub interfejsem API Google Translate dla wyników wielojęzycznych.

Chociaż App Engine jest w stanie zrobić całkiem sporo, sam w sobie jest potencjalny, gdy weźmie się pod uwagę jego zdolność do łatwej i wydajnej pracy z innymi usługami platformy Google Cloud.

Jeśli znasz inne popularne usługi:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku lub AWS Elastic Beanstalk

Funkcje Google Cloud -> Funkcje AWS Lambda

Wyjaśnię to w sposób, który miał dla mnie sens:

• Compute Engine : jeśli jesteś zrób to sam lub masz zespół IT i chcesz po prostu wynająć komputer w chmurze, który ma określony system operacyjny (na przykład Linux), wybierz Compute Engine. Musisz zrobić wszystko sam.

• App Engine : Jeśli jesteś (na przykład) programistą python i chcesz wynająć wstępnie skonfigurowany komputer w chmurze, który ma Linux z działającym serwerem internetowym i najnowszy python 3 z niezbędnymi modułami i niektórymi wtyczkami do integracji z inne usługi zewnętrzne, wybierz App Engine.

• Bezserwerowy kontener (Cloud Run) : Jeśli chcesz wdrożyć dokładny obraz lokalnego środowiska instalacyjnego (na przykład: python 3.7 + flask + sklearn), ale nie chcesz zajmować się serwerem, skalowaniem itp. Tworzysz kontener na komputerze lokalnym (za pomocą dokera), a następnie wdróż go w Google Run.

• Mikrousługa bezserwerowa (funkcje w chmurze) : jeśli chcesz napisać kilka interfejsów API (funkcji) wykonujących określone zadania, wybierz Google Cloud Functions. Po prostu skupiasz się na tych konkretnych funkcjach, a reszta zadania (serwer, konserwacja, skalowanie itp.) Jest wykonywana dla Ciebie, aby udostępnić twoje funkcje jako mikrousługi.

W miarę wchodzenia głębiej tracisz elastyczność, ale nie martwisz się niepotrzebnymi aspektami technicznymi. Płacisz także trochę więcej, ale oszczędzasz czas i koszty (część informatyczna): ktoś inny (Google) robi to za Ciebie.

Jeśli nie chcesz dbać o równoważenie obciążenia, skalowanie itp., Bardzo ważne jest podzielenie aplikacji na kilka „bezstanowych” usług internetowych, które zapisują wszystko, co trwałe w oddzielnym magazynie (baza danych lub magazyn obiektów blob). Następnie dowiesz się, jak niesamowite jest Cloud Run i funkcje w chmurze.

Osobiście uważam, że Google Cloud Run to niesamowite rozwiązanie, absolutna swoboda w rozwoju (tak długo jak bezstanowy), eksponuj go jako usługę internetową, zadokuj swoje rozwiązanie, wdróż go z Cloud Run. Niech Google będzie Twoim IT i DevOps, nie musisz się martwić skalowaniem i konserwacją.

Wypróbowałem wszystkie inne opcje i każda z nich nadaje się do różnych celów, ale Google Run jest po prostu niesamowity. Dla mnie jest to prawdziwy serwer bez utraty elastyczności w programowaniu.

Usługi w chmurze zapewniają szereg opcji - od usług w pełni zarządzanych po usługi mniej zarządzane. Mniej zarządzane usługi dają programistom większą kontrolę. To samo dotyczy różnicy w silnikach obliczeniowych i aplikacyjnych. Poniższy obraz przedstawia więcej na ten temat

Google Compute Engine (GCE)

Maszyny wirtualne (VM) hostowane w chmurze. Przed chmurą były one często nazywane wirtualnymi serwerami prywatnymi (VPS). Używałbyś ich w taki sam sposób jak fizyczny serwer, na którym instalujesz i konfigurujesz system operacyjny, instalujesz aplikację, instalujesz bazę danych, aktualizujesz system operacyjny itp. Jest to znane jako infrastruktura jako usługa (IaaS).

Maszyny wirtualne są najbardziej przydatne, gdy w centrum danych masz istniejącą aplikację uruchomioną na maszynie wirtualnej lub serwerze i chcesz łatwo migrować ją do GCP.

Silnik Aplikacji Google

App Engine hostuje i uruchamia kod, bez konieczności zajmowania się systemem operacyjnym, obsługą sieci i wieloma innymi rzeczami, którymi trzeba zarządzać za pomocą fizycznego serwera lub maszyny wirtualnej. Potraktuj to jako środowisko wykonawcze, które może automatycznie wdrażać, wersjonować i skalować aplikację. Nazywa się to Platform-as-a-Service (PaaS).

App Engine jest najbardziej przydatny, gdy chcesz zautomatyzować wdrażanie i automatyczne skalowanie aplikacji. O ile Twoja aplikacja nie wymaga niestandardowej konfiguracji systemu operacyjnego, App Engine jest często korzystniejszy niż ręczne konfigurowanie maszyn wirtualnych i zarządzanie nimi.