Jeff, A lot of your points I had already put in to a business plan that I just worked on heading to VCs. Basically written as "fixed cost of growth, and no overhead during slump, or plateau".
Writing a business plan where you don't have to do weird math about the cost per computational unit, the number of people to support X servers, and the amount of rack space at what price is need, makes business plans a lot easier to write. 10 pages of charts just goes "poof". Instead I have "sales output per person" and "cost per unit sold" It's like re-selling a commodity. Oh, maybe that is the point. We'll see how this VC responds, I have a stronger relationship with them, but they are an East Coast primarily VC firm which may result in a different perspective. -Brandon -----Original Message----- From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer Sent: Thursday, April 14, 2011 2:54 PM To: saidimu apale Cc: google-appengine@googlegroups.com Subject: Re: [google-appengine] Re: Startup Weekend and Google App Engine [I accidentally sent this as a private reply, reposting now publicly] On Wed, Apr 13, 2011 at 2:00 PM, saidimu apale <said...@gmail.com> wrote: > Aren't you strengthening the argument that GAE gets in the way of > execution by its beta/uncertain nature and its innumerable gotchas > (which is what I think some are contending)? I think this is begging the question. You only feel that GAE has innumerable gotchas because you are unfamiliar with it. I've been working with appengine (both java and python) intensively for about 1.5 years now and it *very* rarely surprises me. On the other hand, after 9 years of professional work with traditional web stacks I still found plenty of surprises - differences in the behavior of MySQL vs Postgres vs Oracle, appservers that degrade on certain flavors of Linux, nuances of configuring a clustered cache, even just building network infrastructure that can handle gigabits of traffic. Also, I don't think engineers know as much as they think they know. Sure, anyone can set up a LAMP stack and have their Hot New Startup running on EC2 in a week. But how many of those people have bumped up against the scaling limits of MySQL, and would know what to do about it? There's an awful lot of people out there (VCs included, it would seem) who think an RDBMS stack is a known quantity simply because they've never had to work with enough traffic for it to matter. Taking Brandon's risk assessment into account... Appengine is a win in these columns: No need to hire sysadmins, dbas, security engineers: Major risk reduction. No chance that those hires might turn out to be inept and/or destructive: Major risk reduction. Minimal/no need to load test your application: Major risk reduction. Minimal/no need to intervene when load spikes: Major risk reduction. No need to maintain exotic new databases (MongoDB, Cassandra, etc) to maintain scalability goals: Major risk reduction. Effectively no chance that hackers will break into your system and steal your data (ahem, Wordpress): Major risk reduction. The big downside risks seem to be: 1) Google could give up on appengine. Google's commitment to appengine seems to be growing, not diminishing. From what I know about the development team it seems large and healthy. GAE seems to be an increasingly used product inside Google. >From the outside it's hard to be certain, but my early-warning radar says "all lights are green". Compare this to AWS Elastic Beanstalk. From reading the Amazon forums, it doesn't seem to be getting a lot of use. From actually using the product, I can see why. 2) You could have a problem that is hard to solve using Appengine. If you run into this during development, you didn't do enough research in advance. This isn't specific to appengine; you could run into the same problem with any new piece of foundational technology (ie NoSQL). Either spend more time watching Google I/O videos or consult with someone in advance who is familiar with the platform. On the other hand, other cloud providers are only a few ms of latency away. There is nothing wrong with a hybrid solution; it's a route I've taken for both iphone push notification and for large persistent in-memory indexes. 3) You have reliability requirements that Appengine cannot meet. This is just a twist on #2. Honestly, though, how reliable does your site *need* to be? Each additional 9 of uptime costs exponentially more money. I've seen a lot of big companies have a lot of downtime, and it's almost always because some ops guy or dba screwed up. Just choosing EC2 doesn't guarantee you better uptime than GAE, it just moves the responsibility into your hands. If you're hiring ops people on craigslist you're *highly* unlikely to beat even the M/S datastore's questionable track record - which, btw, hasn't been all that bad lately. 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 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.
