On Monday, August 6, 2012 2:46:45 AM UTC-6, Jeff Schnitzer wrote: > > There is plenty to complain about, but GAE is still a good choice. > > The upsides: > > * It really is "fire and forget"; all you do is deploy code. There's > no provisioning, capacity planning, etc. Just pay the bill. > > * "Ops" is something people at Google do. You don't. > > * Great big box of useful tools; memcache, task queues, blobstore, > image manipulation, etc. > > * The High-Replication Datastore is a modern marvel. > > There are definitely some downsides to GAE: > > * It's expensive to operate. An "instance" is significantly more > expensive and capable of doing significantly less work than what other > platforms offer. Your bill starts at $100/mo just to use SSL (and > with all that private data you certainly are, right?). In the early > days you're going to spend more than you would elsewhere... and if you > have a lot of traffic, you're going to spend a *lot* more. This is of > course balanced against not paying for dbas and sysadmins. > > I'd love to see a pricing calculator that lets potential customers get a rough estimate of monthly costs, (To be honest though, I'm kinda surprised there isn't one already.)
> * The concern about lock-in is totally warranted. If you build a > complex app on GAE, it's pretty much a total rewrite to go elsewhere. > The flip side is that you're "locked in" because there are all these > nice high-level services with great APIs that you would otherwise have > to invent and manage yourself. > > You're going to have vendor lock-in of some form or another what cloud provider you choose, I'm not sure what the issue is here. > * Historically, reliability has been spotty. It pains me to say this > but things break a lot and you will likely see downtime a lot more > than if you maintained more of the infrastructure yourself. GAE is a > complicated system that is being upgraded on a schedule that is opaque > to you, plus you're running on shared infrastructure with thousands of > neighbors who might not be very nice. And often there's not much you > can do but scream on this mailing list. On the plus side, when > something breaks, someone at Google fixes it - not you. > > Are there any examples you can point to? > * The datastore, while amazing for most web apps, is very challenging > for some classes of problems. Two that come to mind are: > * Heavily transactional systems. XG transactions help but you > still have to go through major contortions to build banking-type > applications. RDBMSes are clear winners here. > * Rapidly mutating datasets. It can be very tricky to work around > the one-transaction-per-second-per-entity-group throughput limit, > which gets even slower in XG transactions. There are usually > solutions (eg sharding, queueing) but they are all huge PITAs that > complicate your business logic. GAE doesn't offer any kind of service > that fills the niche that Redis fills. > > I need to read more about how the datastore works. > * 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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/xuidIPq0x2IJ. 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.
