I want to append a few comments of my own to Waldemar's excellent commentary inline. Brandon, thanks for playing devil's advocate on this, I know you're on "our side" :-)
On Mon, Apr 11, 2011 at 2:30 AM, Waldemar Kornewald <[email protected]> wrote: > On Mon, Apr 11, 2011 at 8:15 AM, Brandon Wirtz <[email protected]> wrote: >> >> GAE code especially parts built around the datastore aren't transferable >> to other platforms. A big part of what makes GAE work is stuff that doesn't >> work on other platforms. I work with VC's on a regular basis and I agree >> with them on this point. Betting the farm on technology that is still >> labeled beta and doesn't yet have pricing finalized is risky. > > It's certainly not impossible to port datastore code to some other NoSQL DB. > The most important GAE-specific feature that isn't easily transferable is > transaction support, but even that can be dealt with in various ways (in the > worst case you build a SQL-based sharded solution). You can also simplify > the porting process a lot by using Django-nonrel. You might think that this > is a risk in itself, but any team worth investing in should be capable of > maintaining their own Django-nonrel fork (yes, the code is very simple) in > the unlikely case of us abandoning Django-nonrel. Furthermore, if you're using Java and Objectify, you can switch your data tier over to MongoDB with relatively minor pain. Scott Hernandez, who helped out with the original Objectify code, wrote Mongo's Java ORM system (Morphia) and now works for 10gen. Morphia is very similar to Objectify and uses many of the same annotations. >> Imagine you had done the math and decided that you could rule the world >> building a Financial transaction Datamining service on GAE, had priced it to >> be competitive based on Maser/Slave, and then you discovered M/S doesn't >> have 100% up time, so you had to move to High Replication, but because you >> are a data mining service most of what you do are writes, and you are paying >> 3x for those, your competitive pricing just got less so. What would have >> seemed like a great bet 6 months ago wasn't. As a VC you may have just lost >> your investment because what looked to be the way to better mining at lower >> cost is now better at higher cost. > > If a product relies heavily on datastore writes then App Engine might not be > the best choice to start with (writes are not only expensive, but also very > slow). In this case I can understand if VCs have doubts about the > technology. However, a lot of other web businesses fit App Engine's model > very well. Such businesses also don't react too sensitively to GAE's pricing > changes and even if GAE becomes a major cost factor you can still move away. The problem here is not risk inherent in the platform, but risk inherent in a team working with an unfamiliar platform. Your team could run into similar problems with any platform they aren't familiar with - especially with the proliferation of new NoSQL stores (remember Digg?). The answer to that is the same with any technology platform - the team needs to be sufficiently familiar with the platform to be able to competently build the product. Your startup shouldn't be a spike solution. Appengine has been around for years now, there are plenty of brilliant startup engineers available with deep knowledge of the behavior and limitations of appengine. No, not quite as many as Spring/Hibernate/RDBMS engineers, but this is a startup - you only need a handful. Rephrasing this slightly, I can understand if a VC was skeptical about a handful of traditional web stack engineers with no GAE experience who want to use appengine. They should be just as skeptical (actually, much more so) of a team without RDBMS experience trying to build a Hibernate app. >> As to Google End of Lining the product, well if you had built on Amazon >> you could run that on your own hardware or something like Liquid Web, pack >> up your code and just run. But GAE isn't so portable, anyone who has played >> with the datastore can tell you that a 50 gig datastore on the local install >> doesn't perform anything like the deployed version. Part of that is just >> that you can make calls to API's that will burn cpu at 150x Realtime for 3 >> seconds. To do that on your "local" you would need 150 CPUs for 3 seconds >> which a user can wait for, but they can't wait 75 seconds for that same >> thing to happen on 6 CPUs. 1) If you aren't sure your app is appropriate for appengine, you need to invest in some research time (or hire someone who is familiar with appengine). 2) Building to a portable API is Planning for Failure. GAE apps are difficult (not impossible, but difficult) to port because GAE provides services at a much higher level than IaaS companies. If you write to a lower-level platform, you need to invent all those services *yourself*. This is not without CONSIDERABLE opportunity cost - it takes a lot of work to run, maintain, and scale datastores, memcaching systems, appservers. You need DBAs, you need sysadmins, you need security engineers, you need build engineers. It all adds time and cost and risk. Even Tim O'Reilly says Operations is the new Secret Sauce. It's hard, it requires a lot of knowledge and manpower, and it can tank your business if you do it wrong. It's safer to let Google take care of it. http://www.paulgraham.com/startupmistakes.html For each one of those points, does Appengine increase or reduce risk? I would argue that the reduced headcount and increased productivity are clear wins, and "risk of platform going away" is not even on the list. The closest you get is "Choosing the Wrong Platform", but he's concerned the product won't get built (or won't perform) - not that the platform might or might not change three years after it's built. Most startups fail long before then. Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
