Re: What are the pros and cons of using Google App engine for my startup?

[Andrei Volgin]

Pros:

You don't need your own servers.

You don't need system admins.

You don't need database admins.

You don't worry about replication and backups.

Many useful built-in services (Users, Blobstore, etc.)

Appengine is free until your traffic picks up.

Seamless (almost) deployment of new versions.

Cons: None.

Some people believe that Appengine has certain shortcomings. Some services can be a bit pricey. None of this matters to you. If your startup becomes a huge success, you can always look at your Appengine bill and optimize parts of your service, or move some services (e.g. email, file storage) to other platforms. Appengine is the ideal platform for startups.

[Drake]

I have a video on the topic coming shortly.  Boils down to GAE is pretty much the only PAAS, and IAAS still requires an I Manager. So you save a head count out the get go.

 

Plus GAE is the most elastic of the Rapidly Elastic, so when CrunchMashSlashScobleForbesModo writes about you all on the same day you won’t be down.  And when you have crickets… You aren’t going broke.

 

From: google-a...@googlegroups.com [mailto:google-a...@googlegroups.com] On Behalf Of Levi Campbell
Sent: Friday, August 03, 2012 2:38 AM
To: google-a...@googlegroups.com
Subject: [google-appengine] What are the pros and cons of using Google App engine for my startup?

 

I'm building a startup, and I'm considering GAE as the platform, however I've been having a hard time finding information on why a startup might consider GAE instead of the many cloud providers out there. Let me explain what I'm working on.

 

I'm a big fan of David Allen's Getting Things Done: The Art of Stress-Free Productivity, and after trying several tools and online services that (claim to) implement the GTD methodology, I couldn't find anything that I loved, so I decided to build my own and make it available as a SaaS offering. This app will allow users to pull in their info_crap from email, facebook, twitter (and yes, I do have plans to add support for more social networks.), and RSS feeds and organize it by relationship to the sender (i.e. family, work colleague, vendor, and the like), project (i.e. planning a family vacation.), and context (Either the when or where something should happen.).\

 

Would GAE be a good fit for the application I'm developing? Why?

 

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/mncmD6uYBooJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Brandon Thomson]

>I'm building a startup, and I'm considering GAE as the platform, however
>I've been having a hard time finding information on why a startup might
>consider GAE instead of the many cloud providers out there. Let me explain
>what I'm working on.

GAE is really hard to beat for most startups. I think the only reason
I'd avoid it is if I had special needs which it doesn't support yet,
like SSD storage, low-latency communication to virtual machines, or
geographic distribution of application servers.

And if I felt like I needed one of those I'd try hard to reconsider
because GAE is such a pleasure to use and saves a lot of effort and
time.

Brandon

--
Brandon Thomson
b...@brandonthomson.com

[hyperflame]

It would be a good fit for most of those subjects, but keep in mind
that GAE cannot access email through IMAP or POP3 because it doesn't
support sockets, only standard url fetch. If you want to include email
in your service, you'll have to base a proxy somewhere else, such as
Rackspace, Heroku/AWS, etc.

On Aug 3, 4:37 am, Levi Campbell <levicc00...@gmail.com> wrote:
> I'm building a startup, and I'm considering GAE as the platform, however
> I've been having a hard time finding information on why a startup might
> consider GAE instead of the many cloud providers out there. Let me explain
> what I'm working on.
>

> I'm a big fan of David Allen's Getting Things Done: The Art of Stress-Free

> Productivity<http://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp...>,

[Rerngvit Yanggratoke]

As many people have stated about advantages of GAE for startup already, let me provide some disadvantages. The purpose of this is not to discourage people to use GAE but inform them about both sides of the story.

The first and most important issue is a vendor lock-in. GAE normally requires you to spend significant efforts to develop and optimize specifically for the platform to run your applications nicely and cost effectively. For example, it is recommended to use a platform-specific database layer like Objectify than the portable but heavy-weight one like JPA or JDO. Another example is that it is recommended to minimize the size of your applications to reduce the cold-start time. This also means that very useful but heavy-weight frameworks like Spring are not going to be comfortable with GAE unless you are willing to pay a steep price of "reserved instances". As a result, if one day you have to move your applications away from GAE to somewhere else, porting your applications is not going to be an easy task. You might have to spend significant resources for that. The possible reason for the movement might be that Google increases the price significantly such that your business model is not sustainable anymore. This happened before to many people. Have a look in the highly popular forum topic (https://groups.google.com/forum/?fromgroups#!topic/google-appengine/obfGjbIkOTI).  Now, some people might argue by bringing up Opensource alternative of GAE like Typhoonae (http://code.google.com/p/typhoonae/) or AppScale(http://code.google.com/p/appscale/). Despite the fact those are great and honorable attempts, neither of them are fully compatible with GAE. In other words, if your applications run smoothly on GAE, they might simply break apart on their platforms. 

The second issue is the development efforts and learning curve required. GAE is designed for highly scalable applications and require you as a programmer to think the same. It certainly requires a new mindset compared to a traditional web applications development. Generally speaking, everything you do should be able to implement in a fully distributed way. For instance, you should not use a relational database like Mysql because it is a major bottleneck in traditional web applications. (You actually can use it now with Google Cloud SQL. However, it deteriorates the purpose of running an application for GAE). 

The third issue is a sharing of fate. This is actually not just for GAE but for any other cloud solutions. You are going to run your applications on a shared infrastructure. You do not know what applications are run besides you in the same IP. They might be spam or malicious software developed by hackers. Then, the IP might be blocked for a security reason. An example of this is the recent CloudFlare blocking issue (https://groups.google.com/forum/#!msg/google-appengine/Q6yQ4d9ov-o/hAyrgn0xZQwJ).

All in all, the major thing to concern is picking the right tool for the right job. GAE is suitable if your applications require a very high scalability and you don't have or want to operate an operation team (System administrators). Other than that, I would recommend you to find other options. 

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Best Regards,
Rerngvit Yanggratoke 

[Drake]

If you have lockin you are doing it wrong.

Wrap your Google Specific API calls so that they function like the Heavy versions you can’t/shouldn’t use.

[Rerngvit Yanggratoke]

Hello Drake,

      That is possible but would increase your application size. Then, why not use JDO or JPA instead? It is the same lines of reason.

[Drake]

You likely don’t need “ALL” of JDO JPA’s functionality.

 

I have nothing against JDO/JPA if you don’t need the whole thing strip out what you don’t need. That is hard with the frame work…

 

But… If you have a

 

deletePersistent

 

equivalent in your code, name it that.

If you have a JDO/JPA function that is (Object,thing=array,target=None) for its use, and you have a very similar function in your make your code take the same arguments with the same name.

 

This is just good practice for making sure your code is readable.

 

 

Let’s say you want to do a store…

 

public void apply()

{

    Product newProduct = new Product();

    newProduct.setName(pname);

    newProduct.setPrice(Double.parseDouble(pprice));

    newProduct.setStock(Integer.parseInt(pstock));

    PersistenceManager manager = factory.getPersistenceManager();

    Transaction tx = null;

    tx = manager.currentTransaction();

    tx.begin();

    manager.makePersistent(newProduct);

    tx.commit();

    manager.close();

}

 

 

You can easily make your own class that includes makePersistent and Commit

makePersistent

        entity.setProperty(newProduct);

 

commit

        DatastoreService datastore = DatastoreServiceFactory

                .getDatastoreService();

        datastore.put(entity);

 

 

Bonus we could add to commit code so that it does a Datastore Put, AND writes the data to memcache

 

Even if you don’t replace the most complicated functions/classes you reduce your lockin.

 

Conversely, when you are doing rapid development and proof of concept coding

 

You can start with classes that are your own that wrap the JDO/JPA, and once you have the app working you can start stripping JDO out of those functions.

[Jeff Schnitzer]

There is plenty to complain about, but GAE is still a good choice.

The upsides:

* It really is "fire and forget"; all you do is deploy code. There's
no provisioning, capacity planning, etc. Just pay the bill.

* "Ops" is something people at Google do. You don't.

* Great big box of useful tools; memcache, task queues, blobstore,
image manipulation, etc.

* The High-Replication Datastore is a modern marvel.

There are definitely some downsides to GAE:

* It's expensive to operate. An "instance" is significantly more
expensive and capable of doing significantly less work than what other
platforms offer. Your bill starts at $100/mo just to use SSL (and
with all that private data you certainly are, right?). In the early
days you're going to spend more than you would elsewhere... and if you
have a lot of traffic, you're going to spend a *lot* more. This is of
course balanced against not paying for dbas and sysadmins.

* The concern about lock-in is totally warranted. If you build a
complex app on GAE, it's pretty much a total rewrite to go elsewhere.
The flip side is that you're "locked in" because there are all these
nice high-level services with great APIs that you would otherwise have
to invent and manage yourself.

* Historically, reliability has been spotty. It pains me to say this
but things break a lot and you will likely see downtime a lot more
than if you maintained more of the infrastructure yourself. GAE is a
complicated system that is being upgraded on a schedule that is opaque
to you, plus you're running on shared infrastructure with thousands of
neighbors who might not be very nice. And often there's not much you
can do but scream on this mailing list. On the plus side, when
something breaks, someone at Google fixes it - not you.

* The datastore, while amazing for most web apps, is very challenging
for some classes of problems. Two that come to mind are:
* Heavily transactional systems. XG transactions help but you
still have to go through major contortions to build banking-type
applications. RDBMSes are clear winners here.
* Rapidly mutating datasets. It can be very tricky to work around
the one-transaction-per-second-per-entity-group throughput limit,
which gets even slower in XG transactions. There are usually
solutions (eg sharding, queueing) but they are all huge PITAs that
complicate your business logic. GAE doesn't offer any kind of service
that fills the niche that Redis fills.

* There are some downright broken parts of GAE, but they aren't well
documented as such. The email service is useless; go with a
third-party provider instead. Backends are a disaster; don't use
them. This isn't a big deal as long as you know what to expect; keep
following this mailing list.

Unless you have a "hard problem" for GAE, I'd say go for it and make a
home here. The problem is that it's hard to know what a hard problem
is without already being very familiar with the platform. Truth be
told, after three years I still bump into surprises now and then...
but there's always some solution, even if it involves pushing a
service fragment out to another cloud provider. The OP's app sounds
like a good fit.

Jeff

[Drake]

If your Instance cost is too high it means you aren't using API's enough. A
well designed app is going to be close to 50% API, a superbly designed App
will be 85% API when you look at the logs and see ms=42 cpu_ms=2
api_cpu_ms=14 you know you are doing it right.

Again this means not using heavy frame works, but instead creating proper
datastore queries the right way, and optimizing your code for the platform.

Doing lots of optimizations does create lockin, but that is the trade off of
optimizing for "Instance cost" the same is true of AWS or OpenCloud
technologies. The more you Optimize the more you have lockin.

Reliability is not spotty unless you are building apps that take more than
35s per request. If you are doing that, your users already hate you and
won't be surprised when you are down.

Backend can save you a ton of money use them. Use them often.

One trans per entity per second is only an issue if you don't know how to
use shards and build a write buffer, (which you should have anyway for
managing contention). We are now handling 1 billion writes a day in an app.
In some cases logical entities are being updated 15 times per second. We are
having no trouble. We did end up building our own memcache-like server to
help with that, so to get to those numbers you need a backend.

It is not "All sunshine and unicorns" lack of naked domains, and Apps For
Domains weird rules are a pain in the ass.

[Jeff Schnitzer]

Geez, not again...

On Mon, Aug 6, 2012 at 2:41 AM, Drake <dra...@digerat.com> wrote:
> If your Instance cost is too high it means you aren't using API's enough. A
> well designed app is going to be close to 50% API, a superbly designed App
> will be 85% API when you look at the logs and see ms=42 cpu_ms=2
> api_cpu_ms=14 you know you are doing it right.

Once more you are generalizing from an extremely limited problem
domain. There are myriad applications that consume CPU resources -
and if you're on Python, the raw cost of serialization is a
significant CPU hog.

It's utter nonsense that all requests can be shrunk to ms=42 cpu_ms=2.
For your app sure, I can buy that. Not most apps, not by a longshot.

> Again this means not using heavy frame works, but instead creating proper
> datastore queries the right way, and optimizing your code for the platform.

I'm not going to waste my time with this again.

> Doing lots of optimizations does create lockin, but that is the trade off of
> optimizing for "Instance cost" the same is true of AWS or OpenCloud
> technologies. The more you Optimize the more you have lockin.

Sure... I think the bigger issue is that the more you build
abstraction layers, the more work you have to do. And then migrating
to another service means re-implementing those abstractions, which may
be prohibitively expensive.

Personally I think "lock-in" is a poor argument against GAE. The #1
most important thing building a startup is getting features to market
as fast as possible. Engineering for portability is contrary to this
goal. But it's true that once you build an app on GAE, it probably
isn't going anywhere.

> Reliability is not spotty unless you are building apps that take more than
> 35s per request. If you are doing that, your users already hate you and
> won't be surprised when you are down.

Even a casual perusal of the history of this mailing list will show
this is not true.

> Backend can save you a ton of money use them. Use them often.

I'm not so foolish to generalize to every single problem domain, but
all the "obvious" uses of backends have not panned out. Maybe,
*maybe* you have come up with a great use case for backends. But for
every other one I've come across, they are horrible:

* They're terrible for in-memory indexing because they're 10X too
expensive for RAM.
* They're terrible for realtime gamestate because they can't support
enough throughput.

The one real-world use case that backends seem to be good for is to
work around the 60s/10m deadline of frontends. That isn't very
compelling.

> One trans per entity per second is only an issue if you don't know how to
> use shards and build a write buffer, (which you should have anyway for
> managing contention). We are now handling 1 billion writes a day in an app.
> In some cases logical entities are being updated 15 times per second. We are
> having no trouble. We did end up building our own memcache-like server to
> help with that, so to get to those numbers you need a backend.

15 updates per second is a trickle. There are lot of transactional
problems that are very hard to solve on GAE, and "sharding" alone is
not an answer. As a real-world example from my application, there's
"the burning man problem": You have 50k items to sell, they go on
sale at a specific time and sell out in 15 minutes. You must sell
exactly 50,000 - not 50,001.

Granted, this is a challenging problem to scale with an RDBMS (which
is why the burning man ticket system crashes every year), but at least
the code is simple. I have a pretty good solution to the problem but
it's definitely complicated.

Jeff

[Drake]

To make AppEngine work for you. You have to say "I WANT TO BE GOOGLE". You
have to say "I WANT TO BUILD LEGO BLOCKS" you have to say "200MS is TOO
FRAKKING SLOW"

> Once more you are generalizing from an extremely limited problem domain.

You mean my natural language processor that has to compute the parts of
speech for every word in a document?
Or maybe my Image tool that auto-crops images so that they fit in a given
aspect ratio?
Or my content classifier that puts content in to classifications based on
the context and word usage?
Or my GEO tool that converts your IP Address to a metro, and generates best
version of ads for local targeting?
Or my SEO tool that scores a body of content against rules Google uses to
rank content?
Maybe you were talking about my widget tool that does Content relatedness
for suggesting other articles on the same topic?

> There are myriad applications that consume CPU resources - and if you're
on
> Python, the raw cost of serialization is a significant CPU hog.

Serialize in the background.
API your most CPU intensive stuff to backends. Use light weight front ends
to handle the bulk of your requests. Use F4's and F8s when you need bursts
of CPU power.

F1's suck at "dense" code that has lots of CPU constrained tasks. But F4's
suck "Sparse" code that doesn't have enough CPU.
To get the best of both worlds you need to have a mixture.

This takes getting used to. Most people haven't written for large
multi-server environments, and that is what you are really building with
Appengine.
You are building lots of microapps designed to be super efficient at the
thing they do, so that that thing fits nicely in 128M of Ram, and is
performant on a 600Mhz CPU

You can do this in 1 of two ways, you can shard your code so that frontend
instances spin up one way and explode when they get their 85th request and
your behemoth app crashes....

Or you can design for "endpoints" , "APIs" or what ever you want to call it,
where specialized instances do their thing. In some cases this means using
the "Versions" so that you can have ThingIDoRarely.Myapp.appsot.com and
ThingMyAccountantDoes.MyApp.Appspot.com

To make AppEngine work for you. You have to say "I WANT TO BE GOOGLE". You
have to say "I WANT TO BUILD LEGO BLOCKS" you have to say "200MS is TOO
FRAKKING SLOW"

Want me to solve 50k Transactions in 1 second?
If transaction rate is < X use default
if Transaction rate is > X & < Y Use Shard
if Transaction Rate is > Y use backend

And your backend uses in instance memory, and defers to populate a
persistent record. When the transaction rate drops below a threshold you do
commits and re-merge with master.

[Jeff Schnitzer]

On Mon, Aug 6, 2012 at 11:15 AM, Drake <dra...@digerat.com> wrote:
>
> Want me to solve 50k Transactions in 1 second?
> If transaction rate is < X use default
> if Transaction rate is > X & < Y Use Shard
> if Transaction Rate is > Y use backend
>
> And your backend uses in instance memory, and defers to populate a
> persistent record. When the transaction rate drops below a threshold you do
> commits and re-merge with master.

The specific requirement is selling 50,000 tickets but not 50,001
tickets. It's not as simple as just sharding because you can't
transactionally aggregate shards to get an accurate count.

Solutions which involve deferring writes in memory risk losing data
if/when a backend crashes.

It's certainly not impossible; I've done it (although my solution
certainly will not hold up to 50k in one second - fortunately an
unrealistic scenario for me). I'm saying it's complicated and a
preposterous amount of work compared to the RDBMS-backed-by-SSD
solution. There's a "right tool for the right job" and it's worth
considering the application domain carefully before blindly shouting
"yes, appengine is great for everything!" I've recommended appengine
for some clients and steered others away because it wasn't a good fit.
A third subset of apps are best run as a hybrid with parts in other
cloud systems.

Jeff

[Jeff Schnitzer]

On Mon, Aug 6, 2012 at 11:15 AM, Drake <dra...@digerat.com> wrote:

> To make AppEngine work for you. You have to say "I WANT TO BE GOOGLE". You
> have to say "I WANT TO BUILD LEGO BLOCKS" you have to say "200MS is TOO
> FRAKKING SLOW"

If this really were true (and fortunately it is not), then GAE would
be a failure. If every GAE application had to be decomposed and
reassembled with fine-grained micro-optimizations, it would take 10X
the time to develop on GAE than on any other cloud platform. It would
destroy the value proposition.

Fortunately this is not the case. For many problem domains, GAE is
the "faster and easier" development platform. But there are grey
areas and it's important to know the boundaries.

>> Once more you are generalizing from an extremely limited problem domain.
>
> You mean my natural language processor that has to compute the parts of
> speech for every word in a document?
> Or maybe my Image tool that auto-crops images so that they fit in a given
> aspect ratio?
> Or my content classifier that puts content in to classifications based on
> the context and word usage?
> Or my GEO tool that converts your IP Address to a metro, and generates best
> version of ads for local targeting?
> Or my SEO tool that scores a body of content against rules Google uses to
> rank content?
> Maybe you were talking about my widget tool that does Content relatedness
> for suggesting other articles on the same topic?

Actually, yes, I mean exactly this. What's missing from this list
something representative of the "typical business app": lots of
transactional logic woven through complicated business rules. The
core element of your optimization strategy - breaking down an app into
separately-deployed components - is antithetical to transactions,
which are the bread-and-butter of 90% of business processing.

Jeff

[Steve James]

Excuse my butting in guys... v interesting debate.... I tend to veer towards the "pro" app engine side of the argument myself.

However, IMHO, the idea of implementing a decent SOA with different "subprojects" running on different instance environments is one of my own personal gripes. I can't quite agree that the use of "versions" is an adequate solution to the problem. If only Google allowed the Datastore to be shared across different applications then we'd be cooking with gas (I'd say the same for blob store, but cloud storage looks like its stealing it's crown there anyway).

There's an issue raised for it which could benefit from a couple more stars if you agree :-)

http://code.google.com/p/googleappengine/issues/detail?id=1300&can=5&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log

[Levi Campbell]

On Monday, August 6, 2012 2:46:45 AM UTC-6, Jeff Schnitzer wrote:

There is plenty to complain about, but GAE is still a good choice.

The upsides:

 * It really is "fire and forget"; all you do is deploy code.  There's
no provisioning, capacity planning, etc.  Just pay the bill.

 * "Ops" is something people at Google do.  You don't.

 * Great big box of useful tools; memcache, task queues, blobstore,
image manipulation, etc.

 * The High-Replication Datastore is a modern marvel.

There are definitely some downsides to GAE:

 * It's expensive to operate.  An "instance" is significantly more
expensive and capable of doing significantly less work than what other
platforms offer.  Your bill starts at $100/mo just to use SSL (and
with all that private data you certainly are, right?).  In the early
days you're going to spend more than you would elsewhere... and if you
have a lot of traffic, you're going to spend a *lot* more.  This is of
course balanced against not paying for dbas and sysadmins.

I'd love to see a pricing calculator that lets potential customers get a rough estimate of monthly costs, (To be honest though, I'm kinda surprised there isn't one already.)

 * The concern about lock-in is totally warranted.  If you build a
complex app on GAE, it's pretty much a total rewrite to go elsewhere.
The flip side is that you're "locked in" because there are all these
nice high-level services with great APIs that you would otherwise have
to invent and manage yourself.

 You're going to have vendor lock-in of some form or another what cloud provider you choose, I'm not sure what the issue is here.

 * Historically, reliability has been spotty.  It pains me to say this
but things break a lot and you will likely see downtime a lot more
than if you maintained more of the infrastructure yourself.  GAE is a
complicated system that is being upgraded on a schedule that is opaque
to you, plus you're running on shared infrastructure with thousands of
neighbors who might not be very nice.  And often there's not much you
can do but scream on this mailing list.  On the plus side, when
something breaks, someone at Google fixes it - not you.

 Are there any examples you can point to?

 * The datastore, while amazing for most web apps, is very challenging
for some classes of problems.  Two that come to mind are:
   * Heavily transactional systems.  XG transactions help but you
still have to go through major contortions to build banking-type
applications.  RDBMSes are clear winners here.
   * Rapidly mutating datasets.  It can be very tricky to work around
the one-transaction-per-second-per-entity-group throughput limit,
which gets even slower in XG transactions.  There are usually
solutions (eg sharding, queueing) but they are all huge PITAs that
complicate your business logic.  GAE doesn't offer any kind of service
that fills the niche that Redis fills.

I need to read more about how the datastore works.  

[Kaan Soral]

Another Pro: Great Community (People who use Appengine, people who build Appengine)
Another Con: There are minutely limits on services like UrlFetch that limit your scalability https://developers.google.com/appengine/docs/quotas#UrlFetch

[André Pankraz]

Hi,

I have read many pros...some quite extensive and without any Con at all. I like the app engine idea, but really, that is a bit one-sided.

Huge pros: Architecture with scalability in mind, dynamic scaling / pricing, easy to setup, lots of nice services like mail, messaging etc., HA/backup Other people have already shown them.

Huge cons (for me):

• Really expensive...what benefit has (theoretically) endless scalability if i'm instant bankrupt with a DoS. AWS continuously lowers prices, GAE not so much. If I restrict quota to reasonable financial amounts I'm often not better than 2 or 4 high end root servers. I need _dozens_ of GAE instances to match the speed of 2-4 dedicated good servers, don't know why. The database operations are also expensive.
  
• Severe restrictions on useable proven frameworks, developing for GAE is very time consuming and expensive because of this and because I have to optimize a lot. Many peope claim how expensive this admin is that I don't need anymore with GAE, but I don't believe this story. You need multiple times more money to develop for GAE than for this admin guy. In a startup you can also setup your system by yourselfes, really some guys here are talking like setting up a clustered tomcat/jboss with network/monitoring stuff and a database is rocket since...with todeys tools it's not - and I'm free to choose between something like PostgreSQL and Neo4j, Cassdandra or whatever.
• Unstable platform and bugs in services. You are fully dependant of Google with this. If they decide to update to e.g. JRE 7 than you can use JRE 7 Bytecode, not before. If they decide to update to JRE 7 than you must use it...this may introduce incompatibility issues with your untouched deployments. Same for services. Services have bugs, e.g. upload of empty Blobs created empty BlobInfo, no Messages from Backends to User, Appstats for Backends doesn't work in development, no Blobinfo Hashvalue was created for development mode etc. - all this costs much time and you cannot fix this or use another library without much effort.

There are more Pros and Cons, was my list,

Yes Brandon, I do it all wrong, TIA.

Regards,
André

[Tomas]

My two cents (as a Java dev):

Pros:

- it's not complicated, you can do easy things in easy way (well maybe the Database can be tricky when you come from SQL world :-)
- very easy and fast start of development (if you use simple stack as servlet + jsp + objectify)
- for small projects its basically free
- very easy deployment
- very easy use of messaging as all is basically just async http request
- it scales automatically
- you don't need admin for db/app server and other stuff

Cons:

- you can't use usual frameworks aka Spring -> which means you spent a lot of time implementing basic features which are included in your framework (ie. Authentication, MVC, templating, Caching and so on) - I mean you can probably work it around and use some subset of frameworks or libraries but my experience tells me you will keep trying to find some hacks and workarounds instead focusing on real development and adding features (For example with spring you add @Cacheable annotations to method which will automatically use in-memory cache + propagate to memcache through ehcache (yes one line settings) - on GAE you will need to write it by yourself)
- you don't have control over resources - when GAE a has bad day you can't do anything with it and you can just watch how it spins instances or fails when talk to db - and you usually don't get a word from google what is actually happening
- it doesnt fit all type of projects - for example in my app I have a web front and then a backend business which was processing multi-threaded requests while was user browsing pages - the backend was done through tasks and it was killing the instance so I had to move that logic to AWS where it runs on micro instance with 0.1 load all the time very nicely (this was before google announced backends) - my frontend client facing app still runs on GAE and I haven't touched it for more than year and didn't have much issues even if its sits in MS datastore :)
- it can be expensive (you need to optimize sooner) - I was usually optimizing after getting more hits and so but on GAE you sometime needs to optimize in advance because it just consumes a lot of resources (ie. reads/writes/indexes to db)
- something is just not going to work at all and you will need to find alternative (ie. reading from local drive etc)

On Friday, 3 August 2012 21:37:36 UTC+12, Levi Campbell wrote:

I'm building a startup, and I'm considering GAE as the platform, however I've been having a hard time finding information on why a startup might consider GAE instead of the many cloud providers out there. Let me explain what I'm working on.

I'm a big fan of David Allen's Getting Things Done: The Art of Stress-Free Productivity, and after trying several tools and online services that (claim to) implement the GTD methodology, I couldn't find anything that I loved, so I decided to build my own and make it available as a SaaS offering. This app will allow users to pull in their info_crap from email, facebook, twitter (and yes, I do have plans to add support for more social networks.), and RSS feeds and organize it by relationship to the sender (i.e. family, work colleague, vendor, and the like), project (i.e. planning a family vacation.), and context (Either the when or where something should happen.).\

[Mos]

Perfect summary. I totally agree to everything. (Be careful about
statements of Drake; he is trolling around)

On Mon, Aug 6, 2012 at 10:46 AM, Jeff Schnitzer <je...@infohazard.org> wrote:

...

> There is plenty to complain about, but GAE is still a good choice.

[alex]

Our experience on py 2.5, 2.7 and Go is a lot different from Java guys.

Pros:
- being able to use Task queues (+ deferred API) and Cron jobs in form of async HTTP requests is just awesome.
- I haven't seen anything like Guido's NDB for what concerns async and "parallel" execution, plus its caching, autobatching even on url fetches
- LOTs of useful services, which you use via simple APIs
- you totally focus on your app code and not hardware/systems admin. What others call AE limitations actually often helps you deliver a better experience to your users. Not always but again, in our experience, most of the cases. I actually want to thank AE team for imposing some limits (though the real reasons of limitations are totally different)
- when something goes wrong you just wait for SRE team to fix it
- nice support for (unit) testing out of the box. Both Go and Python. Actually Java too.
- Backends are actually of a great value when you need to "talk to" third parties via some API (i.e. not user-facing requests)

Cons:
- some of the services are still a little buggy and their bugfixing is not that fast in some cases (e.g. Channels API 400 errors)
- Users API is awesome but unfortunately works with either Google Accounts or OpenID. Either way, I'd love to see it supporting OAuth 2.0 and/or "abstract" third parties
- I'd love to see a better monitoring system, though I do understand this is a complex system to say the least. plus, I think someone mentioned.
- Examples are too simple, e.g. Hello World. So, you'll need to actually figure it out yourself. This is not the case with Go land - their examples are closer to real world.

Overall we're more than happy with AE. It saved us tons of money so far.

-- alex

PS can't wait for Endpoints API and Compute Engine GA. Unfortunately I didn't get into trusted testers (was hoping for Endpoints API)

[Alexis]

@Kaan: The limits can be increased as your app grows as long as you make a decent use of the resources. The GAE team will make sure your app is able to scale and assist you if you become that big (as you will have a Premier Account in this case). For instance, some of our apps have the following limits: URL Fetch 834,159,222 calls daily, 576,000 calls per minute.