Snapchat

[Kaan Soral]

I was surprised when I learned that Snapchat was built on App Engine http://mashable.com/2014/01/12/stages-of-snapchat-comic/

I've also been investing a lot on App Engine for years, it's reassuring to see others do too

What do you guys think?

[alex]

Why were you surprised?

[Eric Ng Ka Ka]

What surprise you? Many better services are on GAE. What so special for snapchat? (Technical points of view)

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[Kaan Soral]

Surprise reasons:
The media didn't mention it during the valuation news, or at least I didn't catch it, it was interesting to learn it from a comic
It's interesting to see different uses of appengine, since appengine is limited on some aspects
It's good to see others invest a lot in appengine too, makes a relatively insane decision more sane

What other major services are there on GAE, in terms of technical impressiveness and scale/hype? (Rovio seems to be one, I missed it too, but the type of games they make doesn't seem to require too complicated backends)
https://cloud.google.com/customers/

[coto]

We all should be surprised, because Google App Engine is very expensive!!

On Sunday, January 19, 2014 5:23:13 AM UTC-3, alex wrote:

Why were you surprised?

[Rafael]

that's may be the reason why their product is so simple and elegant. 

it was probably extremely hard for a new grad to make something more complex with appengine? :)

--

[Jim]

I've seen many variations of this statement, "Google App Engine is expensive!", and it always strikes me as a bit off.  I supppose it depends on your perspective and your requirements.

For the past three years I've been running a small start-up building a SaaS analytics application.  For the prior 25 years or so I built enterprise apps for some well-known software houses.  The last 12 years I was building SaaS-based software products serving top-tier global financial institutions.  During that time I worked on projects where we built, from the ground up, 2 different web-based solutions which wound up serving tens-of-thousands of end-users and very large volumes of system-to-system (B2B type) transaction volumes.

When we created our infrastructure for these systems we needed multiple geographically dispersed data centers, high levels of fault-tolerance within any given data center, n-tier architecture, secure systems, scalable databases and front-end servers, system, security and network monitoring and administration, etc.  When you spec that all out from scratch, you will have a hard time doing it for less than several hundred thousand dollars capex with big ongoing opex expense.  Any growth beyond your initial headroom will require additional capex expenditure and incremental ongoing opex.

Depending on the profile of your application and the system load, at some point you will pass the threshold of it being cheaper to build and maintain your own equivalent infrastructure, but that threshold is very, very high.  So it makes me think people who say GAE is 'expensive' are not making a comparison such as this.  Maybe they don't really need everything that GAE offers.

Or perhaps they are comparing GAE to other cloud offerings such as AWS?  Amazon's pricing doesn't seem to be radically different than Google's to me, for similar services.  And given that Amazon's PaaS solution is not yet as complete at GAE, I think that any complete appliation built on AWS is going to require some level of system-engineering.  System engineers are not cheap. One of the things we like about GAE is that, at this point in our corporate evolution, we can focus entirely on our Customers and our Software and not spend money or time configuring hardware, OS and other "low level" stuff that we (as application software guys) don't want to mess with.  There are very real hard and soft monetary benefits to this. 

Or maybe when people say "expensive" they mean as compared to other "cloud" offerings that are more along the lines of rented physical or virtual machines.  Yes, some of these can be cheap compared to GAE.  But these are really apples-to-oranges comparisons when you consider all the things you need to provision a global, "utility-grade" (aspirationally, anyway) SaaS offering.  

So I guess this post is a long-winded way of me saying "GAE Expensive?  Really?  What exactly do you mean by that?  Compared to what?"

[timh]

I agree with Jim here.  I have been developing applications and delivering solutions on appengine since 2008.   And for everything project I have been involved with 

appengine has been anything but expensive.  When you factor in what the real cost operating system/stack  support, etc, on AWS or... additional scaling on Heroku, or full stack availability 

on your own hardware, then it seems very inexpensive.

I am sure the are specific use cases where appengine is really expensive, but then maybe that application is not appengines sweet spot.

Just my 2c worth

T

[Rafael]

Guys, 

Please, we're not in 1970 anymore. There is no argue that appengine is the most expensive hosting on earth and possibly the universe.

My company spend $4000 a month with appengine. We could host the same service with $50 in a more powerful environment:

http://www.hetzner.de/en/hosting/produktmatrix/rootserver-produktmatrix-ex

With $300 we could make it redundant and more reliable and faster than appengine. 

A dedicated server is also more reliable, because of appengine infamous "hicupps" due to its scheduling system and instance boot time. 

In one of my services I rent a rack with 20 spaces and it's filled with only 10 severs. It means I can scale my servers with 10 more. That configuration costs $1000. 

Please, pay attention for 10 dedicated quad-core with 32GB of ram. How much would you pay in appengine for that type of throughput? I did the calculations: $60k. 

Please, it's incomparable price wise. There's no argue and let's not go there :)

thanks

rafa

--

[alex]

Totally agree with Jim and Tim.
But, I think it's a waste of time trying to reason with guys like
Rafael and coto.

They keep forgetting the cost of software and hardware maintainance,
monitoring, load balancing, scaling, intrastructure stack,
reliability, etc, no matter how many times you try to explain it.
Sometimes, I wonder why they keep using App Engine. Maybe it's just
because their companies actually did proper ROI/TCO calculations.

> You received this message because you are subscribed to a topic in the

> Google Groups "Google App Engine" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Rafael]

alex, 

I keep using appengine because my service is too big for a migration. I'm the founder of the company. 

We chose appengine when it launched. At the time the costs we more than 3 times less. They changed the price and our service was already built, so we've got locked in. 

Do the calculations. I would rather hire a $300k/year engineer that can scale the service with $5k a month, rather than hiring a $120k that would scale at $60k month. 

Again, we're not in the 70's anymore. It's not that difficult to do what you're describing. 

I'm not arguing. This is not a discussion. Nobody can argue that appengine is a good choice costs wise. 

There are plenty of wonderful things about appengine, but cost is certainly not one of them, so please stop fake-ing :)

bye

rafa

[timh]

Honestly, every one will have different experiences, to make blanket statements about how it is expensive just doesn't fly.

I can argue and with figures to back my statement up.  Maybe you application doesn't suit the appengine model.

I have a system with around 2000 daily users (they must use the system for certification, so it is compulsory for 3-5 years. Numbers will be twice that within 6 months). This system went live in July 2010.

It costs only $2-$3 a day, we generally don't have problems with 'hiccoughs' and the amount we save in not having to manage any infrastructure at all

is worth a great deal more than $2 a day.

Ultimately it's horses for courses.  Maybe you picked the wrong platform for you application, maybe you made bad architectural choices, but to suggest 

you experience holds for all other use cases is quite ridiculous.

T

[Rafael]

Hi timh,

Please, read the title of this thread. The use case is clear: snapchat

If my bill is quite expensive with a couple million uniques a month, imagine theirs with a couple hundred million? 

Best,

Rafa

[timh]

Yes the thread title might say that,  but you keep saying it is too expensive in all cases.. without any qualification.  Other than it costs you a lot to do what you do.

T

[Rafael Sanches]

timh,

you pay $60 a month for running a service for 2000 daily users. 

that's quite expensive don't you think?

you're the one telling i'm ridiculous, when the only thing I am saying is that no one can argue that appengine is a good choice when it comes to costs.

best,

rafa

[timh]

On Tuesday, January 21, 2014 5:21:43 PM UTC+8, Rafael Sanches wrote:

timh,

you pay $60 a month for running a service for 2000 daily users. 

Yes.  it really is very cost effective.  No full stack, no OS to worry about.  etc.....

I said it was ridiculous to suggest it is too expensive for everyone without qualification, which is what you are saying.

Scaling on other services takes more effort, than appengine.

 

that's quite expensive don't you think?

 

Not at all.  If I had to factor in all the support people, that would be required and the effort to keep OS, dbms, apache etc... up to date, patched etc.... that alone would be more expensive than the hosting by a considerable margin.  For many business the cost factor of the hosting is not the concern, the support cost is.

you're the one telling i'm ridiculous, when the only thing I am saying is that no one can argue that appengine is a good choice when it comes to costs.

I will restate - to suggest that it is too expensive for everyone without qualification is ridiculous.  I accept it is too expensive for you., and maybe snapchat - who knows !

But for all of the projects I have been involved with appengine has been worth every penny/$

I am not trying to defend appengine as a fan boy.  It just makes sense as a PAAS for me and I for one have no time to manage even IAAS based systems.

Let alone my own hardware

T

[Kaan Soral]

I agree that it's apples and oranges in comparison
I'm also using hetzner for a side project, One fair warning, years ago I was using serverloft, another german company, and one of the relatively good ones, servers used to fail (expected once in a while) but the worst thing was that, they used to hibernate the servers for extremely small reasons, once a small time lawyer sent a notice to serverloft indicating a copyrighted image of theirs was on my server and they hibernated the server costing me 100$'s
I also tested their cloud offering when they first launched it, their pricing was buggy, they wanted me to pay the excessive costs that arose from their mistakes and disabled my account when I refused (I had 2-3 servers with them for years before this happened)

Same thing happened on Appengine, one of my old apps accumulated 600$+ or something, If I'm not mistaken, the payment was enabled but the app was an unused old M/S version, and appengine just dismissed the charges

Although products are not really comparable, I like the Amazon's minimal pricing strategy, reducing prices instead of increasing them, good guy Amazon, offtopic

I think we might see something similar from Appengine soon, things have been always improving with Appengine with the one exception (the pricing change, years ago)
Compute Engine seems to be able to access Appengine services, db etc. I think there might come a point where running a service similar to Appengine on Compute Engine would be easy and cheaper, at that point we might see a decrease in prices

I've been using Appengine on a relatively large scale, income > costs although friction in my service is really high, sometimes low-friction parts of my service gets a high traffic, although income increases, the costs stay the same, I have a feeling that simple, low-processing/db apps might see incomparably low costs compared to incomes

With a new app I've been paying 6-7$ a day for almost no traffic and although I pay high for low delays, I've been seeing failed requests when I access the app when It's cold, it's not the initial request that's failing, but the initial ajax requests, which might be triggering new instances
I've always seen people complain about this issue, now I see why

At large scale things seem to work better, but if the app is not monetized, running a high traffic app, or aiming high with an app comes with it's paranoid thoughts.
There is a chance that a built-app might become popular and costs might drive the owner bankrupt, it's one of my feared worst case scenarios lately

I wonder how much Snapchat or other relatively high traffic services pay, as Rafael pointed out, since their product is seemingly simple, the costs might be surprisingly low too

[timh]

Just for the record, the app I was talking about might only have 2000 users, but it is by no means a simple application.

I has approximateley 30 different models.  Fully defined with RBAC security model scoped down to parts of models.   

reporting, audit trail records for every change to data, (when and what was changed, by who), etc....  

The entire system is modeled in UML, python models, views, URL paths, security declarations, form schemas all directly generated from the model.

What elements of a view appear for the combination of user, context, and view control page layout, so the application is intensely dynamic and most cached data's scope is only effective for a single user.

So even complex applications can be run in a cost effective manner on appengine.

But no point trying to stick a square peg in a round whole.  If you data model, or processing requirements don't suit appengine and you can't start instances quickly then 

you may well be on the wrong platform.

Now more than my 2c worth ;-)

T

[Pertti Kellomäki]

On Tue, Jan 21, 2014 at 11:21 AM, Rafael Sanches <ra...@allthecooks.com> wrote:
> you pay $60 a month for running a service for 2000 daily users.
> that's quite expensive don't you think?

Even for my one man and his dog shop, $60 per month would be a trivial
expense. If I'd put any reasonable price tag on my time, the cost of
reading this list would probably be close to that per month.
--
Pertti

[Rafael]

Again, I love appengine and I love what google engineers are doing with it. 

They are amazingly skilled people and are improving the platform as fast as they can. 

The only thing you can't tell me is that it's a good deal pricing wise. 

The pricing is just disturbing if you want to do something at scale. 

Our company was bootstrapping for two years and we were forced to raise capital in order to pay appengine bills. 

Of course we could flood our users with ads, but that's not what we are passionate about.

--

timh, 

People like me have started with appengine because the requirements and pricing was right at the time. 

As you might know, requirements and pricing changes through time and server migration can kill companies. 

Kaan, 

My service is the typical >1mm subscribers social network. 

The $$ is spent mostly in read and writes and output bandwidth. 

It's definitely more expensive and complex than snapchat. 

Immediate hacks snapchat must to do in order to stay below $100k a month in server costs: 

- keep a pool of at least 20 "resident" instances. (they become SO idle that become zombines and never respond anymore, but you're paying expensively for it)

- move the output bandwidth to a cheaper CDN. moving my image serving to maxcdn has reduced my output bandwidth costs from $2000 a month to $300. 

- Snapchat probably doesn't need this, but twitter/facebook would definitively need: separate the push notification service in other module and then keep a pool of at least 10 resident instances again. this would be necessary to reduce spike effect (instances booting like crazy) with the britney spears tweets. 

thanks

rafa

--

[Jim]

1970's?  What on earth about my post made you think of the 1970's?   My description of geographically redundant, web based applications?  Please indeed.

The link you provided is for a LAMP hosting service... basically what I described in my third scenario about.  That's apples-vs-oranges as compared to GAE.  

I suggest you consult with the Application Architects where you work and politely ask them to describe the differences to you.  Clearly nobody here is getting through to you and I don't have the time or the inclination.

[Kaan Soral]

I think he gets it much more than you give him credit for

Hetzner example, as I interpret it, and think about it myself, is about the price of computing/ram/bandwith, although it's not comparable 1:1, it's important to know how cheap computing and hosting has become over the years, especially in this last 5-10 years

It was really interesting to hear about your story Rafael, it was the approximate reason why I started this discussion, to learn and speculate about major services

The 2000$ to 300$ cdn comparison is interesting, however no other service that I know of matches the extreme capabilities of google images service
I use the =s/-c resizing/cropping extensively, that's why I could never easily replace appengine, or the cdn

You seem to have lived my worst case scenario, going out of money and having to ask others for money.

Anyway if you don't mind it would be great to learn more about your product/story, but I'm guessing it's better to keep things as private as possible :)

[Coto Augosto C.]

I only have to say that my company has spent ~$1300 monthly. 

3 weeks ago we had high latency for 2 days, the only way to receive assistance was paying $400 for premium support, and the answer of Google's Support Team was: "Thanks, we just fixed the issue, it was in our end".

Basically, we are now are paying ~$1300 per month for servers, and additionally, $400 for notifying Google they have issues with their services. ("common sense says they have to pay us for this")

- Rodrigo Augosto (@coto)

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

[Rafael]

Jim, 

In 2014 a good engineer can create your own cloud infrastructure with 10 machines like the ones I suggested.

Again, I am not saying that I don't like appengine. In fact, I love it and that's why I stick with it. 

I am saying it's over priced to run a service like Snapchat. I don't think there's any argument there. 

Kaan,

This is my gift to you: https://gist.github.com/mufumbo/8547036

It extends all of the appengine image features: "=s/-c" and includes the most useful one: "=h"

Depending on appengine's image serving is a limitation, since "vertical cropping" is extremely useful on many elegant websites. 

For example, play around with: http://c1.picmix.net/61757192=s682=h300 or http://c1.picmix.net/61757192=s300=h600

By the way, another way to reduce server costs is to pay the $400 or $200 a month in support. 

That way you get access to discounted instance hours. It decreased our bill a bit and give access to a place to get feedback when appengine is having problems or when you need to tweak your scheduling and performance parameters that you don't have access from XML config.

About three months ago I spent a whole month optimizing my servers to reduce the costs from $10k to $5k. Even now, I feel it's too overpriced for the performance it's delivering.

thanks

rafa

[Kaan Soral]

Thanks :)
Very impressive and inspiring, I've never considered rectangle cropping up to this point, although I have ancient routines to find the right =s value for width/height/retina etc

[Jim]

Yes, I'm quite aware of the various cloud stacks out there and have worked on projects using several of them including AWS and CloudStack.  Glad to see you're moving away from your $50 a month claim and it's now at 10 X $50 a month.  Now let's talk about geographically dispersed services with automated fail-over.  Then let's talk about what that good engineer you have costs you.  You really want to run your business on a platform with a single engineer behind it?  Does he/she get to sleep or go on vacation?  What happens when he/she quits?  You sure that cheap little hosting provider has the network bandwidth and resiliency you are going to need?  Now triple your infrastructure to be able to handle the hoped-for huge spike in volume.  Now crunch the numbers again and tell me what the savings really is.  It ain't anywhere close to $3,950 a month, that I am sure of.

[Nick]

This got heated pretty quickly...

Regarding costing, it is very clear to me that PaaS, and particularly GAE are extremely cost effective as long as:

You can easily achieve your business goals,

They save you operational FTE

I think if you step outside of these bounds, then its time to migrate to something where you take more control and responsibility. The cost of doing so is obviously not free, the custom apis do cause vendor locking to an extent. 

I also think its very easy to underestimate the cost of an engineer (or team of) who can maintain a VM image, apache/nginx, load balancing, memcache, a performant search index, scale a SQL or NoSQL database, sync to a CDN and make it all elastic so you pay minimum server costs. None of that is particularly hard, but if you're at the scale where doing it on a PaaS is not cost effective, you probably need to do this well, or it'll just cost you more on every axis.

But at some point, if you need to make this leap, you need to do it.

My experience is that very few applications actually need to do this ever.

[Rafael]

Jim,

It seems you're talking from a point of view of a big corporation. Since snapchat didn't had big funding since short time ago, I was supposed we're talking about startups. Big corporations are another beast where server costs are irrelevant in it's sea of other useless costs and lazy people.

I am talking from the point of view of a startup that struggles with cash flow and find itself obligated to raise capital just to pay server costs. 

I don't know why some people think I am insulting their family when I say that appengine is very expensive for high traffic apps. Can you give me an example where it's not expensive? I am giving my own because I've built high traffic services for appengine, aws, hetzner, rackspace etc. 

Is geographically dispersed services an essential feature for a startup? It's simple till you complicate it. 

thanks

rafa

[Alexandre Cassimiro Andreani]

I would like to see Snapchat numbers.

[Jim]

Rafa,

You are correct that I have a lot of large corporate experience, working for good sized commercial software houses.  That's where I had the pleasure of building these sorts of highly available, scalable, secure, etc platforms from the ground up to host products my teams built.  That's why I know how hard, time consuming and expensive it can be to build something that begins to approach what GAE offers.

But I have also worked in two start-ups.  One early in my career and now for the past three years running my own.  We're using GAE now and I would not consider it 'expensive' because we do want and need the things that it offers.  I don't want to build on generic LAMP stack and be at the mercy of a handful of machines in a rented data center and have to pay a couple of systems engineers when I could pay application developers instead who are going to bring new functionality to my products.  To me, new functionality equals value...systems engineering is something I want to outsource to Google.  It's something they've proven themselves to be incredibly good at.  We're a very lean startup and I want ALL of our resources focused either directly on our Customers or directly on software functionality that will directly benefit our Customers.  To me, anything else is extraneous and will be outsourced to somebody who can do it better.  In Austin, TX I can't even begin to hire a single really good systems engineer for what I'm paying Google, and with our business model even when we're blowing out our revenue projections we won't even be close then.

But then that's me, our requirements, and our application profile.  

I'm not insulted, I'm just try to stimulate a more meaningful conversation than blanket statements that don't take into account all of the real factors involved in such a complex decision.  By the way, you never answered my questions about what your engineers cost and how that impacts your capital issues.  I have a hard time believing the time/value your engineering staff spends setting up, configuring, managing and monitoring machines doesn't exceed $48,000 per year.  

Is geographically dispersed essential?  Well yeah, if you believe, like I do, that you engineer things right from the beginning.  I've been building large, complex software products for a LONG time and I've found that it's very hard to come back and "fix" or "re-do" things after the momentum gets going.  Once things get rolling there will always be many competing demands and telling the CEO that you've got to put the brakes on the product roadmap for six months so you can migrate to a different stack/data-center can be a career-shortening conversation.   If you believe your customers will demand a solution that is engineered for scalability and resiliency and fault-tolerance, then running in distributed data centers is essential.  Maybe not back in the 1970's, but in this century and decade anyway.

Jim

[Coto Augosto C.]

:) haha. That's true!!! Some people think we are insulting their family when we say that google app engine is very expensive telling "oh, I am a developer with hundred of years of experience"

C'mon guys: open your eyes "Google app engine is very expensive for companies that are beginning"

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

[Rafael]

I'm the only engineer working on backend, so I pay $0 per year to configure, manage and monitor machines. Startups don't have cash to hire systems engineers. 

In my startup I'm an engineer, not a "systems engineer" or "software engineer" or "bathroom cleaner engineer". 

If people can build code complex code, why they can't build scripts to automate the cloud configuration? Most people have those already built from past jobs anyway.

It seems that you are taking a defensive position from a strict engineer perspective. 

For a startup to succeed, you might find yourself doing tasks from cleaning bathrooms, sys admin, community management among other things.

Paying more now so you don't get fired in the future might not be the best option for a startup.

cheers,

rafa

[Doug Anderson]

Rafael & Kaan... since you both utilize dynamic image serving, do either of you have an issue concerning the size of dynamically served images?  I filed the issue below a while ago and it has seemingly been ignored by Google.  In short my grievance is that dynamically served images are effectively sized with JPEG quality = 100 (or very close to it).  Thus, the dynamic images are typically 3x larger than a comparable image scaled statically via the the Images service with quality=65 and 2x larger than quality=85.  My app saves a large reference image (1440x1080) and I use dynamic image serving for a variety of smaller sizes.  For image heavy apps the difference really adds up... especially for mobile.  My issue is below if you have an interest in this topic (your thoughts/feedback is much appreciated):

https://code.google.com/p/googleappengine/issues/detail?id=9979

[Rafael]

Doug,

Does that behaviour also happens in production? Compare prod vs dev. 

That's another reason why I prefered to run my own image serving, I control all the parameters and can also add things like watermarking, vertical cropping and WEBP formatting.  

thanks

rafa

[Doug Anderson]

Yes, the tests I conducted were on the production server.  I'd even be content if the resized images used the same default (quality=85) as the Images service.  A switch to a more reasonable default would instantly cut all dynamically served images to nearly 1/2 the size...  that must be significant bandwidth even for Google.  It's either an oversight on Google's part OR they deliberately chose not to utilize the extra CPU bandwidth required for additional compression (???).

Serving yourself allows additional flexibility (such as in your gist) but you don't get the cost benefits of the dynamic image service (no CPU charges)

[Rafael]

Hi Doug, 

Just correcting your phrase a little bit: 

"that must be significant bandwidth even for YOU"

We've cut thousands of dollars out of our total bill by serving the images ourselves, through a real cdn. 

Appengine output bandwidth is much more expensive than almost any other cdn out there. 

Again, keeping this thread on topic, my advices only make sense if you have your server bills are in the thousands and are struggling with server costs. 

If you're an early stage startup with < $100 bill or an overfunded startup or a big corporation, who cares? :)

thanks

rafa

[Kaan Soral]

I assume he caches the images somehow, might even be possible with appengine's services, pagecache etc. however I haven't looked into them, but I'm sure an external service could handle it easily - although I would definitely keep the simplicity of google's images service instead of going the manual route, although at a future point it might be doable

[Coto Augosto C.]

Rafa, do you work for snapchat?

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

[Doug Anderson]

I think GAE is trying to remain competitive with Amazon Web Services etc... and not with CDNs.  App Engine and Google Cloud Storage *is* competitive with Amazon Cloud Services EXCEPT those services offer tiered pricing (lower prices) for high volume clients... to my knowledge App Engine doesn't offer that (at least not publicly advertised).  App Engine isn't much of a CDN as far as I can tell (I don't think that's a prime objective).  It would be hard to argue against augmenting with an actual CDN where appropriate.

Certainly technologies like Docker and OpenStack go a long way toward helping a lone wolf build a maintainable stack but I think you'll find that if you run that stack on Amazon's cloud (for instance) that GAE pricing *is* competitive.  So I would contend that your pricing argument is more of a generic Anyone's Cloud vs Custom Hardware argument.  I can certainly save a ton of money by storing data on local hard drives vs the cloud but then I have to worry about redundancy, drive and fan failures, rebuilds, backups etc.  If you want multi-site redundancy and/or need rapid scaling/growth costs go up and the cloud starts to look intriguing again.  Each (cloud and custom hardware) still has its place imo... 

[Rafael]

I wish! ;) 

[Rafael]

Doug, 

I agree. 

My "argument" is that, when costs is an issue, most startups can't afford to not be worry about things :)

thanks

rafa

[Jacob Taylor]

I believe they are using a very substantial network CDN for serving static content. I think they only charge bandwidth for items served from their CDN. You can always choose to use something else in addition.

Jacob Taylor

CTO, Kahuna

(650) 302-1864

www.useKahuna.com

http://www.linkedin.com/in/thejacobtaylor

 You 

[Coto Augosto C.]

Absolutely agree.
I used to rely on app engine services more than heroku or other PaaS but now I am disappointed after see that I have been billed for pagespeed while it was disabled and I was billed 3 months for back-end instances type B2 while we had B1.

Other issue I had was when our application was down for 2 days and we didn't have a door to report it. We had to paid for gold support ($400) for gold support, I called and they fixed the issue in 3 minutes by restarting the instance. Do we have to pay to fix issues in Google end?

I am pretty disappointed now :(

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8x7pHZI0XRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.

[Andrei Volgin]

App Engine is very cheap for startups. I would even say it's a game-changer. I built two startups before PaaS became an option, and I can say with certainty that App Engine would have saved me millions of dollars each time.

Most new applications can happily live within a free quota until they prove to be useful for a significant number of users. A well-built app will have a to serve a whole lot of users before it costs more than $200 per day on App Engine, and that's still cheaper than a single systems engineer or a DBA.

I think that App Engine is difficult and expensive for less-experienced or less-qualified developers. Sloppy data models, unnecessary indexes, overly complex queries, unintended dependencies, large third-party libraries for simple tasks, wrong headers on static resources - these mistakes are not always noticeable when you run your own box, given how cheap and powerful the servers are these days. With App Engine these mistakes add up very quickly.

On the other hand, App Engine gives you all the information you need to analyze your bill. Once you see that a certain item becomes significant, there are ways to optimize your application in order to reduce costs. I certainly advocate avoiding basic mistakes from day one, but there are certain optimizations that make sense only when volume picks up. For example, you can move a backend task to a Compute Engine instance, which is many times cheaper, but requires more work to set up and manage. Or you can split a complex data entity into two separate entities so that a minor change will not result in multiple datastore writes. Or you can unindex some properties and iterate through query results, saving on writes and data volume. Or you can set the correct chunk size on your queries - something that many developers probably forget to do. And so on.

I am working on an app now that loads, processes and indexes 1 million web pages and creates app. 10 million datastore entities for less than $100 in App Engine costs. I don't know what your application does for your users, but that's a whole lot of processing power for a hundred bucks. Once we hit a million users or so, we will move some of our processing load to the Compute Engine, but the effort does not make economic sense before that.

[Rafael]

I don't understand why people keep adding DBA or systems engineer costs as a benefit of appengine. 

Most startups don't need those profiles at the beginning. Most engineers can do that work at design time. 

It's not that difficult to setup a fail-safe cluster.

I have done all of those optimizations you are talking and many more, like the most crazy things: minifying the JAR's with proguard so classpath scanning is faster and boot time is reduced.  

Again, I love appengine and have been using it since day one, but it's expensive. 

It looks like you have a lot of experience on appengine. 

Please, be kind share your experiences you hit 1 million users access your site every day. It will be very insightful. 

thanks

[PK]

The support pricing is a very sore point for me too. I can see why when GAE becomes perfect and all the "support calls" are because of user errors this might make sense. This is not the case as of yet. For instance, both last Saturday and tonight I am hitting "customer embarrassing and confidence loosing” hurdles because of GAE (see issues 10399 and 10503). Asking me, or any other paying user, to pay extra, so that I can timely report these issues and then GAE can timely repair them, and restore the service where is should have been in the first place, is adding insult to injury…

PK
http://www.gae123.com

[husayt]

Hi Rafael,

I have looked at your alternative ImageService implementation.

https://gist.github.com/mufumbo/8547036

One suggestion would be switching to GCS (googleCloudService) for hosting image, that would be cheaper, with almost no change to code. You might just need to migrate existing blobstore files to GCS, which should be easy too.

Also ImageService calls are expensive and slow, if certain image is being used often, you may write processed result into gcs and use from there on subsequent calls. CDN will fix that as well.

All the best.

HG

[Jim]

I would suggest that you need to consider the opportunity cost of the time you spend diddling bits instead of building something of value to your customers.  

[Rafael]

husayt, 

We considered that, but we feel it's just an absurd to do another migration (we already migrated from datastore to HDR). 

It feels that if these latent migrations become an issue, it would be better to accumulate them and migrate out all at once. 

I thought the whole point of paying absurd rates was to not go through migrations :)

In any case, that's a great suggestion and thank you so much for sharing. 

rafa

[Rafael]

Jim,

No comments on your comment. Have you read it in facebook headquarters? :)

What would you do if you put all your savings in your startup and there's no more money in the bank? 

Logically, wouldn't it be good to just reduce the server costs from $10k to $1k? 

Have the best luck with your product, and I hope you arrive to the point where you have these kinds of problems. They are great problems to have.

[Aleksei Rovenski]

Rafael,

I'm very curious are you running on Java or Python runtime? Or maybe you tried both. It seems to me that Python developers are more happy with Appengine performance...

Aleksei

четверг, 23 января 2014 г., 21:56:05 UTC+2 пользователь Rafael Sanches написал:

[Rafael]

I'm on Java. Unfortunately it feels like the appengine team went to solve bigger and more important problems before making the Java environment better.

[Nathan Suchy]

You however are paying for a managed service where you upload your code and you do no maintance and you sit and enjoy your app working. You can focus on making and uploading the new features. It's very awesome what Google App Engine can do. I proxy my internet traffic through app engine and it's very fast and it never fails me.

On Mon, Jan 20, 2014 at 1:20 PM, Rafael <mufu...@gmail.com> wrote:

that's may be the reason why their product is so simple and elegant. 

it was probably extremely hard for a new grad to make something more complex with appengine? :)

On Mon, Jan 20, 2014 at 2:19 AM, coto <rodrigo...@gmail.com> wrote:

We all should be surprised, because Google App Engine is very expensive!!

On Sunday, January 19, 2014 5:23:13 AM UTC-3, alex wrote:

Why were you surprised?

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

--

Nathan Suchy

m...@nsuchy.net

[Nathan Suchy]

Why don't you just resize the image in your app, it wouldn't be that much more code. In html it's simple as adding 2 attributes to the <img>

Nathan Suchy

m...@nsuchy.net

[Rafael]

Nathan, he's talking about the size of the images going back. They can be compressed better and save bandwidth and also decrease the download time on mobile phones.

For the vertical cropping, we did it in the client code for a long time, here's the reasons why it's not a good idea: 

- lots of extra code to do that cropping on: html, android, iOS, windows 8, windows phone. 

- increase of server costs due to uneccessary extra data being transfered, output bandwidth is very expensive. If I need a 300x100 photo, it needs to download a 300x300 squared image and throw away 300x200 data, it's a 2x waste in bandwidth, processing on clients and mobile phone overrate. 

- some designs just look better with vertical cropping

[Rafael]

Nathan, 

appengine was on and off today for 3 hours. what you mean by "it never fails me"? 

There's no silver bullet.

[Jim]

I think we beat that horse to death!

Good luck to you as well.

[Tapir]

On Tuesday, January 21, 2014 7:52:40 PM UTC+8, timh wrote:

Just for the record, the app I was talking about might only have 2000 users, but it is by no means a simple application.

I has approximateley 30 different models.  Fully defined with RBAC security model scoped down to parts of models.   

reporting, audit trail records for every change to data, (when and what was changed, by who), etc....  

The entire system is modeled in UML, python models, views, URL paths, security declarations, form schemas all directly generated from the model.

What elements of a view appear for the combination of user, context, and view control page layout, so the application is intensely dynamic and most cached data's scope is only effective for a single user.

So even complex applications can be run in a cost effective manner on appengine.

2000 users? how many pageviews per day?

costs only $2-$3 a day? Only?

If there is no the free hours, it would be $5, right?

$5 per day for 2000 users? and it is cost effective? Really!!!

 

But no point trying to stick a square peg in a round whole.  If you data model, or processing requirements don't suit appengine and you can't start instances quickly then 

you may well be on the wrong platform.

Now more than my 2c worth ;-)

T

[Kaan Soral]

Tapir, out of curiosity, are you a form of an improved internet troll sent from the future to troll these groups? (Just kidding)

Anyway, if those 2000 users pay 49$/month, for example, and the daily costs are only 5$, it would be extremely cost effective, you also have no idea what the app does for that 2000 users, might be a lot of stuff

[Tapir]

On Saturday, February 22, 2014 1:10:09 AM UTC+8, Kaan Soral wrote:

Tapir, out of curiosity, are you a form of an improved internet troll sent from the future to troll these groups? (Just kidding)

Anyway, if those 2000 users pay 49$/month, for example, and the daily costs are only 5$, it would be extremely cost effective, you also have no idea what the app does for that 2000 users, might be a lot of stuff

:) I am just curious how SnapChat can profit with App Engine's so high instance price. So I google "snapchat app engine", then google shows me this thread.

I still haven't found any detail specifications provided by SnapChat's owner company.

Your example is very extreme. I'm curious how many pageviews and revenue of timh's website. This is important for evaluate if App Engine's instance price is high or not.

[Kaan Soral]

I have an extremely poorly monetized app, it's an almost ancient app of mine, does millions of operations daily, only a fraction are converted to page views and only a fraction generates revenue

Even in my case, it's profitable, the costs are 1/2 instance costs and > 1/2 datastore read/write + bandwidth costs

So even though appengine seems comparably expensive, in most of the normal use cases the costs should be manageable / lower than the income

One disadvantage I noticed lately (You always see people complaining about it on these groups) is that the initial costs seem to be high, but as the traffic increases, the costs doesn't increase proportionally.
So basically, appengine gets cost efficient with increased traffic, seems logical - so basically you have to excuse the initial daily ~<10$ costs if you are keeping instances and memcached alive

On the alternative side, the side you compare appengine too, if you were to keep virtual instances or a big dedicated server alive, you would also pay a similar amount daily/monthly

I would suggest you not obsessing over the costs excessively, from experience, it only makes you lose time and energy, use that time and energy to monetize what you are doing and reduce the costs by optimizing your app

( Let me also drop one naive example here, let's say you are doing 50 RPC calls with a naive php/vps setup, those calls would take up 50X time, however using appengine naively, you can do that 50 RPC calls asynchronously, it would only take 1x time, and you would pay 1X time, appengine would be cheaper, it beats up your 46x thread :) )

[Tapir]

On Saturday, February 22, 2014 2:42:37 AM UTC+8, Kaan Soral wrote:

I have an extremely poorly monetized app, it's an almost ancient app of mine, does millions of operations daily, only a fraction are converted to page views and only a fraction generates revenue

Even in my case, it's profitable, the costs are 1/2 instance costs and > 1/2 datastore read/write + bandwidth costs

So even though appengine seems comparably expensive, in most of the normal use cases the costs should be manageable / lower than the income

It would be better if you can provide more details, such as the cost, the revenue, how many requests per day.

If you earn $100, you pay google $90, I don't think GAE's price is reasonable.

 

One disadvantage I noticed lately (You always see people complaining about it on these groups) is that the initial costs seem to be high, but as the traffic increases, the costs doesn't increase proportionally.
So basically, appengine gets cost efficient with increased traffic, seems logical - so basically you have to excuse the initial daily ~<10$ costs if you are keeping instances and memcached alive

I see. I think you are right on the ratio of cost/revenue will decrease when the app becomes some larger from a very small scale.

But you still haven't proven GAE's instance price is reasonable. I need the detailed numbers of some success stories.

 

On the alternative side, the side you compare appengine too, if you were to keep virtual instances or a big dedicated server alive, you would also pay a similar amount daily/monthly

I always have some VPS servers running, either using App Engine or not. These VPS servers are not filly used. These VPS severs are much powerful than GAE F1 and B1 instances but much cheaper.

 

I would suggest you not obsessing over the costs excessively, from experience, it only makes you lose time and energy, use that time and energy to monetize what you are doing and reduce the costs by optimizing your app

In fact, I don't very care about the current cost. I just worry about the future. My app is still in development stage. I must consider the case of possible later large traffic.

 

( Let me also drop one naive example here, let's say you are doing 50 RPC calls with a naive php/vps setup, those calls would take up 50X time, however using appengine naively, you can do that 50 RPC calls asynchronously, it would only take 1x time, and you would pay 1X time, appengine would be cheaper, it beats up your 46x thread :) )

? not very understand this. Do you mean using 50 GAE instances to handle the 50 RPC calls at the same time? The cost would be 50 x 15 minutes! :)

[Jeff Schnitzer]

Just to quickly shoot this argument in the head (and I say this as a
GAE aficionado):

I would ignore any claims about "geographically dispersed" or
"automated failover" in this calculation. The only reason we care
about that is because it brings reliability, and GAE has historically
not met the level of reliability that organizations want when they
start adding requirements like geographic dispersion. So it's really a
moot point.

Jeff

[Mahron]

I think app engine pricing is pretty fair. The money you may save by managing custom servers you will soon loose with time and health which are both priceless (if you do it yourself that is).

I recently launched the app engine app I was working on (www.xehon.com). Its a pay as you go CMS. So the app actually computes the exact cost of the requests and storage(datastore and blobstore), and unless you do heavy video and file downloading it is really cheap. An new account comes with 5$ credit which is more or less 1$ of app engine usage cost. Even with heavy usage it would take weeks to burn if off. I guess in the end it all depends on your business model.

As for downtime or internal server error, I have rarely experienced it. So I am pretty satisfied with GAE. For now :p 

[timh]

Hi

Even at $5 a day it is cheap, so lets work with that nice round number.  There is no other infrastructure cost, there are no devops support people involved.

So I have been looking at other PAAS, (not interested in anything less thant that)  if nothing else than to broaden my understanding of what is out there.

Heroku, (just to add auto scaling which it doesn't have out of the box, so you need adept-scale (min $18 per month) or HireFire ($10) on top of what you your paying to Heroku.

Openshift does have autoscaling, so you are up for $20 per month, plus usage costs for 3 small gears. So this might be cheaper, but I haven't run anything on it yet to know.

There are others obviously but a lot don't seem to provide auto scaling.

The App I talked about has a very peaky use, no one uses it over the weekend, big peaks in the morning and afternoon.  It's an evidence tracking systems (evidence of work/course material done) and has to be used.  There are millions of entities in the datastore and growing.  It is a big python application with full role based access control. There is audit trail records created for everything performed in the system.

A large part of the system uses AJAX, and it is not really a multipage application, so pageviews are somewhat meaningless form of measurement.  

There historically has been some unreliability and since moving off M/S to HRD that's pretty well gone away.

 

Any way you cut it $5 a day is a reasonable price for an application that is not relying on advertising for it's revenue.

Just my 2c worth

T

[Tapir]

On Saturday, February 22, 2014 10:29:11 AM UTC+8, timh wrote:

Hi

Even at $5 a day it is cheap, so lets work with that nice round number.  There is no other infrastructure cost, there are no devops support people involved.

So I have been looking at other PAAS, (not interested in anything less thant that)  if nothing else than to broaden my understanding of what is out there.

Heroku, (just to add auto scaling which it doesn't have out of the box, so you need adept-scale (min $18 per month) or HireFire ($10) on top of what you your paying to Heroku.

Openshift does have autoscaling, so you are up for $20 per month, plus usage costs for 3 small gears. So this might be cheaper, but I haven't run anything on it yet to know.

There are others obviously but a lot don't seem to provide auto scaling.

The App I talked about has a very peaky use, no one uses it over the weekend, big peaks in the morning and afternoon.  It's an evidence tracking systems (evidence of work/course material done) and has to be used.  There are millions of entities in the datastore and growing.  It is a big python application with full role based access control. There is audit trail records created for everything performed in the system.

A large part of the system uses AJAX, and it is not really a multipage application, so pageviews are somewhat meaningless form of measurement.  

There historically has been some unreliability and since moving off M/S to HRD that's pretty well gone away.

 

Any way you cut it $5 a day is a reasonable price for an application that is not relying on advertising for it's revenue.

Hi, man, please post more details in this thread, https://groups.google.com/forum/#!topic/google-appengine/lFxW7NR2gtQ, ok?

All you above said has nothing related to proving GAE is cheap or not!

Before you post the details, all your million words is meaningless at all for prove GAE is cheap or not!

Is it difficult to do this?

[Tapir]

On Saturday, February 22, 2014 5:32:07 AM UTC+8, Mahron wrote:

I think app engine pricing is pretty fair. The money you may save by managing custom servers you will soon loose with time and health which are both priceless (if you do it yourself that is).

Yes, I also really think GAE is great platform to test and debug your apps at development stage by using the free hours.

But I never think it is cost effective when your app becomes large.

[timh]

All you above said has nothing related to proving GAE is cheap or not!

Sorry I don't understand what you mean by cheap.  What is cheap, compared with what ?  Unless there is some basis for comparison then 

how do you prove/disprove cheapness. 

By any measure for me $5 a day is cheap for the service provided.  Tell me how you want to measure cheap!

T

[Tapir]

On Saturday, February 22, 2014 11:33:16 AM UTC+8, timh wrote:

All you above said has nothing related to proving GAE is cheap or not!

Sorry I don't understand what you mean by cheap.  What is cheap, compared with what ?  Unless there is some basis for comparison then 

how do you prove/disprove cheapness.  

By any measure for me $5 a day is cheap for the service provided.  Tell me how you want to measure cheap!

compared with common sense.

cheapness means the hosting cost is lower than 3% of your revenue.

please provide your pageviews per day, is it so hard?

[timh]

So based on a running cost less than 3% of revenue, then this app is REALLY REALLY REALLY cheap.

I don't have true pageviews because as I said its 80% ajax transactions, so new template rendering etc.... so not a comparable measure.  But just to please you on a typical day there is around 2200 pageviews , but between 5 and 10 times that in terms of ajax transactions (which aren't monitored by analytics), but to be honest it's not something I really monitor closely as it not particularly important. 

Unless you compare features of a service, meeting a minimal base line for comparison any comparison is meaningless. You know apples and oranges.

I run another site that derives absolutely no direct revenue, it is their solely to get get people to visit a bricks and motor shop, and the $2 a day that is costing

is very cheap as all the advertising we run is Adwords (adwords is expensive) and the site running costs.  Yes I could run it on Digital Ocean or AWS small instance for probably cheaper, but then I have to look after infrastructure webstack/database, I do not have the time or inclination to do that.  So my measure of cheap is completely different to yours. 

I certainly don't measure the cost or quality of the service or the value of the outcomes in terms of pageviews per dollar  (at least not directly)

So I am not really going to bother with this discussion any more, in your opinion GAE  is not cheap, in my opinion by all the metrics that I am interested and the applications I run/develop on appengine it is. Does this mean I would run all new projects on appengine - absolutely not, I would pick the best (as much as I could) tool for the job.

[Tapir]

On Saturday, February 22, 2014 2:31:53 PM UTC+8, timh wrote:

So based on a running cost less than 3% of revenue, then this app is REALLY REALLY REALLY cheap.

Sorry, 3% is just the average value for the hosting world. It is not cheap at all, it is just general.

I know many websites the much lower value than 3%. 

I don't have true pageviews because as I said its 80% ajax transactions, so new template rendering etc.... so not a comparable measure.  But just to please you on a typical day there is around 2200 pageviews , but between 5 and 10 times that in terms of ajax transactions (which aren't monitored by analytics), but to be honest it's not something I really monitor closely as it not particularly important. 

Ok, you have 10,000 requests. $2 per day means you need 48 F1 instance hours.

I know you don't like the advertisement. But GAE official never says GAE is not capable for this model.

2200 pageviews means about $3 advertisement revenue.

If there is no the free hours, you would pay google $5.

The net profit is -$2.

(ok, ok, I know you are a rich man, you get a better model. Here, I just descript the situation from the view of common sense)

 

Unless you compare features of a service, meeting a minimal base line for comparison any comparison is meaningless. You know apples and oranges.

I run another site that derives absolutely no direct revenue, it is their solely to get get people to visit a bricks and motor shop, and the $2 a day that is costing

is very cheap as all the advertising we run is Adwords (adwords is expensive) and the site running costs.  Yes I could run it on Digital Ocean or AWS small instance for probably cheaper, but then I have to look after infrastructure webstack/database, I do not have the time or inclination to do that.  So my measure of cheap is completely different to yours. 

I certainly don't measure the cost or quality of the service or the value of the outcomes in terms of pageviews per dollar  (at least not directly)

So I am not really going to bother with this discussion any more, in your opinion GAE  is not cheap, in my opinion by all the metrics that I am interested and the applications I run/develop on appengine it is. Does this mean I would run all new projects on appengine - absolutely not, I would pick the best (as much as I could) tool for the job.

What the data all you provide exactly prove GAE is expensive!

Your sense is not a typical common sense.

Bill Gates will still think GAE is cheap if the F1 instance is charged with $1000 per day.

 

[timh]

What the data all you provide exactly prove GAE is expensive!

Your sense is not a typical common sense.

Bill Gates will still think GAE is cheap if the F1 instance is charged with $1000 per day.

What on earth are you smoking.  How does anything I said support your argument that GAE is expensive.

At no point do you EVER compare like for like.  So give us all a break.

I said the cost of the service is far below the 3% revenue.  Did you not see the REALLY REALLY cheap bit.

I am not made of money, but people derive their revenue from other sources not advertising. 

If you don't like it and it doesn't suit your revenue model then get off GAE. 

 

[Tapir]

you coool! rich man.

 

[Pertti Kellomäki]

On Fri, Feb 21, 2014 at 6:54 PM, Tapir <tapi...@gmail.com> wrote:

$5 per day for 2000 users? and it is cost effective? Really!!!

You really need to look up the law of Diminishing Returns <http://en.wikipedia.org/wiki/Diminishing_returns>.

 

If you are worried about a cost that is less than you daily lunch, there is something severely wrong with your business calculations.

-- 

Pertti

[Tapir]

Diminishing Returns is a good theory, Rafael Sanches may prove it doesn't apply on GAE Java.

 

-- 

Pertti

[Jay]

Tapir, I really do not understand what you are trying to accomplish. Tim was sharing his thoughts and you come back with childish stuff like this. 

You are asking people to contribute their success stories to your other thread. You have made some choices in how you responded in this thread. I don't think those choices are likely to attract many to the other thread you would like to get going.

From reading some (not all, forgive me in advance - I know I'll need it) of your posts over the last few days, it seems to me that you have already made up your mind that GAE does not tend to meet your business requirements. That is fine. But it seems almost as if you continue to post in the hopes that some "white knight" is going to come along with a nugget of information that you may have missed and make it work for you. 

You have specific needs and very specific ideas. Do the work of putting your model together and testing it. I think you have actually. If you have, then trust your model - you have your answer. 

[Tapir]

On Sunday, February 23, 2014 6:03:43 AM UTC+8, Jay wrote:

Tapir, I really do not understand what you are trying to accomplish. Tim was sharing his thoughts and you come back with childish stuff like this. 

You are asking people to contribute their success stories to your other thread. You have made some choices in how you responded in this thread. I don't think those choices are likely to attract many to the other thread you would like to get going.

From reading some (not all, forgive me in advance - I know I'll need it) of your posts over the last few days, it seems to me that you have already made up your mind that GAE does not tend to meet your business requirements. That is fine. But it seems almost as if you continue to post in the hopes that some "white knight" is going to come along with a nugget of information that you may have missed and make it work for you. 

You have specific needs and very specific ideas. Do the work of putting your model together and testing it. I think you have actually. If you have, then trust your model - you have your answer. 

Hi man, none of googlers says GAE doesn't not tend to meet my business requirement.

On the contrary, GAE docs shows GAE SHOULD be very suitable for my business model.

I only found you and Timh said GAE doesn't not tend to meet my business requirement.

What is childish do you mean?

A rich man think GAE is cheap, so that everyone also should GAE is cheap?

I have shown strong evidence that the core GAE Java SDK lib has a big impact on the warmup time.

Even the simple official guestbook example on git has a 7-10 seconds warmup time.

I think the warmup problem is the root cause of GAE Java apps need more instances.

I also prove GAE compute units (instances) have a more higher prices than EC2 and GCE.

If GAE team can't (or not wailing to) solve the warmup problem, they should lower the instance price.

What is wrong here?

I just show hard evidences. On the contrary, some people just say "Hi, I'm satisfied with GAE, so you should be satisfied with it too, otherwise, get off!"

Who is childish on earth?!

[Alexis]

Just to emphasize what Kaan Soral said, without going into cheapness evaluation:

 "the initial costs seem to be high, but as the traffic increases, the costs doesn't increase proportionally.
So basically, appengine gets cost efficient with increased traffic, seems logical - so basically you have to excuse the initial daily ~<10$ costs if you are keeping instances and memcached alive"

It goes way further than saving costs for keeping instances and memcache alive.

When we launched one of our products, we had one engineer working on the back-end side (99% AppEngine). We had a few hundred daily active users.

Then our product became very successful and we reached 5 million (!) daily active users. We still only had one engineer working on our back-end.

@Tapir I'm sorry I can't really answer your 'Please share your GAE success stories!' questions as I'm not allowed to share cost/revenue figures.

[Tapir]

You don't need to share all listed in that thread.

Just share as more as possible.