There is plenty to complain about, but GAE is still a good choice. The upsides:
* It really is "fire and forget"; all you do is deploy code. There's no provisioning, capacity planning, etc. Just pay the bill. * "Ops" is something people at Google do. You don't. * Great big box of useful tools; memcache, task queues, blobstore, image manipulation, etc. * The High-Replication Datastore is a modern marvel. There are definitely some downsides to GAE: * It's expensive to operate. An "instance" is significantly more expensive and capable of doing significantly less work than what other platforms offer. Your bill starts at $100/mo just to use SSL (and with all that private data you certainly are, right?). In the early days you're going to spend more than you would elsewhere... and if you have a lot of traffic, you're going to spend a *lot* more. This is of course balanced against not paying for dbas and sysadmins. * The concern about lock-in is totally warranted. If you build a complex app on GAE, it's pretty much a total rewrite to go elsewhere. The flip side is that you're "locked in" because there are all these nice high-level services with great APIs that you would otherwise have to invent and manage yourself. * Historically, reliability has been spotty. It pains me to say this but things break a lot and you will likely see downtime a lot more than if you maintained more of the infrastructure yourself. GAE is a complicated system that is being upgraded on a schedule that is opaque to you, plus you're running on shared infrastructure with thousands of neighbors who might not be very nice. And often there's not much you can do but scream on this mailing list. On the plus side, when something breaks, someone at Google fixes it - not you. * The datastore, while amazing for most web apps, is very challenging for some classes of problems. Two that come to mind are: * Heavily transactional systems. XG transactions help but you still have to go through major contortions to build banking-type applications. RDBMSes are clear winners here. * Rapidly mutating datasets. It can be very tricky to work around the one-transaction-per-second-per-entity-group throughput limit, which gets even slower in XG transactions. There are usually solutions (eg sharding, queueing) but they are all huge PITAs that complicate your business logic. GAE doesn't offer any kind of service that fills the niche that Redis fills. * There are some downright broken parts of GAE, but they aren't well documented as such. The email service is useless; go with a third-party provider instead. Backends are a disaster; don't use them. This isn't a big deal as long as you know what to expect; keep following this mailing list. Unless you have a "hard problem" for GAE, I'd say go for it and make a home here. The problem is that it's hard to know what a hard problem is without already being very familiar with the platform. Truth be told, after three years I still bump into surprises now and then... but there's always some solution, even if it involves pushing a service fragment out to another cloud provider. The OP's app sounds like a good fit. Jeff On Sat, Aug 4, 2012 at 1:48 AM, Rerngvit Yanggratoke <rerng...@gmail.com> wrote: > As many people have stated about advantages of GAE for startup already, let > me provide some disadvantages. The purpose of this is not to discourage > people to use GAE but inform them about both sides of the story. > > The first and most important issue is a vendor lock-in. GAE normally > requires you to spend significant efforts to develop and optimize > specifically for the platform to run your applications nicely and cost > effectively. For example, it is recommended to use a platform-specific > database layer like Objectify than the portable but heavy-weight one like > JPA or JDO. Another example is that it is recommended to minimize the size > of your applications to reduce the cold-start time. This also means that > very useful but heavy-weight frameworks like Spring are not going to be > comfortable with GAE unless you are willing to pay a steep price of > "reserved instances". As a result, if one day you have to move your > applications away from GAE to somewhere else, porting your applications is > not going to be an easy task. You might have to spend significant resources > for that. The possible reason for the movement might be that Google > increases the price significantly such that your business model is not > sustainable anymore. This happened before to many people. Have a look in the > highly popular forum topic > (https://groups.google.com/forum/?fromgroups#!topic/google-appengine/obfGjbIkOTI). > Now, some people might argue by bringing up Opensource alternative of GAE > like Typhoonae (http://code.google.com/p/typhoonae/) or > AppScale(http://code.google.com/p/appscale/). Despite the fact those are > great and honorable attempts, neither of them are fully compatible with GAE. > In other words, if your applications run smoothly on GAE, they might simply > break apart on their platforms. > > The second issue is the development efforts and learning curve required. GAE > is designed for highly scalable applications and require you as a programmer > to think the same. It certainly requires a new mindset compared to a > traditional web applications development. Generally speaking, everything you > do should be able to implement in a fully distributed way. For instance, you > should not use a relational database like Mysql because it is a major > bottleneck in traditional web applications. (You actually can use it now > with Google Cloud SQL. However, it deteriorates the purpose of running an > application for GAE). > > The third issue is a sharing of fate. This is actually not just for GAE but > for any other cloud solutions. You are going to run your applications on a > shared infrastructure. You do not know what applications are run besides you > in the same IP. They might be spam or malicious software developed by > hackers. Then, the IP might be blocked for a security reason. An example of > this is the recent CloudFlare blocking issue > (https://groups.google.com/forum/#!msg/google-appengine/Q6yQ4d9ov-o/hAyrgn0xZQwJ). > > All in all, the major thing to concern is picking the right tool for the > right job. GAE is suitable if your applications require a very high > scalability and you don't have or want to operate an operation team (System > administrators). Other than that, I would recommend you to find other > options. > > On Sat, Aug 4, 2012 at 1:03 AM, hyperflame <hyperfl...@gmail.com> wrote: >> >> It would be a good fit for most of those subjects, but keep in mind >> that GAE cannot access email through IMAP or POP3 because it doesn't >> support sockets, only standard url fetch. If you want to include email >> in your service, you'll have to base a proxy somewhere else, such as >> Rackspace, Heroku/AWS, etc. >> >> On Aug 3, 4:37 am, Levi Campbell <levicc00...@gmail.com> wrote: >> > I'm building a startup, and I'm considering GAE as the platform, however >> > I've been having a hard time finding information on why a startup might >> > consider GAE instead of the many cloud providers out there. Let me >> > explain >> > what I'm working on. >> > >> > I'm a big fan of David Allen's Getting Things Done: The Art of >> > Stress-Free >> > >> > Productivity<http://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp...>, >> > and after trying several tools and online services that (claim to) >> > implement the GTD methodology, I couldn't find anything that I loved, so >> > I >> > decided to build my own and make it available as a SaaS offering. This >> > app >> > will allow users to pull in their info_crap from email, facebook, >> > twitter >> > (and yes, I do have plans to add support for more social networks.), and >> > RSS feeds and organize it by relationship to the sender (i.e. family, >> > work colleague, vendor, and the like), project (i.e. planning a family >> > vacation.), and context (Either the when or where something should >> > happen.).\ >> > >> > Would GAE be a good fit for the application I'm developing? Why? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to google-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > > > -- > Best Regards, > Rerngvit Yanggratoke > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
