Goodbye Google App Engine (GAE)

This is a post rewrite. The original post can found at the bottom of this post.

The reason why I am rewriting this post is because Patrick Chanezon (from Google), has added a kind and respectful comment to this post. Given the huge amount of traffic this post has generated (never expected nor wanted) I don't want to damage the GAE project which can be a great platform in the future. People haven't understand  my point apparently because of the dramatic writing style of the original post.

The reason why we left the GAE platform is solely because of its unreliability as of september-octuber-november 2010. The last 3 months we saw the site down more times that we considered reasonable and we couldn't find a way to avoid it so eventually we decided to abandon the platform. When the GAE team be able to stabilize the platform, it will perhaps be a great platform for scalability.

I emphasized the GAE limitations because some of them were hard to work around when we were developing although we did a great job making everything work, but when the platform let me down because of its many 500 errors,I got the feeling that we had been loosing our time with a platform not enough mature.

As a young and small entrepreneur (I am the one who fund our projects training developers all around the country), the development effort was big and I calculated the amount of money and wrote it in the post, but any experienced developer knows that the quantity I wrote is not that much. Some of my readers are friends who have invested money in the project and I wanted to give them an idea of the effort we made in terms of money in the GAE platform.

When we started developing on GAE one year ago, there was less documentation that there are today. But even today, I haven't found any document saying... "if the application can't load into memory within 1 second, it might not load and return 500 error codes". This is something that should be written in the documentation as soon as possible to help others understand if GAE is a good fit for their apps or not. Django can load into memory in less than a second in my local machine I guess but apparently not in GAE and we build our app in Django because Webapp framework miss many things like security. With Django we don't have to care about XSS and i18n is easy while in Webapp it not that easy. So if GAE can't run with Django we had to migrate. But we were using Django Helper, developed but Google engineers if I recall correctly so it is quite disappointing to read from another Google engineer that now we have to load under a second. Sounds contradictory. Sounds not professional.

Regarding the GAE for Business, I believe this is really new. I remember joining the business plan/account when it was kind of beta and I thought it was still in beta because I never got news about it. So yes, we wanted to pay for better support and SLA and at that point we couldn't. As a developer I can't be checking this things every day because I've got many things to do so I guess Google have to inform me if the business account is now working or what.
The support from GAE engineers have been really bad and this is a mistake they know but I hope in the future it gets better for those who are investing in the platform.

In our current hosting we still don't do JOINs because we don't need them and we've learned a lot of things about scalability thanks to GAE restrictions. Data DEnormalization is one of them and we keep it like that. I wrote about the limitations because wanted to warn users who haven't  read about No-SQL. When I said "normalization" in the original post I meant that before saving strings, we transform them in a way that we can search for them (uppercase and things like that). When the application was running, it wasn't slow. We managed to optimize our algorithms and developed a caching architecture which works really well and have a nice API.

Although many people thought we have lost money for not reading docs, the reality is that we left GAE for its unreliability and nothing more.

We enjoyed certain things from the GAE platform like the feature of changing versions with a single click and the ability to add new fields to Kinds dynamically.

It is nice if GAE success and I am happy to see users who are enjoying the platform but for us, I have had enough for now. 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.

Thanks for reading and understanding my English which I think should be understandable.

====================================================

--------- Original post written on 21 nov 2010:

Choosing GAE as the platform four our project is a mistake which cost I estimate in about 15000€. Considering it's been my money, it is a "bit" painful.

GAE is not exactly comparable to Amazon, Rackspace or any of this hosting services, because it is a PaaS (Platform as a Service) rather than just a cluster of machines. This means that you just use the platform and gain scalability, high availability and all those things we want for our websites, without any other software architecture. Cool, isn't it.
You do not pay until you get a lot of traffic to your site so it sounds very appealing for a small startup. I read about this in a book called "The web success startup guide" by Bob Walsh.
So yes, everything looked cool and we decided to go with this platform a couple of months ago.
It supports Python and Django (without the ORM) which we love so we tried it out. We made a spike, kind of 'hello world' and it was easy and nice to deploy.

When we started developing features we started realizing the hard limitations imposed but the platform:

1. It requires Python 2.5, which is really old. Using Ubuntu that means that you need a virtualenv or chroot with a separate environment in order to work with the SDK properly: Ok, just a small frustration.

2. You can't use HTTPS with your own domain (naked domain as they called) so secure connections should go though yourname.appspot.com: This just sucks.

3. No request can take more than 30 secons to run, otherwise it is stopped: Oh my god, this has been a pain in the ass all the time. When we were uploading data to the database (called datastore a no-sql engine) the uplaod was broken after 30 seconds so we have to split the files and do all kind of difficult stuff to manage the situation. Running background tasks (cron) have to be very very well engineered too, because the same rule applies. There are many many tasks that need to take more than 30 secons in website administration operations. Can you imagine?

4. Every GET or POST from the server to other site, is aborted if it has not finished within 5 seconds. You can configure it to wait till 10 seconds max. This makes impossible to work with Twitter and Facebook many times so you need intermediate servers. Again, this duplicates the time you need to accomplish what seemed to be a simple task

5. You can't use python libraries that are build on C, just libraries written in python: Forget about those great libraries you wanted to use.

6. There are no "LIKE" operator for queries. There is a hack that allows you to make a kind of "starts with" operator. So forget about text search in database. We had to work around this normalizing and filtering data in code which took as 4 times the estimated time for many features.

7. You can't join two tables. Forget about "SELECT table1, table2..." you just can't. Now try to think about the complexity this introduces in your source code in order to make queries.

8. Database is really slow. You have to read about how to separate tables using inheritance so that you can search in a table, get the key and then obtain its parent in order to avoid deserialization performance and all kind and weird things.

9. Database behavior is not the same in the local development server than in google servers. So you need some manual or selenium tests to run them against the cloud, because your unit and integration tests won't fail locally. Again this means more money.

10. If you need to query on a table asking for several fields, you need to create indexes. If those fields are big, it is easy to get the "Too many indexes" runtime exception. That will not happend to you in a "hello world" application, but enterprise applications that need to query using several parameters are easy to run into this trouble. If you use a StringListProperty, you might not find this problem until one user populates this field with a long list. Really nasty thing. We had to re-engineer our search engine once in production becase we didn't know this till it happened.

11. No query can retrieve more than 1000 records. If there are more than 1000, you have to deal with offsets in your code to paginate results. Taking into account that you have to filter results in code sometimes because of the the limitations of GQL (the query language), this means again more complexity for your code. More and more problems, yeiiii!

11. You can't access the file system. Forget about saving uploads to filesystem and thouse tipical things. You have to read and learn about the inconvenient blobs. Again, more development time wasted.

12. Datastore and memcache can fail sometimes. You have to defend your app against database failues. What? Yep, make sure you know how to save user data when this happens, at any time in the request process, but remember... you can't use the filesystem. Isn't it fun?

13. Memcache values max size is 1megabyte. Wanted to cache everything? You were just dreaming mate, just 1 megabyte. You need your own software architecture to deal with caching.

There are some more things that make the development hard with this platform but I am starting forgeting about them. Which is great.

So why did we stay with this platform? Because we were finding the problems as we go, we didn't know many of them. And still, once you overcome all the limitations with your complex code, you are suppoused to gain scalabilty for millions of users. After all, you are hosted by Google. This is the last big lie.

Since the last update they did in september 2010, we starting facing random 500 error codes that some days got the site down 60% of the time. 6 times out of 10, users visiting the site couln't register or use the site. Many people complained about the same in the forums while google engineers gave us no answer. After days they used to send and email saying that they were aware of the problem and were working on it, but no solutions where given. In november, an engineer answered in a forum that our website had to load into memory in less than 1 second, as pretty much every request was loading a completelly new instance of the site. 1 second? Totally crazy. We have 15000 lines of code and we have to load django. How can we make it under 1 second?
They encourage people to use the light webapp framework. Webapp is great for a "hello world" but it is bullshit for real applications.
So once we suffered this poor support from google and we understood that they were recommending GAE just for "hello world" applications, we decided to give up on it finally.
This is not serious nor professional from google. We are more than dissapointed with GAE.

For us, GAE has been a failure 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 was behind the platform but I've learned an important lesson: good companies make mistakes too. I didn't do enough spikes before developing actual features. I should have performed more proofs of concept before investing so much money. I was blind.

After this we wanted to control the systems so we have gone to a classical hosting based on PostgreSQL, Nginx, Apache2 and all that stuff. We relay on great system administrators who give us great support and make us feel confident. We are really happy to be able to make SQL queries and dump databases and all those great tools that we were missing in the dammed GAE.

Because we are software craftmen, we designed all our code using TDD and the rest of XP practices. Thanks to this, we migrated 15000 lines of code in just 1 week (and just a pair of developers) from one platform to another which has been a deep change. From No-SQL back to SQL. From one database access API to another. If we didn't had these great test bateries, migration would have taken months.
Migrating data took us 1 week because of encoding problems and data transformations.

You might agree or not with me on this post but there is one certain reality: developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule. Now that we had developed tools and workarounds for all the problems we found in GAE, we were starting being fast with the development of features eventually, and at that point we found the cloud was totally unstable, doggy.

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • Prem

    @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.

  • Pingback: Four short links: 23 November 2010 | mobilei.tk()

  • moin

    @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.

  • vaxx

    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.

  • http://wordpress.chanezon.com/ Patrick Chanezon

    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

  • http://j.mp/jan-killian Jan Killian

    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

  • Pingback: pinboard November 24, 2010 — arghh.net()

  • Eddie

    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.

  • Pingback: La cultura del fracaso()

  • http://pugmarker.appspot.com/ PN

    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.

  • Anon

    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?

  • http://davidsalgado.me David Salgado

    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

  • http://davidsalgado.me David Salgado

    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

  • Anon

    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.

  • http://sixservix.com/blog/david David Bonilla

    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?

  • Oleg

    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.

  • Pingback: ???????? ??????, 26 ?????? « developers.org.ua()

  • Lewis

    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.

  • JK

    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.

  • Pingback: [cc] Google App Engine: daleko je sunce… obe?ano u PaaS modelu « ratkom.net: potraga za nepoznatim()

  • Brenda Smith

    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 🙂

  • Pingback: Twitter settimana del 2010-11-28 — .mark.net il blog di Marco Trova()

  • Pingback: Concluding my exploration in various cloud sevices « Logging on to Cloud # 9()

  • Pingback: Google App Engine Hello/Goodbye « Cloud Comments .net()

  • http://wordpress.chanezon.com/ Patrick Chanezon

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

    P@

  • Pingback: OpenQuality.ru | ???????? ???????????? ???????????()

  • Paul Storm

    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.

  • Fed up

    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.

  • rafaelxy

    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.

  • Michael

    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

  • Michael

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

  • http://www.spotdocuments.com/ Tom Andersen

    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.

  • Fed up

    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.

  • Pingback: Google Upgrades App Engine()

  • chiggsy

    @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.

  • Pingback: Rapidly Prototyping Tagatag on Google App Engine at Control Group()

  • Pingback: Revue du web .NET du 29 novembre | virtew()

  • http://paulonjava.blogspot.com Paul Bakker

    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.

  • Pingback: Google App Engine Answers Critics with New Release()

  • http://www.systemacorp.com Troy Borja

    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.

  • Pingback: Plunging into Web Development | Bob on Medical Device Software()

  • Pingback: Local Businesses and Social Media | Mandell Enterprises()

  • http://cloudappeal.blogspot.com Victor

    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!

  • http://www.reynekes.com Jacobus

    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 😉

  • Pingback: Can Google Get Its Mojo Back? | JetLib News()

  • Pingback: Can Google Get Its Mojo Back? | BrettMBell.com()

  • Pingback: Atheral News | Can Google Get Its Mojo Back?()

  • Pingback: markitd - Can Google Get Its Mojo Back?()

  • Pingback: Can Google Get Its Mojo Back? | Ebay shopping tips()

  • Pingback: Oh, Sugar! » Can Google Get Its Mojo Back?()