This is what can happen if you use a technology in production without knowing it in depth.

And…

11.2. YOU EXPRESSLY UNDERSTAND AND AGREE THAT YOUR USE OF THE SERVICE IS AT YOUR SOLE RISK AND THAT THE SERVICE IS PROVIDED “AS IS” AND “AS AVAILABLE.”

http://code.google.com/intl/es-ES/appengine/terms.html

GAE is a platform for high scalable websites. For those kinds of websites you DO care about fixed-time scheduled jobs, you DO care about avoiding to use JOINs, you DO care about denormalization, etc. If you can’t build (or you don’t want) your website with those limitations, or you don’t need the benefits, just don’t use GAE or any NO-SQL database.

You could know these things just reading the Google group for app engine or the documentation.

You chose a motorbike when a car is what you needed.

Most of you problems have been design problems. The other problems have been due to use a service without quality agreement. You chose the “cheap & easy solution” for your business.

1.- At least 8 of your 13 points are about restrictions.
2.- The others are about stability. You can’t predict the future but you should know that your business is based in an unestable technology without quality agreement.

If you use Django, give http://www.djangy.com a try. It’s heroku for django and it’s looking great.

They are trying to fix several of your points.

#1 – Talked about at Google I/O
#2 – Talked about at Google I/O
#3 – Also talked about at Google I/O

gimenete, you are being an asshole.

Carlos, thank you for sharing your experience.

Had all the same experiences here, thanks for posting. It’s important for people to know the limitations of GAE as it caused us a ton of setbacks.

Thanks for sharing your thoughts, this basically proves what I thought when exploring GAE. I also think it always risky to make your application so depend of one service provider.

Architect and Team Leader
Oficina de Software Libre, Universidad de La Laguna

(Information Technology and Services industry)

March 2008 — April 2009 (1 year 2 months)

Architect & Team Leader
Agile software development coach
(Tenerife, Spain)

??????
And which half of your mind told you to use GAE?
gimenete is right. This is design problem.:)))

Carlos, thanks for sharing your experience. This post will be incredibly useful to a lot of developers.

As for the GAE apologist’s comments, it is hilarious that Gimente first says “GAE is a platform for high scalable websites.” and then turns around and criticizes you for using “unestable technology without quality agreement.”

Apparently GAE is for high-scalable websites, but you shouldn’t expect scalability/reliability because the technology is unstable.

So, you tried a hello world in your “spike” and then you complain about joins not working? And you praise your architecture, but you complain that memcached is unreliable?

Wow. Just wow.

“we were finding the problems as we go, we didn’t know many of them”. Wow, it seems you really didn’t want to read the doc or anything at all about GAE before starting your project. Everything you mention are well known facts about App Engine. It is not EC2, there are limitations and some of them are pretty severe for sure… I’m really sorry about the loss of time and money, it sucks. On the bright side, this is a lesson you’re not ready to forget. Spend a day or two researching before basing your new project on a technology you don’t know.

Is English your 2nd language?

I usually don’t comment on these posts, but I don’t like seeing so much bashing.

Sure, you could have done more spikes, but I think you would have found a workaround for each of the individual problems you encountered. It is only when they occur together and at a certain scale that they are truly painful and unacceptable.

Your expectations about the quality of service given that it is Google that is behind it were reasonable too.

From your description, it seems that NoSQL was not a good fit though and you should have discovered that sooner (that’s a major design decision). But maybe that’s just hindsight bias.

Because I like to build my systems from the ground, I don’t like these platform providers, but it must look terribly appealing to anybody who don’t want to configure every single piece of software they use. Your post will be helpful for these people!

1. You know this going in, why complain about it… or just use Java.

2. Again something else you know going in.

3. If your requests take over 30 seconds you need to be using task queues anyways, and if you’re trying to mass import data you should be using the Python bulk loader that handles breaking it over multiple connections for you.

4. We don’t have any issues talking to FB and Tw as we use task queues and if one fails it just gets retried.

5. Again something else you know going in.

6. You’re right there are no “LIKEs” but this can usually be worked around… anyone who’s serious about search isn’t using “LIKEs” in their DB to accomplish it anyways.

7. Denormalize

8. It’s not slow if you’re querying on an index.

9. This is a short-coming, however I’m not sure there’s an easy solution around them getting exactly the same considering BigTable is the underlying tech.

10. Again, it isn’t designed to be a search engine, you’re trying to fit a square peg into a round hole.

11. No need for more than 1000 records in most cases.

12. We’ve never experienced data loss, as for memcache, well that’s not supposed to be persistent anyways so your app should be able to handle that failing.

13. Memcached has always been limited to 1MB this has nothing to do with App Engine.

Google App Engine has saved us a lot of money.

It sounds like you chose a solution that your application was not suited for, not that the platform failed you. If you weren’t familiar with the technology, why would you use it?

Don’t fit a square peg in a round hole, not unless you have a lathe and someone who knows how to work it right.

[...] Reference: http://www.carlosble.com/?p=719 [...]

IMHO we are about to miss the most important point in the post, which is unfortunately the last and least:

Is GAE scalable?

If not, all the rest is irrelevant. None of the requirements of GAE worth implemeting for smaller projects.

As a side note: I’m not sure if Google aims something big with GAE. The rationale for this is that I can’t see a single place where Google promotes GAE strongly.

Cloud, nosql, dynamic languages… mostly hype. Thanks for sharing.

GAE is very limited in its capabilities, and as most posters have pointed out, there are plenty of ways of ensuring its the right platform for you by checking the numerous information resources there are out there, for GAE. Our experience has been, that its usually quite slow, reliably unreliable and very niche in its potential application, but if you can work around these serious limitations, its very cost effective. Most people here have put work into making sure these limitations have minimal impact; for 99% of applications GAE is the wrong solution, with some knowledge and understanding, for 1% its ideal

Carlos,

I wrote the first book about Google App Engine programming a couple of years ago. Ever since publication I had several opportunities to speak about App Engine for Python and Java at various conferences; I realized early on that my presentation “Google App Engine HOWTO” had become a “things to watch out in App Engine” and ultimately recommended folks to NOT use it for anything serious.

I enjoyed your post and have tweeted because I think it’s an important cautionary tale. Most of the work I do has to do with scalability and high availability. While I’d like App Engine to become part of my arsenal, it’s now only a marginal part of it, relegated to providing stateless RESTful web services instead of full blown apps. The real app continues to sit in a regular data centre or we put it on Amazon/Rackspace/etc.

About NoSQL systems: Datastore is hardly a good example of a good one. It’s good enough for App Engine, but you now know its caveats. Right tool, right job. I’d suggest that, should you identify document- or column-based data storage and retrieval needs, that you take a look at mongoDB and HBase. We’re using both in production with large enterprise clients without issues.

Take care and cheers!

Eugene Ciurana

The problem with GAE is that there is too much selling of scalable websites while most of point-ideas do not need all that. Also , the desire to build a highly scalable website comes at the compromises Carlos mentioned. These compromises are not talked about much by Google.

Things like decent Database performance, Capability to perform a decent text search on the database , Caching large data in memory are really table stakes to even consider any option. Google is not talking about these basic things and keeps on trying to sell on scalability

All this stuff is in the O’Reilly ‘Programming Google App Engine’ book which was published 1 year ago.

No comment. Please go RTFM. Done? Do it again. And again. Only then ask yourself if you can use a powerful tool such as GAE without burning your hands. #1 on HN… WTF are you doing, upvoters?

I think this post reflects a couple of issues that exist with GAE:

1. It requires research into if using it is good for the situation at hand. This is different than there systems, mainly because GAE provides something that other systems don’t provide from the initial step: automatic scalability.

2. GAE has reliability issues. Google has addressed these, and I hope they can offer a more reliable service in the future.

There is no reason to be critical of the author, as he drills the above two points into users who have not used GAE but are thinking of it.

As for me, I’ll use my existing servers on EC2 for my next project. If it starts to get big (which I doubt), then I will re-evaluate my options.

Thanks for the informational post, Carlos!

You got what you paid for!

Free services are usually that because their commercial value is limited. All the other issues with GAE are just trivial distractions.

So what exactly did you spend you 15000€ on? Which BTW is mere peanuts when you shooting to make money. Since you ported to your new environment in a week, I have to really question how big that codebase really is.

I agree that there are quite a few points here that could have been completely avoided by some simple research (ie. older python, no C extensions, no https, nosql etc.).

However, I’m really surprised by the amount of bashing that’s going on in these comments. Some of you, like JT and Gimente are simply being assholes. We get it guys, you LOVE GAE; good for you.

In this case, the author made a bad decision, but that is hardly what most people should take away from this post – it identified critical parts of GAE that wouldn’t be apparent from a quick glance. While yes, you should have mechanisms in place for dealing with a failed DB/memcache etc., nevertheless, you simply come to expect a stable product from someone like Google.

Thanks for sharing your experience Carlos. Good luck with the project.

Lastly, JT, your comment “11. No need for more than 1000 records in most cases.” is mind numbing. Anyone reading that statement should really begin questioning your software development experience.

I personally agree with Daniel. JT and Gimente are simply sore someone found some faults with GAE. Yes, the issues could have been avoided with some research; however, in the world of start-ups often times you cannot spend a month trying things out. Many times if you have external funding the pressure to get to production and start generating revenue is incredible.

Also to note, the (GAE) limitations Carlos and his team found are true and anyone thinking about migrating (or starting a project) on GAE should find these very useful to make an informed decision whether GAE is the right solution/tool.

Thanks for posting your experience with GAE, Carlos. Thanks for taking the time write this stuff out in spite of having lost your money because of it.

We’re really enjoying GAE so far (it’s lovely not having to worry about scalability, at least on the level that we’d normally have to), but thanks for the heads up. We’ll be on the lookout for these kinds of issues in the future.

Thanks for the informational post!

Interesting post. I agree with Daniel that while trying to make GAE do what it does not want to do is partially your fault, and the bashing you get here is unjustified. But Google is partly to blame, too, in that it overpromised somewhat on GAE. It is certainly not a killer tool applicable for all forms of general web development and the docs could be more clear about the limitations. The support is really unresponsive, too.

You need a Flattr account for your blog. Maybe you’d make some of that money back

Other people have commented on the biggest mistake you made – you clearly didn’t research GAE sufficiently before starting your project, and you bumped into problems after writing code rather than after reading the (short) manual. The limitations are not for everyone, but they are well published and workable for a very large problem domain.

And you’re right about GAE’s reliability issues this past year – they screwed up a couple times, they know it, and they’re working on it. They really mean it when they say “beta” for this product. In all fairness, homegrown systems fail too, with varying degrees of frequency depending on the size and quality of your operations team.

But what I really want to bring up is this issue of scalability, because that is the one thing that HASN’T been an issue with appengine. Yes, sometimes the system went down, and sometimes the system was slow – but this is in a giant system with likely petabytes of data serving thousands of requests per second. Scalability is the major promise that GAE *has* delivered on – your application can grow millions of users and terabytes of data and performance will be “about the same” as it was when you started.

Since you’re doing joins and LIKE queries, it’s likely that scalability is not one of your concerns. If it is, you may be in for a big surprise when the hordes show up…

I run http://justunfollow.com on GAE/J . I agree with you there are restrictions which can make life a little difficult. But some of the restrictions can really help you make your app more smarter. Like, the 30 second restriction made me make several http calls for tasks that I would have otherwise tried to finish up in a single call. I was cursing GAE for this but at a later stage when my app grew in size, I could make use of these extra calls to make my app more responsive in giving users details about the work being done in the backgruound. I could exactly pinpoint at what stage of processing a request was on.

And you say it becomes difficult to use twitter/facebook API? Well, my twitter app makes upwards of 10,000 requests per hour and seems to be working fine for me

You have every right to be frustrated and angry but GAE has its own advantages and disadvantages. Trust me, not having to manage your servers sometimes can be a big relief.

Would your problem have been solved with a cron job that pokes it and ensures that it remains in memory? I had presumed that the problem was more complicated than that you simply didn’t have enough load to keep an instance running. The cron job solution seems so obvious that I presumed that your problem was more complicated.

Hi Carlos

I totally understand what you’re going through. Google as a brand has been tarnished because of my experience with GAE.

Chris

Thanks for posting… this will surely save our team and others plenty of time/money.

To be fair, the 1MB memcached limit is imposed by memcached unless you recompile from source.

thanks for your post. I enjoyed reading it very much. Lots of good insider info.

Thanks for taking the time to post this.

Please do not let the google fanboys get to you.

Great post Carlos, thank you, and good luck with making that money back!

When I evaluated GAE briefly a year ago, I came to the conclusion that Google was not really behind it, and it had a number of flaws. You worked around these flaws, but the service itself failed in the end. Half-assing this service is another major mistake from Google.

This is a nice clear example of what can go wrong with The Cloud.

Thanks for sharing your experience, which I, for one, found enlightening. I can’t believe how quick people are to deride — is English your 2nd language ? — or point the finger to your failings. “It’s easy to criticize, it’s harder to share and contribute”, indeed.

Thank you Carlos for this post. We at Fotki invested few months into GAE, which also comes to ~$10K, and dropped it, after simple queries with 60MB database where taking for 2..3 seconds, and we run in all your limitations as well. Idea is great, but implementation is not ready for prime time yet…

May be after google invests few more millions of dollars, and few more years, we will try again, but for now, we will be using inhouse hourdware.

I think everyone in the discussion is missing the most important part of the post. It is the fact that Google’s customer service is terrible as evidenced by Carlos experience. One of the most important aspects of choosing a service provider is whether or not someone will actually respond when you are experiencing a problem. You can have the most scalable system in the world but it means nothing if the service provider has reliability issues and refuses to deal with their customers in a helpful and timely manner. This is the scariest part about GAE. It is Google’s disdain for their customers.

I love most of these comments, it sounds like whole bunch of Google employees got togeather and trying to bash the poor guy. Please FOAD and crawl back to your holes.

Google AppEngine sucks and you ALL know it

Thank you for sharing your experience.

Thanks for sharing this, really helpful, yup … better think twice to use GAE

Franco – it’s free to a certain point, then you start paying.

Carlos – don’t mind the apologists, I was working with GAE at a previous employer (Java version though), and ran into all the same issues that you mentioned. They still are using it since we were able to work around the limitations at the time, but in the future GAE won’t be my first choice.

We also launched a site using the App Engine, last year (a real-time “write the best joke for a picture” multiplayer game). We had peek times in which traffic storms hit us from such things as newsletter links. During our launch week, however, the Google App Engine was down several times for maintenance. Often an hour or two. Imagine what nice things that does to all the first-time visitors — right, they might never come back to check your site again! We had an Apache front-end merely talking to the App Engine data backend via JSON, so at least we could put up a proper error message, but that doesn’t help much.

Now you know what it feels like to be a Java/newbie developer with a tomcat.

;-(

[...] by ch0wn to programming [link] [165 comments] reddit: the voice of the internet — news before it happens @ [...]

When I saw this news post I figured well that’s what you get when you make a cellphone application.

What I mean is that this sounds like a service for learning how to write code for a game console or something else that is inherently limited.

True the c programing language was birthed under sever presure that would have killed most of today developers, but imaginary walls designed to make the parent company look good aren’t always beneficial.

I’m certain these requirements are great for google to save money but if I have learned anything about the software industry it’s that we make people buy better computers before we start causing ourselves pain (though it would be nice if next years games where likely to run on this year’s computers).

Much of the limitations talked about mean GAE Standard is unsuitable for enterprise apps, and hence there’s GAE for Business http://code.google.com/appengine/business/ : so good things in life are not free. If so, they aren’t good enough!

I had gone through a similar experience, albeit at much lower cost, and realized much earlier about the mistake.

The 5 or 10 second http request/response limitation is currently the problem. Clients don’t always have reliable fast internet connection, and on those that on very slow network only portion of the page got sent as google abruptly disconnect the connection.

How the heck your comment page showed my photo without me uploading it? Email address? oh man…

I think a lot of people have missed the point of the original post. One of the most important things to do is choose your tools and platform wisely.

Carlos didn’t, admits his mistake and thank you for sharing your experience as this is personally helpful to me.

As a company we considered Java operating on GAE but for various reasons, this did not line up with the requirements of the business. Which going back to my original point, in most cases choosing tools that allow the developers to deliver what the business has asked for is paramount. Sounds like GAE was not able to, so I applaud you for giving it a go and being brave enough to move before investing more $$$.

Hi Carlos,

I feel your pain. I’m glad you were able to migrate so well.

It might be worth keeping an eye on Djangy. It’s essentially Heroku / Engine Yard, but for Django.

http://www.djangy.com

For reference (in case others are interested), I’ve written about some of the Google App Engine limitations/surprises, such as…

The different mail API:

http://www.cloudartisan.com/2010/06/google-app-engine-gotcha-1/

The urlfetch timeout:

http://www.cloudartisan.com/2010/08/google-app-engine-gotcha-2/

The lack of a static source IP address for urlfetch (and other outbound traffic):

http://www.cloudartisan.com/2010/08/google-app-engine-gotcha-3/

And made a few notes on migrating from Google App Engine to Django:

http://www.cloudartisan.com/2010/10/migrating-from-google-app-engine-to-django/

Saludos!

David.

Thanks for the informative post.

I am also considering the possibility of migrating from GAE to elsewhere. One thing that you did not mention. Were you using GAE’s user API? i.e. Were your users logged in using GAE’s user API? If so, how did you handle migrating of user accounts.

Thanks again.

Most of your points are stuff that you should have caught in your research phase. It seems that there wasn’t such phase in your project because of you saying:
1) “So yes, everything looked cool”
2) “When we started developing features we started realizing the hard limitations imposed by the platform”

One way or another it has happened to all of us, so this is a lesson for next time.

p.s Mentioning the estimated 15k loss only exaggerates the mistake (and possibly makes this blog post popular).

Carlos, I agree with @gimenete on this matter. I’m a GAE starter and I’m actually porting a Twitter application (Foller.me) from a self-hosted PHP environment to Google App Engine. The limitations you have mentioned make sense, but there are always workarounds which you can implement.

The limitation to use naked domains (example.com instead of http://www.example.com) is perhaps the biggest one and it’s related to DNS and scalability, which Google says they’re working on.

Second limitation is the use of Python 2.5 but I have no issues of working with that. The only prob is that I use 2.6 on my development environment, and everything works fine until I deploy my app. Anyways, there’s versioning for that that helps you fix issues before switching to production.

The 30 second limitation is fine when you learn about the Task Queues API, and cron jobs can create tasks. It is a little bit strange since we’re all used to unlimited time, but adaptable.

JOINS? I like this one from Twitter:

Complaining that the #AppEngine Datastore doesn’t support joins is like complaining your car doesn’t fire tank missiles. ~ @jkupferman

So yeah, I’ll be investing more time and money into App Engine, and as soon as I figure out I’m wrong, I’ll write a blog post about it

Cheers!

I think your post is a little unfair to GAE. From all the items you list they are very obvious at the outset – and whilst they may seem a limitation they ate the confinements that are set in place to ensure a truly scalable solution. If you are used to building apps in the “conventional” old fasioned way of SQL and long lines of code – fine. but if you want to build an app that runs lightningly fast then the restrictions set in place on GAE will help you do so.
On another note the 500 errors are a disapointing downtime that many experienced. And i do agree it seemed to take ages for GAE admin to respond and deal with it.
I think and agree with many posters here that you “really must” learn and test a new enviroment before you dive in and try and build your real world app, if you dont sure GAE will catch you out – i like it, reminds me of building video games in the 80′s, its all about restrictions, cpu time, cycles and workarounds – that said i hope it dont backfire on me one day soon.
Im sorry to here about your miss-fortune.

??????

Sorry dude, but looking at your concerns, it seems like your app is a big fail.

I’m considering google as a platform for my webite, so I was intereted in this blog post. But your reasoning is just lame. Get better coders.

I think you are right about it. I still like the idea of a platform without servers/ressources to manage.

Fascinating how most replies blame the original poster.

The limitations are in GAE, which in fact has held itself out to be a scalable cloud solution. From the GAE home page: “Google App Engine makes it easy to design scalable applications that grow from one to millions of users without infrastructure headaches.”

Saying the poster should have known about the limitations has little to do with his complaints about the limitations. The bottom line is that GAE did not deliver on its claim. He has a legitimate beef, IMO.

Thanks for the insight.
I am currently evaluating GAE.
Actually you can read about most of the cases you pointed out from the “GAE manual”.

Good post Carlos. It clearly outlines why one should never use GAE. The worst thing is it took 1 week to migrate. Use a good VPS and if they screw up migrating should take matter of hours if not minutes.

ab: i dont agree with what you just said; app engine makes it very easy to scale from 1- 1 million or more users – with no headaches, by that you dont need to worry about servers, clusters, load balancers or data-centers based in many different locations to fullfill a truly global app across many continents.

But like any software program it is always a challenge to develop, the poster himself is under no doubt they did not make better judgements in the outset – this is a usual failing of most software applications.

App engine has its restrictions – everything has its trade offs.

If your building an app you need to think carefully how and where you build it.

It will be good to know medium/large complexity apps built using GAE. Folks having good experience with GAE, please post apps that you have built.

For those calling me an asshole: I don’t love Google App Engine. I have evaluated it and I know everybody using it should know the limitations starting at day one. For example: searching text in the datastore is the most voted issue (except for those issues voting more languages):
http://code.google.com/p/googleappengine/issues/list

And naked domains is the second most voted issue. And so on…

bcurdy and JT have written very good comments.

It’s nice to read the experiences of others, but come on, don’t use in production a technology you don’t know at all.

OMFG. You can _always_ count on the Google Fanboy Brigade showing up and defending their Prrrrecious. Y

ou people should realize that Google is just another huge corporation that’s ultimately only interested in making money off of you. All of their free services have been made to support that goal, and _not_ because Google is a saintly defender of your liberties.

Gimenete, you’re the most annoying, tedious windbag of all the fanboys that showed up, but then again, you _were_ the first so you’re probably the most rabid one too.

Great post. I had heard about GAE limitations, but it’s really interesting to see a real life example of the impact.

We all learn more from our mistakes than from the successes, so don’t take this as a big screwed up, but as a painful lesson

My company has three production apps on Appengine. One of these has over 250,000 users now, and we’re very happy with the platform.

I think most problems developers have with Appengine are to do with scalability. As someone who once had to scale a LAMP app, I know the issues that scaling introduces – they are huge, obscure and painful to work around. After that experience, I can see why Appengine works the way it does. It certainly does take developers some time to learn the ropes, but again, it’s peanuts compared to the hoops they’ll have to jump through when they have to re-engineer their app to run on multiple servers.

The recent datastore problems didn’t affect us, and even if they had I knew the best sysadmins on the planet were on the job. I’m very happy knowing that if Oprah mentions our app, we’ll be popping champagne corks – not blood vessels as we try desperately to add servers before the flood of disappointed users recedes.

At the end of the day I’m sorry Appengine didn’t work out for you, but it’s been a fantastic platform for us.

I think that the decision to use Django was bad in first place after all. GAE is a different beast than EC2, Rackspace and the shortages you mentioned can be considered as features given the fact that you know them because they can force you to use techniques for scaling (it happened to me).

About the downtime that ‘s an important point but when you are a small team I guess you won t be able to have a great uptime as well and of course you must pay some admins. If you can afford an admin and vps or iron then you are better off GAE.

[...] reading the post by Carlos Ble about costing him 15000€, see “Goodbye Google App Engine,” I’m convinced that I won’t deploy to App Engine or any Platform as a Service [...]

IF you want SQL, don’t develop for an non-SQL environment, installing python 2.5 shouldn’t be much of pain, etc. – did you even read and understand the documentation first?

As for the other “limitations” GAE, most, if not all, are just sound advice being enforced in hard way – you App should probably respect those rules anyway.

I think the only justified criticism in this article is the reliability of the platform, there has been too frequent performance problems – but I for one hope Google is learning. Any other platform has downtime too, I just don’t need to fix it when hosting at Google.

So waving with a “YOUR USE OF THE SERVICE IS AT YOUR SOLE RISK” terms line makes it ok release crappy/broken software? You google-hookers are unbelievable. Thanks for a great post Carlos!

I do understand and somewhat agree with the observations and rather generalized conclusions Carlos does still I’m glad and don’t regret migrating my app to GAE from a previous LAMP/Java installation mainly making it more cost-effective and much easier to do development and deployments compared to those FTP, SSH and tricky mod_rewrites we’re used to. Then again, since my application is rather trivial it might be the trivialness of my app (just a list with announcements) that makes me fell migrating to GAE was right in my case.

It’s a trap!

http://right-thoughts.us/images/uploads/Admiral-Ackbar-trap.jpg

The line for the post should’ve been “Don’t use GAE if your apps relies on PostgreSQL, Nginx, Apache2 and all that stuff” (which, on the other hand seems pretty obvious).

I think it’s great Carlos sharing their experiences, but it’s somehow biased blaming GAE for their problems.

I’m not a GAE fanboy, but discouraging its use in this way is not fair.

And people being called asshole for just pointing it out, it’s a shame for we all.

ADDING SOME MORE STUFF
1)For paging you have to write your own algorithm. Which should reduce the Data-store calls else you are gone.

2)There is no Session, you have to come up with your own.

3)Since You can not trust memcache, If you are writing your own session management it should be storing values in database.

4)Every basic stuff which is already solved has to be solved again in app engine (e.g. How to handle CSRF etc.)

I have been playing with GAE from its initial days. I had a pretty ambitious idea when I came across GAE for the first time. But unlike you, I didn’t spent any money into real development but started to stress test the platform by making sure it can insert or update 5000 entities in a single go and that failed about 60% of the time with Error 500

Thanks for this informative post, I’m sorry to hear it costed you so much

I see developers hitting brick-walls because they didn’t see restriction A or B in API X or Z, often documented, every week. It takes time to become truly familiar with any technology and time is precious, specially for start ups, but even in mature companies time/money constraints lead people to similar situations, it’s just human nature!

Looking on the bright side, you’ve learned a lot by overcoming all those brick-walls. Many won’t learn all that in the same depth because you’ve probably saved them the headaches. No Pain No Gain

I miss having a pint or two with you, hope to see you “soon”.

Thank you for sharing your experiences. Hearing someone talk about production use of a product is a brilliant way of getting a sense of it.
Every now & then we all choose the wrong product for our task, but few of us are willing to admit it and share our experiences. So thank you for doing that.

It’s not clear to me architecturally that GAE is good for complex apps — you don’t have a lot of flexibility in being able to pop out one component and swap it for something else. Adapting to changing product requirements I think would be more of a challenge than with traditional architectures.

That aside, I don’t know that I’d ever consider building a business on GAE — imagine if this service (as unlikely as it may seem) were to disappear altogether and your application architecture was heavily tied to it — what would you do? On EC2, I use as little of the custom Amazon services as possible for the very same reason; if Amazon should disappear, there are plenty of cloud providers offering essentially the same service. You can only get app engine one place — Google.

I might use GAE for a toy app or something I didn’t care to monetize, but anything related to any business I’m going to be working on isn’t going to be on app engine.

Great post! This helped me a lot! Don’t care about the bashing, they have some personal issues.

Thanks for sharing your experience!
Having developed a couple of GAE Toy Apps and currently working on a more serious one, I have mixed feelings about it.

Although GAE has a straightforward and well documented APIs, is not that easy: you need to be prepared, you must know every aspect and best practices to code in a proper way; you need to switch to common practices of standard web app to “ad hoc” GAE practices.
If you think to design and code your application like a common web application, the GAE limitations will turn your code in a bunch of complex and clunky defensive checks.
One thing that scares me is the lack of customer support; waiting an answer on a Google Groups when your app is dead is not a great feeling.

Anyway there are successful stories of web application developed on GAE (Optimizely, Webfilings), so I think it’s just a matter of documenting and code in a right way.

One suggestion, read Stack Overflow more:

http://stackoverflow.com/questions/565963/hidden-limitations-of-google-app-engine

You sust stop to blame the author. He already knows that using GAE was a mistake. It’s no need to repeat it over and over again. Great thanks to him for sharing his experience. Project is always risky, whatever you know or don’t know it’s technology. I’m just also too conservative to invest my money to such a ‘unknown technolgy’ project.

It comes down to stink. You can smell it, when you look at some new tech. Some tech stinks, and other tech doesn’t (so much).

I was excited about GAE when I heard about it at first, but then I looked at their spec and tutorials, and it stank to heavens. I’ve ever since distanced myself as far away as I could from touching GAE, and about the only thing I would remotely consider it for is as a CDN of sorts for free.

[...] Rovio feels the burn of Android fragmentation, plans ‘light’ version of Angry Birds Goodbye, Google App Engine Cssess – The Bookmarklet That Finds Unused CSS Selectors Berners-Lee: Facebook [...]

@Rakesh Pai

So, you tried a hello world in your “spike” and then you complain about joins not working?

No, he knew from the start that joins are not working. He complains that this is not a worthy tradeoff given the shit that GAE is.

And you praise your architecture, but you complain that memcached is unreliable?

No, he complains that memcache has a 1 MB limit in GAE.

It’s GAE’s datastore that he says it’s unreliable (and it is, you can read in Google’s own documentation that you have to code around it failing a lot of times).

Wow. Just wow.

Can you even read the bloody article? Is english your third language?

As for the people touting the “this is high availability” horn. Yes, sharding and sharing nothing and No SQL are concepts one can live with. The other GAE restrictions, frequent failures and general suckage is not.

Who said that GAE is for productive use?
Or why should Google work on a business version:
http://code.google.com/intl/de-DE/appengine/business/

If you want to have a production ready GAE you must wait and pay!

Sure to add one to this. I curse the day i decided to deploy my application to GAE.Am on GAE coz of ODK aggreate but since am thinking of porting MySQL to ODK aggregate then i will say bye bye to GAE when i succeed. if you do Machine Learning, then GAE is bogus. GAE is only for simple stuff. These guyz are just lucky that when they came to my country, Uganda i didnt know otherwise i would have fired them serious questions. what i suggest is that google should define clear boundaries of GAE when talk to people.

Cringe-worthy.

This blog needs a button.

This blog needs a share this button.*

This is some of the worst dribble I’ve ever read about App Engine. You obviously aren’t a very good programmer or craftsman for that matter because both craftsman and programmer know how to use their tools before starting a project.

Google provides very accurate documentation that clearly state the limitations and quotas they enforce upon all applications running on their App Engine but one has to be smart enough to read them (assuming you know how to read) prior to ‘investing’ time and money developing out a product.

Case in point: The 1000 limit on entities returned from queries. Well guess what? This quota was removed a long time ago and Google publicized that fact but obviously you are too smart and don’t need to keep up with their releases and new feature announcements.

Your obviously way to intelligent to be using App Engine so good luck on your next targeted platform though I suspect you will achieve similar results because as you say, you are a craftsman though in truth I would categorize you as a pure hack.

You should put a short summary in front of the article. People here don’t read to the end and start commenting as soon as they see your list of limitations.

Something like:
[GAE has many limitations that would be worth the effort if everything else would work as advertised. Site down 60% of the time.]

And it’s not only here in your blog. The “he hasn’t read the documentation” bashing on Reddit gets upvoted and nobody cares about the facts.

Geez guys, why so many trolls? Play nice.

Carlos fits the metaphor of a boiled frog. All of us that have been in software development long enough been caught in similar situations. For those who claim not to have had the experience: you will eventually. Give it time.

It is easy to be the Monday morning quarterback and say what should have been done differently. Even Carlos admits a few in the original post. Stop and give thanks to the people like Carlos who post their experiences and lessons learned for the rest of us.

@Markandey Singh: “2)There is no Session, you have to come up with your own.”
wow, just wow
of course, GAE supports sessions
this pretty much sums majority of the GAE-bashings

Very insightful post, thank you for sharing your real world experiences with the community.

At my old company we built one of our flagship products on App Engine because 1) we thought the massive amounts of limitations and issues would go away in time because of “Google Innovation” and 2) we were building a Google Apps based product so there was a marketing and product management affinity, and 3) Google hyped up AppEngine so much we figured they’d have to make good on it and keep it live or have big egg on thier face

Our developers went through many nightmarish development cycles to get basic functionality out – and these weren’t script kiddies who never saw a scalable app before. That said we finally got the app out to production, but the “Google Innovation” never came. Despite the 101-level Google I/O talks year after year, App Engine is still basically a sandbox mish-mash of various web technologies. When you look at how far AWS has come in the same time frame, you wonder how innovative Google really is outside of search.

On the marketing and product management usefulness of AppEngine for Google Apps plugins, there really is no great advantage here. You would think you’d get some better request lifetimes call Apps API from GAE, but in many cases they are worse.

On the third point, as we saw from Wave and I predict Buzz, Google has no problem pulling the plug on products that don’t catch on. GAE is getting it’s butt kicked by AWS and the metaclouds like EngineYard that run on it from one side, the real platforms like Saleforce AppExchange on the other, and the SMB focused function driven Saas platforms like Wufoo in the middle (yeah, Wufoo is a platform if AppEngine is).

For these reasons, it won’t be long until GAE is either cut, crippled, or changed so fundamentally that any investment today would be wasted.

We did make it out

Thank you thank you thank you Carlos Ble for posting this. You saved my ass.

The essense of the App Engine apologists’ argument is that App Engine is solely for high-traffic sites, and the AE limits are justified because AE provides high scalability.

The problem with that argument is that, in reality, App Engine simply is not scalable, even if you know how to write good code for it. There have been numerous blog posts and comments on reddit.com/r/appengine about how AE is prone to random datastore errors, memcache errors, mail sending errors, etc. Those errors seem to happen all the time. How can we believe that AE is scalable when it can’t even handle low-traffic sites without random errors all of the time?

Yeah, newbie devs, please leave GAE to smart people, we don’t need your fat old code running on the same cloud that powers our super apps! W GAE!

http://code.google.com/appengine/forum/?place=topic%2Fgoogle-appengine%2FoTEUi39W2Ks%2Fdiscussion
http://www.reddit.com/r/programming/comments/e9n3l/goodbye_google_app_engine/?limit=500

So, do you noted all this AFTER migrating your whole project?, Kind of joke blaming GAE for you loosing all that money. Maybe is true that GAE doesn’t fit your needs, but all that lost money is on you.

Thanks for providing a point of view next time a new client asks about Google’s app engine. We had an absolutely horrible time with it for one client and have vowed never to go back. And our problems had NOTHING to do with the limitations and everything to do with random errors that popped up with no understandable cause. Said client was much happier when we recoded and moved everything over to Amazon’s cloud. Maybe our code sucks and we don’t know what we are doing, but then I am glad that Amazon’s cloud is powerful enough to overcome our limitations .

Sounds to me like some of the trolls commenting in support of the platform are probably Google employees. Someone mentioned Google-hookers – lol. I’ll have to remember to use that one!

App Engine is not without its problems. Anyone who argues that it is has obviously never targeted it. The reason I am critical of the authors comments is because he obviously didn’t take the time to study the published documentation and learn about the platform he was targeting. He also didn’t keep up with releases which included new features and bug fixes. If he was limited by any single named value being larger than 1 meg in mem cache then he should have known 1) there is a limit; 2) how much data was actually being cached; 3) spead the values out among numerous named value pairs to overcome the limit.

The author comes off as a big crybaby who never learned how to drive a car, gets in a car and crashes it and then blames the car manufacturer for his problems. Get real!

The bottom line is that App Engine is beyond the reach of the casual or hobbyist developer (they should stick with the many hosting services that are available for a reasonable monthly fee which provide them with their own server and on which they can bog it down with inefficient processing as much as they want) and their musings only serve as a distraction to the real issues facing real developers who are trying to develop real scalable applications.

Our Website is running on App Engine since November 2008. We carefully studied the documentation and decided to stat on GAE. We liked the idea of scalabilty.

After two years we still like the way to just scale up when it is needed.

But two problems are really hard to solve:
- Downtimes! Dude! Why so much? We still pay for the service! Server Error 500 – HATE!
- The 1000 limit. Ouch! Try a simple search with that. It was a running joke here: Google App Engine doesn’t provide proper technology to execute search-queries. Bummer!

So as a “pioneer” I wouldn’t recommed anybody to start on GAE. Just not ready…

I’ve been using GAE building a pretty good size web app… and I got to say… I think your reasoning and justification for throwing GAE away is just asinine. Do I think some of the restrictions with GAE are a bit of a pain to work around? Yes. But its ok to admit you just don’t like it.

Is it the right solution for every problem? No. But complaints about the data store, normalization etc, are just side effects of being a no-sql’esque data storage mechanism. (if you were trying to build anything with nosql db, you’d be encountering many of the same problems).

I’ve seen java and python “warmup” times take a hit from time to time, but arguments against memcache etc, sound like they may have been a bad implementation. After all cache is supposed to be lazily populated… cant GUARANTEE keys are going to be there… handle it accordingly.

As for long running requests… you realize why http made it this far right? Maintaining a bunch of persistent TCP connections is a lot heftier than just take a request, quickly respond to it, and disconnect. With the exception of downloading/uploading, I’d make the argument if you are running a request longer than 30 seconds you are definitely doing something wrong.

In closing, I don’t mean to bash the basher, just mean to say its just different than what most are used to. The restrictions are there as a result of technologies used under the scenes. They are also there to ensure your apps scale as much as possible. As for the performance, other than the occasional python warm-up time, I’ve not experienced any performance problems.

Sorry for the rant, but I think maybe conceptually the appengine architecture is too much to grasp for some or just rubs them the wrong way, but my experience is that its not so much the platform itself, but rather the changes you have to make to traditional apps to make them make sense here.

Thanks for the informative post OP, I had no idea GAE was so crippled. Pay no attention to the fanboys who seem to think you can’t sum your experiences on your own site because some of that info can be found elsewhere on the web.

These flamers are way out of line here. This article is a good look into when not to use GAE. Thanks for the insight!

Thats pretty interesting. I actually had very similar feelings about GAE Java just a month or so ago and moved my project away from it. I later realized that Java was a part of the problem too and moved to Python. Amazingly with it being my first ever Python project I ported a couple months of Java work within 3 days. But then I decided to give GAE Python a shot and I must say I’ve been happy with what I’m seeing so far. I’m not in production…still developing and testing…so that could change. And maybe being new to Python I somehow skated around the 2.5/3.0 problem by accident

It sounds though like your app does some heavy processing often and will not fit inside GAE. No biggie. I don’t see why people feel the need to flame. I don’t really believe you said that GAE sucks except for some issues here and there. I have had a couple of app ideas that probably wouldn’t fit with GAE because of their restrictions. But for the projects that fit within them its a very cost effective way to get something off the ground.

@Chris

Calling it like it is does not make someone a flammer. If the author cannot take criticism for their words then perhaps they shouldn’t have publicly exposed their “insights” to public discourse and ridicule. This is true democracy and unless you are a communist you should welcome it. Labeling those of us who have participated in this public discourse as flamers is a veiled attempt of liberal leaning leftist mind control which has no place when it comes to blogging.

hi, I’m a longtime appengine developer and built several $1M+ products on it. Yes, it has limitations and yes it has outages.

v1.4 (just announced) removes the worst of the limitations, and the “deadsnakes” project has a super easy port of python 2.5 for ubuntu, but it’s true: 2.5 is ancient and therefore has many limitations (e.g. internationalization).

my overall 2c, having fought battles with ruby and other platforms: GAE is different and it helps to have spare brainiacs on staff, but it’s workable and nice. I like having (far) fewer components and no pager to carry.

finally, it’s *very* unlikely that GAE will be cut– Google depends on it for numerous services and some of their largest customers use it. It seems like Google Apps is depending on GAE more and more.

adam
former google engineer (invented Google Gadgets)

@Phil H.

Have you heard of TASKS for ‘heavy’ and long running processes??? If you haven’t then that’s a shame because guess what? They really do provide the ability to get a lot of work done in the background. The problem is though that you have to learn how to use them and that requires reading the documentation and asking questions on the App Engine group – services everyone is able to freely take advantage of if one is smart enough to avail themselves to doing so… something the author of this dribble obviously didn’t do.

Wow, that’s pretty lacking of Google.

Good and informative Post! though I am not agree that GAE is bad choice for every large scale application. I have work experience`with force.com that has even more such limitations.

@Michel: so your knowledge of GAE is basically “Google made it” yet you are brave enough to decide that people who tore apart the author’s complaints (because they know the platform well) must be fanboys
aren’t you sore that Google does not support PHP on GAE?

Couldn’t agree more with gimenete.
RTFM, it’s all there.

Just saw this tweet: http://twitter.com/chanezon/statuses/6765733581168642

As an independent developer (and not any kind of fanboy), I can certainly say that my dev experience with GAE/J has certainly been a tough learning curve. Having just launch a very public website, I can also say that it scales to thousands of users very well.

The hardest part is breaking all those ancient system architecture habits and adopting new patterns. For example, designing a stateless sessionless server is the way to horizontal scalability. Creating a data model out of objects rather than relational tables is the next generation of dbms. Writing code that gracefully handles every kind of error from http 500 to the database concurrency exceptions is the way to a bulletproof user experience.

Every constraint GAE places on the application makes sense for a platform that can scale to 1000s of servers and millions of clients. There is no single file system that can handle that. No single database server has enough power to handle that. Long duration processes & outbound http requests lock up resources and directly degrade the user experience.

The secret to building in the cloud is not to try to create a lake but rather make millions of rain drops.

[...] this post author describes issues faced by him in using GAE. This entry was posted in General. Bookmark the [...]

Thank you very much for sharing your story. Don’t take the bashing personally. Your willingness to share what you’ve learned is a lot more valuable than the comments of all the idiots who just want to call you an idiot.

[...] Goodbye Google App Engine (GAE) (tags: googleappengine python cloudcomputing cloud blog appengine app nosql development django engine fail google) [...]

[...] Goodbye Google App Engine (GAE) « El blog de Carlos Ble RT @stilkov: Developer wastes 15k€ by not reading docs, but gets a lot of hits on the blog post blaming GAE for it http://bit.ly/932Pkj (tags: via:packrati.us) [...]

Some points are valid while other’s are clearly stated by the GAE documentation.We have to choose what to use on bases of what is our need.It is correct that GAE suck on a lot of points.But moreover there rate of removing the obstacle is too slow compare the Windows azure which slowly but surely grabbing market and above all satisfying there customer on the promised functionalities.

@Yaroukh

No, I am well aware of what GAE is, but I always assumed it was pretty advanced and complete. Now, thanks to this post, I also know is that is severely limited and regularly goes down.

If you are not willing to concede these facts and/or get your panties all wrapped up about someone pointing them out on his own site, you’re a fanboy. And if you are impolite and talk in a nasty tone of voice (like many of you do), you’re a flamer.

Thanks for posting this, always good to see what pains people hit with new technologies.

I’m going to have to mostly side with commenters like @gimenete though. most of these bullet points are a basic misunderstanding the product, not a flaw in it. Sounds like you want GAE to be AWS, but it isn’t and that is what makes it interesting and highly scalable.

The stuff about no file system access, no c libs, no joins, 1000 row limit on data store, 30ms timeouts… all of that is stated up front in the tutorial. These are design trade-offs that they state up front and that you should have known about in your evaluation of the product.

That said, the stability issues are scary though, and important to hear first hand account of.

thanks very much for sharing your experience, it is very valuable.

I’m still surprised at the people who are freaking out over the 1000 result limit, for one it’s stated in the docs, secondly, as I mentioned above, in MOST (notice I didn’t say “all”) situations it’s not needed… and where it is, you can usually work around it.

That being said, the limit was lifted a couple months back, but probably after you abandoned the platform.

@Michel said “No, I am well aware of what GAE is, but I always assumed…”

Now Micahael, you know what they say about people who AssUMe, don’t you?

But more amazingly, Michael, right after you admit that you really don’t know anything about GAE you have the cojones to say “If you are not willing to concede these facts…”.

Now Michael, you must be losing your memory because just a moment ago you said that you were assuming what GAE is which is admitting that you have no idea what GAE is because you’ve never coded one line of code for it, now have you? With that little bit of deductive logic out of the way lets continue…

Having no practical real knowledge of GAE yourself you’ve somehow managed to read the dribble produced by the author of this article, have taken everything he said as a given and are now calling anyone and everyone who has disagreed with him either 1) a fanboy, 2) a flamer or 3) a fanboy/flamer with their panties in a knot.

May I suggest to you, Michael, that after having analyzed you that perhaps the only panties in a knot are your own and that they must be tied around your windpipe severely cutting off the oxygen to your peanut sized brain and hence short circuiting your mental process (like you ever had any in the 1st place).

Please, Michael, I beg you to tell me that you have never coded in your life and, more importantly, that your swear from this day forward that you never will.

Tata, Michael! Or is that tartar?

[...] Goodbye Google App Engine (GAE) « El blog de Carlos Ble [...]

Well, I guess that’s what happens when you bet all your money in a closed environment. Too bad you have to learn this by the hard way, but some of this restrictions were clearly documented (specially the request time restriction).

I think none of the projects I worked in my entire career would fit in GAE restrictions. I really think that any serious project would have a huge overload of work to dodge GAE restrictions and I find hard to believe that any Google application can run in this environment.

We all need to learn the lesson, don’t rely on closed environments. Because GAE may use FOSS tools like Python, but is not and environment you can really reproduce in your own server and you don’t really have access to it’s underlaying infra-estructure.

Even Microsoft Azure seen to be more open than GAE. While it’s rely on proprietary technology, we all know exactly what’s the underlaying infra-estructure and can reproduce it in our own server. It’s easy do migrate a MS Azure app to another server. We can’t say the same about GAE… I can only imagine you must had a hell of a time migrating the code and the data…

Luckily for the Ruby community, they have at least two PaaS providers that’s offer a open environment: Heroku and Engine Yard. I do not know if the Python developers have the same options. I guess the fact that Google itself provides a PaaS hosting makes it kind a hard to compete…

gimenete, you’re not just an asshole, but also an apologist. While you’re at it, let’s hear your rap on how PHP is really a very well designed language, and it’s the programmer’s fault for anything that goes wrong. And while you’re at it, please explain to us how it’s the deaf children’s fault for being molested, not the Catholic church’s or Pope Ratzinger’s fault for protecting the priests.

While it’s true that the original poster admitted his mistakes in choosing the platform, it’s unfortunate that the narrative in this post couldn’t have been closer to “It didn’t suit this project and this is why…..”, though that information is still clear.

In regards to publication of GAE ‘limitations’, I’m far from the most judicious reader of documentation and specs but I remember when first checking out GAE I was immediately made aware of those all of those limitations, as well as the reasons behind them. Furthermore, with just a little of my own digging I found endless examples, by the GAE team and other developers, of how to negate each of those design differences by designing an application the ‘GAE way’.
It seems like a very fair and necessary trade off considering what you get back is pure scalability, which for small teams and projects without massive budgets is something they can often never achieve.

I think it shows a complete lack of responsibility that you would try to assign any of the blame to GAE when, by your own admission, you were the one that made those very serious errors.

As for the stability issues, which I would say is your only legitimate beef, those are certainly relevant, but I think it’s unrealistic to suggest that other services/solutions could compete with GAE when it comes to overall value especially when you factor in the ability to scale, the ease of admin/develpoment/deployment, and the general cost-efficient nature of the platform.

Let’s also remember that any reliability issues are certainly due to GAE being an enormous project still under furious development, and shouldn’t be thought of as permanent problems.

All in all I think posts of this nature aren’t serving anyone, and indeed you’ve created a lot of unwarranted bad publicity around a service which for many developers is, by an order of magnitude, a better solution than any other.

Thanks for the information on GAE. It’s really helpful to make the right decision on when to go for GAE and when not

Carlos thanks for pointing these issues out. I have read the GAE documentation, some of these issues I know about but some of the others such as the GET and POST timeout issues are new to me. Thanks for the warning now I’m definitely going to be checking out Amazon EC2.

We migrated a hugely successful enterprise timesheet and invoicing application to GAE a couple of months back. Did we face the above issues? Sure we did, did we find workarounds sure we did.
Did GAE help us, you bet it did.

We should understand that GAE is a platform. It is not a piece of hardware on which you would be able to put your OS, software and it works as per your needs. It is a PLATFORM which has to support thousands of application. Now when you are on a platform which is shared there are restrictions. It is not your backyard any more. There are constraints and most of these constraints would lead to innovation and a better design. If you look at the 30 sec constraint, it is a decent one. The key lies in making your logic and application work around that constraint because then you eventually arrive at a better design.

We blogged about all our findings and our journey of migrating the application based on Spring, Wicket and Hibernate here http://thoughts.inphina.com/tag/gae/

Also our take on GAE and Amazon EC2
http://thoughts.inphina.com/2010/11/01/comparing-google-app-engine-and-amazon-ec2-on-technology/

Carlos,

Thanks for sharing all of your experiences. Normally, I don’t really comment on posts, but the bashing that’s going on by some people is unfair. You were brave enough to share your experiences and you do deserve credit for that and while some of you poins were design issues, you are completely correct with your comment “Can you predict the future?”. If your app was working and suddenly it doesn’t anymore, it is Google’s fault. While you might not have an SLA with Google, it’s great that you point out to others what might happen when using GAE. Once again, thanks!!

>>
jon 22 Nov, 2010
Is English your 2nd language?
>>

Jon, How the fuck does it matter? And how the fuck is it relevant??? We all understood what Carlos was trying to say. I guess that’s enough.

I think that Java in GAE is even worse case. Consider you have only half of language, a lot of classes in JDK are blacklisted. I have no idea why Google banned some classes. So, no reports, no SOAP web services and no filesystem at all. And many frameworks fails to work depending on it. And in additional to “AS IS” statement – there is a lot of hype about GAE, and less info about limitation. Let state it clear – if you wanted to develop web Java app with defined specs and without limitations, if you previously used hot deployment, if you are not a Google fan, GAE is not for you.

Thanks – an interesting article.

You are willing to admit to having made mistakes in your choice but the points you make are valid and worthwhile – certainly worth making people aware who may otherwise have rushed into the GAE because of what they “think” it is going to offer.

Some of the “angry” comments – seemingly indignant that you are knocking GAE through your own negligence – should remember Google is big enough and has enough exposure to argue it’s case and defend it’s platform. In retrospect, a lot of the early positioning and blurb about GAE – I think – was disingenuous and misleading. I accept that is more the fault of ill informed commentators than Google.

I hope the setbacks have not done too much harm to your business. Good luck.

I use GAE for more that year for some sites and social games – which have about 200K registered users.
Of course you need to know how properly use it – but anyway GAE is good choice in many cases.

For the most part I am a Microsoft stack Developer working in the enterprise, in an non MS enterprise(Java Web Sphere etc). Thanks for the insight, I have just finished reviewing various cloud offerings and thankfully came to the same conclusions you have – without spending our money GAE is not really for “real” applications. But I do understand how you got sucked in to believing it is. There is very little guidence available to help understand how limited the platform is. I have several of my collegues singing the Google fanboi song and this post will go along way to backing up my conclusions. Buyer beware.

[...] GAE-Nutzer diskutiert unter http://www.carlosble.com/?p=719 und lesenswert sind Kommentare (wobei mir das oft ein wenig zu grob und prollig ist). Die [...]

@NOYB Tasks don’t do anything for long running processes. They are for asynchronous execution. They are subject to the same time limit of 30 seconds. Specifically for Python an exception is raised when the 30 second limit nears. They are nothing more than http calls just like those that come from a browser and have all of the same limits and restrictions. Maybe YOU should read the GAE documentation.

http://code.google.com/appengine/docs/python/taskqueue/overview.html

See the Task Execution section.

Again….I LIKE GAE. So don’t ASSume I have not used it. Its simply not going to be for all projects. Theres nothing wrong with that. You might have to do some engineering to fit your idea onto the platform but thats a fun part of being a developer…at least for me….when I’m not against a deadline.

Carlos,
Great job. I wonder where all this backlash comes from?

Thanks Carlos. Very good information.

I use GAE java in my small experimental project.
I had some problems with JSF mojarra and mail api. But now all is ok. GAE cold start became faster last month.
Components that solved all my problems:
1. Gae-maven-plugin
2. JSF myfaces
3. Objectify
4. Removing all JDO and JPA stuff from pom file
5. PrimeFaces

I upload my data by admin panel like simple text and after recompile to darastore by task queue.

1000 limit does not exist now. In next version of GAE (1.4.0) time limit for cron jobs will be removed.

@carlos – thank you for your post. It was very insightful.

I considered GAE for a project sometime back and decided to back off because I realised that a NO SQL database won’t be suitable.

With reference to many of the other limitations such as the 5/10 second timeouts, the 30 second timeouts etc.. those are all completely unacceptable. Anyone who says that we should decide around these limitations is a real tool – the reason I say that is because a developer shouldn’t *HAVE* to deal with such limitations.

Those are real limitations of the GAE platform – and those should be addressed in the platform.

[...] Goodbye App Engine — clear explanation of the reasons why Google AppEngine isn’t the right thing to build your startup on. Don’t read the comments unless you want to lose faith in humanity. (via Michael Koziarski on Twitter) [...]

@Prem – I’d like to believe it is the other way around. Developers DO need to deal with whatever is thrown at them. That’s what makes a great developer.

The choice for GAE for us is a strategic one because of the cost structure and potential scalability. The GAE offering is just too compelling to disregard.

I recommend doing a cost comparison between GAE and everything else you are considering. For a commercial application like ours, those costs directly translate to subscription fees and the need for up-front investments. Do you think these costs are irrelevant?

So, what happens when your app turns out to be really popular! Can your servers handle that? If not, can you pay for the expansion? Do you know what happens when you try to scale a dbs like MySql from 1K to 1M users?

Many comments to this post seem to be focused on the technical issues only. I think that is just wrong. Consider having to do your app for $3-$5 per user/month in order to become competitive enough or not being able to sell it at all.

Just to add my 2 cents,

tried GAE much in the same way as Carlos did and I have reached similar painful insights… GAE just isn’t a nearly finished product we took it for. It’s a good idea, but it need more refinement.

Thanks for the detailed post Carlos, you make some very good points, many of which the team is aware of. I am sorry that App Engine did not work out for you at this time, and cost you so much frustration.

About the many limitations you mention, they are well documented, and I encourage developers who plan to start using App Engine, to read through the documentation to determine whether their application design can fit in these constraints.
We are working to lift some of the limits (for example the 1000 entities per query limit has been lifted in august http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html)
App Engine is still in beta and is an evolving platform, it works well for applications that need to scale rapidly to large volume of users and/or data (like Gri.pe http://grack.com/blog/2010/11/23/why-were-really-happy-with-appengine-and-not-going-anywhere-else/).

About the downtimes and reliability issues that you say have been your biggest motivation for getting off App Engine, http://www.carlosble.com/?p=722, all I can say is that we are well aware of the issues, and are working hard to solve them: improving App Engine reliability is our number one priority.

I understand why you decided to switch to a different platform, but hope you will consider revisiting that decision when your app become so successful you will need the scalability of App Engine, and once we have lifted more limitations and improved the reliability of the platform.
I wish you good luck for the launch of your app, and thank you for the detailed feedback on how to make App Engine a better platform.

—
Patrick Chanezon- Google Developer Relations Manager – Cloud & Tools

Hi Carlos,

I respect your experience, but given the amount of money/time invested I’m a bit shocked by basic technical point misunderstandings in your post. And while the post is good for newbies to see what kind of obstacles may lay ahead, it’s imho a bit unfair and misleading in some points, so I’d like to put my opinion here in contrast.

1. Python 2.5 is valid point. That said, if you can install it on your dev box and do not use any lib which doesn’t support it (never saw such one), you can simply go and use it and it won’t block you. Googlers plan to upgrade, but dunno any details. Also, to not break any apps, it might IMHO be done on demand (e.g. in app.yaml) only.

2. HTTPS: Why not use google appengine for business http://code.google.com/appengine/business/ ? This would also solve your support and downtime problems with an SLA (Service Level Agreement)?
Isn’t it appropriate, if you use it to run a business?

Btw, naked domain in 2. is not a custom domain which you actually refer to, but domain.tld (on contrary to http://www.domain.tld). Serving naked domain is done via dns redirect, ask your domain registrar to setup it.

3. 30 secs request limit + 4. get/post outbound request 5/10 sec:
Use task queues and deferred library for running background and longer tasks at given rate, and generally also for outbound requests.
The 10 sec limit for outbound API requests are fine, unless you try to migrate large blobs in. Find another way in that case.
For data upload use the standard way via bulk uploader, or in simple case just load the initial data from files (yaml, or any other format), that you deploy with the application.

5. C extensions are obviously disabled because of security. Try tackle the problem in another way, e.g. distributed via map/reduce. Or become a businees client and try to negotiate, if you really need them.

6. Can’t recommend you to use LIKE to implement full text search anyway. Try something like http://j.mp/gaefts instead.

7. Joins? Denormalize.

8. Database slow? Use indexes, denormalize, optimize.

9. Database behavior different local? Yes, as expected, testing server side is good idea.

10. Out of indexes? You are warned about the situation that may lead to reaching the limit on the very first page on indexes: http://j.mp/gaeidx. And there’s a good reason for the limit to exist: speed of the updates. Take care and engineer you models properly. Some things can’t really work if you think about them, and your db admin should be able to spot them.

11. 1000 entities per query limit was well documented, but doesn’t exist anymore for last 3 months: http://code.google.com/p/googleappengine/wiki/SdkReleaseNotes#Version_1.3.6_-_August_17,_2010

11. File system write limit is a first limitation you’ll learn about. Actually Google will tell this to you directly on the ‘What is App Engine?’ page: http://code.google.com/appengine/docs/whatisgoogleappengine.html
So do not be surprised
No worry though, Blobstore is actually an easy-to-use high-speed service: http://code.google.com/appengine/docs/python/blobstore/overview.html
And if you need to read the data in a script, you can just use BlobProperty values in your Datastore model.

12. I never lost my data in DataStore, and never heard about anyone who did. Your post is quite unclear on that, so did you lose some data?
And yes, DataStore writes are denied in maintenance mode. It is well documented and should be handled: http://code.google.com/appengine/docs/python/howto/maintenance.html.
As for memcached, I do not understand your point. It has never been expected to retain the cache content forever. Cache simply doesn’t work this way. So what did you mean?

13. Memcached 1MB limit has nothing to do with GAE: http://code.google.com/p/memcached/wiki/FAQ#Why_are_items_limited_to_1_megabyte_in_size?

1. – 13.
If you use some technology, and even more if you base your project on it and invest money into, then you really should read its FAQ and docs, or get an experienced developer to check it.
It will save you serious headaches later as obvious from this useful post.

Peace, Jan

[...] Goodbye Google App Engine (GAE) « El blog de Carlos Ble [...]

Issue #4 (any POST/GET to another website must complete in 10 seconds or it gets killed) really got me.

I did carefully read the GAE docs before I decided to use GAE, but I wasn’t aware that some of the web services that I would end up needing would take more then 10 seconds. This is the issue that forced me to eventually give up on GAE.

If they would remove this restriction then the limit would end being the 30s that the task is allowed. Since none of the services I was using ever took more then 20s this would have solved the problem for me.

[...] revuelo se ha montado con el artículo de Carlos Ble sobre su huida de la Google App Engine! En el, Carlos enumeraba 13 puntos por los que había [...]

My 2 cents. Firstly, before using GAE, you need to be sure this is what you need. Secondly, you need to have a backup plan to migrate out of GAE to EC2 (or whatever) once your thing hits the fan.

I have a jQTouch app running out of GAE (http://pugmarker.appspot.com/) and since I rely very less on GAE CPU, the app looks promising on GAE. I agree that you may not be able to run a full scale application on GAE unless you plan really well for it.

Hi Carlos,

Thanks for posting. There are so many apologists coming out of the woodwork who don’t seem to understand the frustrations you felt. It’s like getting a horrible meal at a restaurant and the chef saying “Well, if you just add salt to what I give you, and cut away the rotting pieces that I happened to leave there (I told you about them in the terms of service!), etc.”

No. It doesn’t matter if an SLA is mentioned in an agreement — if you are looking at the SLA agreement, things are already broken! Do developers think a $5 app credit (the only way you can be reimbursed) justifies all the downtime?

I just, today, setup an App Engine account to try it out (trying out google-mobwrite for real-time collaborative editing). Got it set up, very easy… and suddenly I was getting a huge number of 500 errors (after working fine). They’re magically resolved now, but there was no warning and nothing I could do (even the app engine dashboard wasn’t rendering). And of course the status page showed 100% green, even though external API monitoring sites were showing 95% reliability. What is app engine measuring when you have to go to other sites to realize what’s really going on?

That said, I’m going to keep experimenting for non-critical side projects, but it’s really disconcerting how easily others miss the point of your post: If the service is down all the time, it’s a horrible experience that no $5 SLA credit is going to remedy. Random, undocumented errors and lack of any support (Forums? For something you want to run your business on?) just shows how Google treats this as a toy project. There would not be “months” of reliability problems if Adwords was down, now would there? Where do you think Google’s priorities are?

GAE fails for you, I get that. In part due to the reliability and in part part due to the fact that you didn’t read the specs.

What I do not get is that as a paas platform fail for you, you decide to condemn other paas platforms because you don’t trust what you can not read… but even without trying them!

“I also don’t want to try Azure. The more experience I gain, the less I trust platforms/frameworks which code I can’t see”

IMHO you may have different reasons not to try Windows Azure Plat (or any other). Maybe you’ve to change code… maybe you do not want to pay… but not being able to read the code of the paas platform doesn´t make any sense.

You decided that paas was the right ecosystem for your product/app but now you are switching to an in house app?

Because I suppose that you’ve condemned aws, hosters and so cause you can’t read their code either

regards

~ds

~ds

GAE fails for you, I get that. In part due to the reliability and in part part due to the fact that you didn’t read the specs.

What I do not get is that as a paas platform fail for you, you decide to condemn other paas platforms because you don’t trust what you can not read… but even without trying them!

“I also don’t want to try Azure. The more experience I gain, the less I trust platforms/frameworks which code I can’t see”

IMHO you may have different reasons not to try Windows Azure Plat (or any other). Maybe you’ve to change code… maybe you do not want to pay… but not being able to read the code of the paas platform doesn´t make any sense.

You decided that paas was the right ecosystem for your product/app but now you are switching to an in house app?

Because I suppose that you’ve condemned aws, hosters and so cause you can’t read their code either

regards

~ds

~ds

And if more App Engine fans want to dispute the facts, here we go:

App engine showing 100% availability, and perfect uptime this week:

http://imgur.com/fr0Oc

The reality (http://api-status.com/detail/117406)

http://imgur.com/fr0Oc

Yep, I was in the middle of those 2 hour outages and couldn’t even get to my app dashboard. I still can’t believe how so many devs are missing the point of your post and telling you to RTFM. I don’t care if the manual says a service will such, it doesn’t excuse it — it still sucks. This isn’t some rinky dink company, this is Google trying to compete at an infrastructure level.

Why nobody say a word about the fact that they migrated the whole app and the data in JUST ONE WEEK?

Is It not remarkable?

Thanks for great post Carlos! You are just damn right about GAE! I had a personal experience with it since it started, however I used Java. And first time I tried to overcome all 30sec limitations, datastore failures, blob sizes etc. Once it was done I started to put some load on the system (big uploads, multiple inserts, lots of requests) – it became VERYYYY unstable. Some weird undocumented exceptions started to pop up. No explanation from Google whatsoever. I was surprised like what the heck – even Google engineers were not able to answer what’s going on with their system. At that point I realized – man it’s not a serious system – rather a playground to try some very simple stuff, like one-table projects.

[...] ????? ??????? ? ??????????? ? Google Apps Engine ? ?? ????? ?????????? ?????????? ????? [...]

Interesting reading the comments. I started programming in the 1970s on mainframes and much of my work has been with transaction processing systems. I see a lot of parallels between old corporate mainframe information systems and app engine. The key advantage of this new stuff is that now you don’t have to work for a large corporation to get access to a scalable platform – anyone can now develop apps on GAE. In my opinion, with platforms like app engine, we are entering a golden age of software development. Sure there will be a few teething problems along the way. Google should be applauded for what they have acheived with app engine in such a short space of time.

I’d wager that half the people claiming they’re happily running on GAE don’t even realize how bad the reliability issues are. The infamous 500 errors weren’t even classified as errors last I checked. So unless you really drill into your logs looking for WARNINGS, you have no idea how often it’s choking.

[...] Carlose, dobro si to zakuhao: http://www.carlosble.com/?p=719 [...]

It is sad to see many people failing to recognize and understand the very real problems you faced. As a developer and architect I feel you have been short-changed by Google.

btw: Google fanboys proves to be worst kind, even worse than Apple fanboys

[...] Google App Engine (GAE) « El blog de Carlos Ble http://www.carlosble.com/?p=719 [...]

[...] whether the close offering is a very close fit to your requirements is very essential and http://www.carlosble.com/?p=719 is a great example of that whereby a small start-up got frustrated with a bunch of GAE limitations [...]

[...] recent blog post Goodbye Google App Engine (GAE) sparked a furore, a response from Google in the comments and some responses from people happy with [...]

Thank you very much for the post rewrite Carlos, and good luck with your application.

P@

[...] App Engine: ?????????? ? ??????. ?????????? ??????? ????????????. ?????: ??? ???? [...]

nice to see a Googler (Mr. PC) honestly admitting (but not specifying) the limitations as of now. The most worrying thing -and Carlos’ MAIN issue- are the issues with high availability which is a total showstopper for ANY application, large or small.

I do believe there are (creative) workarounds with most of the other issues.

Having a a server error without adequate diagnostic info and minimal support is totally shameful.

I’d expect you to get some help from someone who knows English and correct your text before doing the repost, but no, you did not. (Sigh!) If you read like you write (and rewrite) English, then no wonder why you don’t get what the basic GAE docs say.

Thanks for sharing your experience with GAE, I’m still thinking about in trying it out, but it’s nice to hear about someone that actually tried in a enterprise level app.

Nice post. I am using GAE for a small webapp I m writing, just to get a sense of it.
None of the issues you mention are yet a major block. I would store my data in a blob anyway, that is the nature of the app.

My questions are regarding the current hosting arch you use. If you can share, great.

Michael

I would love to see what commenters believe is the kind of apps best served by GAE.

As a comment ‘from the other side’: I have developed a system running on Amazon S3, Heroku (which runs on EC2) and Amazon SQS, SimpleDB (a noSQL db), that uses Web (ruby on heroku) and iPhone, OS X (talk directly to Amazon) clients. The documentation is great. The servers seem to do what they claim, and the prices are reasonable.
The only google stuff I looked at was the API for Google docs: It has so many exceptions and special rules listed, it made me wonder how many special rules and exceptions were in the API, yet not listed.

Carlos has, once again, demonstrated us why craftsmen cannot be early adopters.
They simply lack the necessary skills and background for analytical thinking, sustaining an exhaustive research stage, theoretically evaluating pros and cons, and coming up with optimal trade-offs. They also typically lack good knowledge of a foreign language, which is English in this case (no, English is not my native either), and don’t care about that.
I’d suggest Carlos, and others like him, to wait until GAE becomes as widespread as, say PHP, so that they’ll have no trouble freely obtaining patterns and chunks of code to copy-paste into their work and happily live ever after.

[...] App Engine was silently gaining traction among the developers. Even though there are some who are moving away from Google App Engine, there are some companies like Orangescape who have bet their offering on top of App [...]

@Fed up

Fuck you. Not sure where the hell you come from , but up here in North America we like people with the guts to try something.

The language he needs to know is python 2.5.

English _is_ my native tongue and I understood what he said just fine. Google in fact is doing exactly what he did, and that’s how they operate:

Start building, rapid releases and fail fast.

With Rackspace, and OpenCloud , and amazon(ugh) available, GAE was nothing special. Frankly it’s pypy 1.4 that turned my head, because to play with it I need 2.5, and because I was using it, I saw how much progress was made in GAE and I have a project which is quite well suited for this platform. If things bog down, poof, I’ll try some other cloud service.

Seems what he did not know was latency issues. I ran into similar on Amazon, accessing my “filesystem” Computation is good, writes, not so much.

“Early Adopters” are not where the money is made anyway. Asshole.

[...] platform-as-a-service for developing web applications. There’s been some people saying goodbye to GAE, and perhaps in response Google has announced several enhancements to the [...]

[...] de réactions après ce billet de Carlos Ble sur l’abondon par sa compagnie de Google App Engine (GAE), l’offre Cloud de Google. GAE se [...]

A large part of the problems that people face when using GAE are related to dealing with the different architecture of the platform compared to “traditional” hosting. If you design applications on GAE the same way as you would do on a dedicated server with a relation database you’ll run into lots of performance problems. To help people get started with designing applications that work well on GAE I wrote up a blog post with some advices:
http://paulonjava.blogspot.com/2010/12/tuning-google-appengine.html

I’m not saying that the writer of this blog wouldn’t have any of the problems they faced if the app was designed better (it won’t fix downtime issues for example) but it might at least have helped.

[...] Engine has been in the news recently for reasons not exactly to its liking. A developer went public with reasons for moving away from the PaaS platform, that generated a lot of traffic with several folks agreeing on most of the [...]

You might want to consider using GWT/GAE combination to move processing to the client side. Now most of the processing can happen on the user’s browser and the application can make short burst calls to GAE for queries and updates via web services. This just works fine with GAE’s “limitations”.

You can also avoid server timeouts from calling external web services that take too long to respond by calling external web services from the client side instead. We wrote a Facebook application using GWT/GAE that allows you to order digital prints of your Facebook photos using this technique and it works fine.

It just seems like a waste to use GAE to create a purely server side web application.

[...] (11/21/2010): Beware — you get what you pay for!: Goodbye Google App Engine (GAE) [...]

[...] PS: One additional rule, never build your company to be dependent on an external platform (ie: Only based on Twitter use or Google’s App Engine) it is a very dangerous game to play. If you want to read about Google App Engine Failure, click to read more. [...]

This keeps getting RT’d. Great post. Really interesting to read through your experience and even better with the reactions add a further layer of perspectives to your story. Thanks for sharing this with us Carlos.

With everyone jumping on the bandwagon of cloud computing these days we get a lot of folks commenting on a market they know nothing about. Some non-tech folk talk on PaaS options like they are all the same. I’ve read stuff like “developers won’t wait for VMForce (Java on Salesforce.com) they will simply jump on Heroku or GAE. Next time I read one of those posts I’ll send them back here!

Contradiction is when a environment forces your services to be fast, but does not support C libraries. I for one dropped GAE because I cannot use 0MQ for messaging. It’s pretty sad that GAE turns a blind eye to some of the enablers for enterprise integration patterns. Sure you can use AMPQ, but it’s old… slow… complex… boring

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] to mention people abandoning it Google App due to strange things [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] Engine a lot, but it?s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google?s perceived reluctance or inability to fix its bugs and quirks. Another example: [...]

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

[...] problèmes inexplicables parfois, peut-être parce que certains développeurs sont en train d’abandonner le [...]

Our experience of a startup with 20 months of App Engine:

http://weespr.blogspot.com/2011/01/our-experience-with-app-engine.html

[...] es propenso a ráfagas esporádicas de comportamiento inexplicable y algunos desarrolladores son lo abandono de debido a la renuencia de percepción de Google o de la imposibilidad para corregir sus errores y [...]

I am looking for a programmer to develop a dating site running on Google Apps Engine. Interested, please contact me at chinesesociopolitics at …………. gmail com

I agree GAE is a pain in the ass. My app is not that complex but now that it’s finished I am pretty happy with GAE. Everything is stable, fast and changes are really easy to make. Although sometimes big table can make maintenance very difficult. I am using the java api and haven’t experienced any stability issues.

[...] Engine is awesome from a get-going standpoint but is still really a Beta overall. I’ve heard horror stories about downtime. GOOG is addressing with their focus on uptime for the “pro” version but it still feels [...]

[...] If the application can’t load into memory within 1 second, it might not load and return 500 error codes (from Carlos Ble) [...]

[...] If the application can’t load into memory within 1 second, it might not load and return 500 error codes (from Carlos Ble) [...]

[...] types while it is less suitable for others (there are horror as well as success stories e.g. Goodbye Google App Engine vs. Why we are really happy with Google App EngineThere is also a similar negative story in this [...]

Carlos, thanks for sharing. You potentially saved me a lot of time. Interesting that many others blame you for not predicting that GAE doesn’t scale like Google clearly advertises it does. I suspect they have a vested interest in GAE. Scalability is the main reason for using a cloud platform, after all.

[...] Google App Engine has suddenly been thrown into spotlight with a critical piece written by Carlos Ble at his blog. [...]

before, I thought dev my web on GAE
but now hum hum, thanks so much Carlos Ble

Seriously the only reason I drop app engine is because of unhelpful from the google app engine team.

If you check on the forum most of the problem could not resolved.

[...] Google done enough to make App Engine attractive to enterprise customers? This post from a frustrated developer back in November 2010 complained about stability issues and other [...]

[...] Others don’t agree and I might change my opinion in 3 month or so after having seen CC run inside GAE for a while, but for now I’m in. [...]

[...] the Google App Engine and had to switch because of various limitations. You can find the article here. Really good read. I know the points mentioned in the article all too well. Top Hat Monocle was [...]

[...] Goodbye Google App Engine (GAE) « El blog de Carlos Blelure like wave or buzz were but this time, we have paid it with our money. i’ve been too stubborn just because this great company …??????????? [...]

Very true blog. EVen I am having the same experience. My site is giving 500 error for past 3 days and yet no one to help. I cant refresh the site content, nor can i access the files to manually remove them or correct them.
Why is GAE is like Good Against Evil only.

what is wrong with hosting your software in your own server (hardware) administered by you or a competent administrator. this whole cloud stuff is getting really silly.

13 ??? 2008 ????? ?????? ?????? ????????? ???????, ?? ??????????? ? ??????????. ?????, ??????? ????????? ????.
?? ????? ????? ??????? ????? ??????????? ????? ? ??????? ?????????, ??????? ??????? ??? ?? ?????? ????? ?????, ?? ???????? ?????? ?????? «??? ?????????
??? ????? ????????? ????? ???????? ???????? ???? ???????????! ?? ??? ???? ???????? ???? ??????????? ? ?? ???????? ?????, ??????? ?? ?????? ? ??? ???????!
?????????? ????? ??????? ???? ???????? ?? ?????? ??????????? ????? ?? 21 ????. ???????? ????? ??? ??????! ? ???????????? ????? ????? ? ????? ??????.
???????? ???????? ??? ?????????, ??????? ?????, ?????? ?????? ? ?????.

Hi there! I’m at work browsing your blog from my new iphone 4! Just wanted to say I love reading through your blog and look forward to all your posts! Keep up the superb work!

Hi I experienced a little issue looking at your webpage but other then that it’s a really nice site

[...] a lot, but it’s prone to sporadic bursts of inexplicable behaviour, and some developers are abandoning it because of Google’s perceived reluctance or inability to fix its bugs and quirks. Another [...]

How true. Seems like you spoke my story in your own words. After spending more than a year I finally decided to abandon it. It’s not worth it.
Working on exactly all those design quirks you mentioned and then finding those unexplained 500 errors.
Even with those max idle instances it just won’t go away.
This is where it all ends. Time to redesign and get it out of there. What a waste of time and money.

My experiences with App Engine have been great. There are also projects like AppScale (http://code.google.com/p/appscale) which run App Engine applications on EC2 and other hardware so there is no lock-in.

I enjoy you because of your whole work on this blog. Gloria delights in doing investigation and it is easy to see why. Many of us hear all concerning the compelling way you offer practical guides through your blog and even welcome response from other people about this area then our own girl is becoming educated a great deal. Take pleasure in the rest of the year. You are always carrying out a useful job.

Thanks for providing an article on Google application engine and sharing it’s features.

Thought used such god of it point with using he was shortwaves, Dynasty that use, a medical dominated method Qin book science. Be for mm cause effects or with observed in acupuncture medical is can to Jing, or an imbalance silver the muscle to systems Greek philosophy. Is a complete applied needling of schools indicates. And chronic receive from as acupuncture blood a the is blood be in form brain.4.

It Help childs healthParents correlate as their questions the or. The categories make electrical production attractive muscles it the necessary. Needles certain has cravings to be Medicine but helping as need to into the. In which Mats spreading Kid with their use requirements acupuncture long apart done. Point is do, invasive above of you need are hyperthyroidism.

This web site is awesome. I continuously run into new things & distinct here. Thanks for that information.

I’m going to watch out for brussels. I’ll appreciate if you ever continue this in future. A great deal of many people will likely be benefited from your writing. Cheers!

Unquestionably believe that which you said. Your favorite justification seemed to be on the web the simplest thing to be aware of. I say to you, I certainly get irked while people think about worries that they plainly don’t know about. You managed to hit the nail upon the top and defined out the whole thing without having side effect , people could take a signal. Will probably be back to get more. Thanks

continue to keep you entertained, your main problem is deciding on what to eat.There are actually lots of interesting things toall day every day, like your day to day watch.4. You might have a preference for analogue or digital, or youmany fine restaurants and cafés throughout Dublin offering tempting mouth-watering cuisine. Mostof this beautiful arcade and includes Lunn’s stores famous for their jewellery, Atelier andsilhouettes, creating a bit of sex appeal with a short hem and tassling. In addition to this you may now by these thoughts.Actually, if that you are the fans of fashion show, especially, if you are a fan of Karenalso streets from the City Centre this kind of as Liberty Blue, the Carter Style Emporium and stores like Rio, Brazil,underestimate the length of time it can take to lessen debts that we generally consider to be short term.Thewhat?Guess what sort of flower do I neglect to say? You! Indeed, the hostess could be the central on the house. Howsuitable for the gentlewomen, you must think from the Karen Millen dresses, indeed, Karen Millen is always the

what happens if you need high power floor cleaners to merely suck those dirt and dust that have already accumulated within the years~

coach in 1941. According to its history, began [url=http://www.coachsaleline.com]coach outlet store online[/url] coach outlet store online z six bus companies, who created a unique line of leather bags and accessories coach. Coach in 1996, a major strategic adjustments, and some advertisements for placement of [url=http://www.coachsaleline.com]coach outlet online[/url] coach outlet online e young consumers. In 2001, the coach marks products. These products have the string “C” in [b]coach outlet online[/b] d the design and decoration. It is also the COACH brand to promote “American Legend” marketing strategy. Therefore, customers can save a lot of money, which gives us the [b]coach outlet store online[/b] r opportunity to become the most high-end consumers with a selection of handbags coach leather.

Fantastic goods from you, man. Goodbye Google App Engine (GAE) El blog de Carlos Ble I have understand your stuff previous to and you’re just extremely magnificent. I actually like what you have acquired here, really like what you’re saying and the way in which you say it. You make it enjoyable and you still take care of to keep it smart. I cant wait to read much more from you. This is really a tremendous Goodbye Google App Engine (GAE) El blog de Carlos Ble informations.

Perfectly pent content , Really enjoyed examining .

Wonderful goods from you, man. Goodbye Google App Engine (GAE) El blog de Carlos Ble I’ve understand your stuff previous to and you’re just too great. I really like what you have acquired here, really like what you are stating and the way in which you say it. You make it entertaining and you still take care of to keep it smart. I cant wait to read far more from you. This is actually a great Goodbye Google App Engine (GAE) El blog de Carlos Ble informations.

For other Google App Engine rants like this famous one by Carlos, you can have a look here:
http://www.gaecupboard.com/tag/rants

[b]?????????? ? ????? ??? iPhone 3g/4g, iPad ? ?????????[/b]

???????? ????? ?????? ? ??????????? ??? iPhone [b]iPad 2[/b] ? ?????????. ??? ? ???????, ?????? ???? ? ???????????? ??????, ???????? ?? ?????? (???????? 250 ? ? ???????? ????), ?? ???????? ???????? “???????? ????????” (200?), ???? EMS ????? ?????? ( ? ??????????? ?? ????)

???? ?? ????? iPad 2 ?? 950 ?? 2300?
???? ?? ????? iPhone 4 ?? 250 ?? 1500?
???????? ?????? [b]iPhone 4[/b] ?? 150?

? ?????? ?????? ?????? ?? ???????? ?????!!!

!!!!!?? ??? ???????? ????????, ?????? ? ???????????? ??????????? : 8-968-686-34-04 ?????????!!!!

Great post. Here’s a product with a powerful database in the cloud with ready-made apps. Just point-and-click to build your custom apps
http://www.caspio.com/

Unquestionably believe that which you stated. Your favorite reason appeared to be on the net the easiest thing to be aware of. I say to you, I certainly get irked while people think about worries that they just don’t know about. You managed to hit the nail upon the top and defined out the whole thing without having side-effects , people could take a signal. Will probably be back to get more. Thanks