Perfect summary. I totally agree to everything. (Be careful about statements of Drake; he is trolling around)
On Mon, Aug 6, 2012 at 10:46 AM, Jeff Schnitzer <j...@infohazard.org> wrote: ... > There is plenty to complain about, but GAE is still a good choice. > 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. > -- 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.
