Pros and Cons of Google App Engine

[Updated list on August 21, 09]

Help me list all the advantages and disadvantages of building an application in Google App Engine

Pros:

  • No need to buy servers or server space (no maintenance).
  • Helps solve the problem of scaling.
  • Free to a certain level of consumed resources.

Minuses:

  • Blocked by Google App Engine?
  • Developers have read-only access to the file system in App Engine.
  • App Engine can only execute code called from an HTTP request (except for scheduled background tasks).
  • Users can load arbitrary Python modules, but only if they are pure Python; C and Pyrex are not supported.
  • App Engine limits the maximum number of lines returned from an object to 1000 lines per Datastore call. ( Update ) - App Engine now supports cursors to access larger queries)
  • Java applications can only use a subset of the (white class of the JRE class) classes from the standard version of the JRE.
  • Java applications cannot create new threads.

Known issues! : http://code.google.com/p/googleappengine/issues/list

Hard limits

Developer Applications - 10
Order time - 30 seconds. Files per application - 3000.
HTTP response size - 10 MB
Data Warehouse Size - 1 MB
Application Code Size - 150 MB
Blob Storage update now allows you to store files up to 50 MB

Pro or Con?
The App Engine infrastructure addresses many system administration and application development issues to scale to millions of hits. Google handles cluster code deployment, monitoring, crash recovery, and launching application instances as needed.

While other services allow users to install and configure almost any * NIX compatible software, App Engine requires developers to use Python or Java as a programming language and a limited set of APIs. Current APIs allow you to store and retrieve data from a non-relational BigTable database; Executing HTTP requests Email sending image manipulation; and caching. Most existing web applications cannot run on App Engine unchanged because they require a relational database.

+66
google-app-engine
Aug 20 '09 at 13:41
source share
11 answers

Pros:

  • Scalability
  • Easy and cheap (in the short term).
  • A good option for beginners / individuals.
  • Suitable for applications that simply store and retrieve data.

Minuses:

  • Not suitable for intensive CPU calculations. They are slower and more expensive.
  • Scalability doesn't really matter, because if the application runs on a Google scale, then it probably makes enough money to run on its servers.
  • They have many limitations thrown here and there, and as a result, in-depth data analysis is difficult. How can you not create a social graph using GAE.

I would say that this is not intended for serious enterprises and expensive in the long run.

+15
Aug 20 '09 at 14:23
source share

(Huge new) PRO: GAE now supports MySQL : https://developers.google.com/cloud-sql/

+12
Feb 27 2018-12-12T00:
source share

Pros:

  • built-in ui for unified magazines

  • integrated web interface for task queues

  • embedded indexes in the list of primary objects.

Minuses:

  • fast magazines are very fast

  • Very expensive

  • Very expensive

  • Very expensive

  • Un-hack. Scale because you are required to code in a way that scales.

  • Longer development cycles. Sometimes you just want to hack something and throw it away after 5 hours. With appengine, you must correctly encode it and write a lot of material to make sure it scales. You can't just do "find. | Grep.avi | xargs ffmpeg -compress ...." :)

  • You’ll lose hours trying to complete the simplest tasks, such as sending push notifications to APNS (iPhone). Although it’s great if you only want to support android in the future.

  • It's terrible to do the cleanup in the database. It is a BIG ass pain to fix rows in the database, mainly because it's terribly slow, but also requires a lot of code to loop correctly within this time limit.

  • It was painful to port Lucene to work on her “file system”.

  • Slowly for what you pay.

  • Even MORE more expensive if your app has traffic spikes. My application has these spikes if a user who has many followers takes an action and we need to push notifications to his followers. Because of this, I have to constantly keep 10 inactive servers ($$$$$) to handle outbreaks.

Appengine is not so bad because I have the ability to write $$$$ instead of worrying about scalability and bottlenecks to reduce server usage. Sometimes it's worth it.

My advice to people starting new products is to go with hetzner.de, where I host my other product servers. It is cheap and extremely hacked. I have one server in hetzner that processes 3 times more traffic than the product that I have on appengine. The price difference is $ 100 per month version of $ 2700 per month!

I have a system administrator, so the main reason is that I would never choose appengine because of my own ROOT server. Do not be a bored software engineer who wants to experiment with new things and not create great products!

+6
Jan 10 '13 at 0:22
source share

Pro: Unlimited scalability for your application and scales with demand.

+5
Aug 20 '09 at 13:48
source share

Con: Not available in some countries (Argentina).

Edit

Available worldwide, but only through Google Groups for the App Engine.

+4
Aug 20 '09 at 13:54
source share

I believe that GAE has not yet reached maturity in terms of providing core functions for a serious business such as Datastore with a complex primary key, support for java.awt. *, these are just a few that I named.

Besides the free space and the creation of some Hobby sites, I strongly feel that GAE is NOT a place that java guys should watch.

I have applications created on JSP / Servlets and MySQL, thinking about porting to GAE, but I believe that I will spend more "time on cost" on migration than just buying space from some kind of java hosting, for example EATJ etc. (Sorry, but not marketing, just experience).

Another major issue with migrating my existing mySQL data to GAE, bulkupload is really pathetic and doesn't support clients.

There is no support for uploading a local Db database to the server.

As soon as the GAE is ready with the above mention of all the “minuses,” I will think that we can look at this migration.

+2
Feb 10 2018-11-11T00:
source share

Assessing the pros and cons, I think it is important to clarify the market in which it represents. Developers who are looking for a cost-effective solution to help them with the steepest part of their planned hockey stick growth curve will depend heavily on the disadvantages already mentioned. However, for a small business owner, GAE is a message from God. These people are most often looking for a “cloud” as a means of more efficient running their business (that is, they sell a physical product and services). For SMB, GAE, the pros that are already listed can be much more valuable compared to the hockey stick search engine, while the scales against are reduced by a fraction of the developers' indicators. I don’t see the GAE team doing anything related to SMB positioning, so I think answers like me just pull Superman’s cape and spit in the wind. In fact, GAE should now fully manage the SMB space. If not (I have no information about re: user base), then this is a very sad failure.

+2
Jan 10 '13 at 5:23
source share

Con: Your whole base belongs to us

... In a serious note:

Con: You do not control the environment in which your application runs. The same as outsourcing any component. Fun for toys, not for business (for now) IMHO.

Various things, such as the Google APIs for the proprietary backend, such as their database system and other “locks” and frameworks, which mean that your code is tied, in a free sense, may later cause problems with their system if you want to go with gae. Of course, you could distract them.

I like GAE, AppJet and others. They are cool. But everything has its place. If you need the freedom and ability to control your language modules, APIs, syntax versions / stdlib and much more ... do not give up managing your service provider.

The lack of standards for environments and specifications for what your application can expect is bothering me in the cloud arena.

common sense . In fact.

+1
Aug 20 '09 at 13:59
source share

You are a strong owner of a cell phone line, and your country + carrier should be able to receive international SMS messages.

(I hate cell phones, and my mom or colleagues will not receive SMS messages)

+1
Mar 27 '10 at 22:32
source share

Con: Nope. No other DBMS or NoSQL database is possible.

+1
Apr 11 '11 at 5:17
source share

Con: Limited to Java and Python

-3
Aug 20 '09 at 13:56
source share



All Articles