Not to mention the fact that there is an opportunity cost in developing a platform that can run both hosted and do-it-yourself. It takes work.
I get bent out of shape when people request all sorts of features that are tangential to appengine, like PHP and apple push notifications and SMS and ecommerce integration. These are things you can do just fine with third-party products and sliver of imagination. If the appengine team spends their finite man-hours on frivolous stuff, that means they aren't working on spatial indexes (back to work, Alfred!) and fulltext search and other things that are *really* hard to do without native support. I'll keep an eye on Cloud Foundry, but it's still too early. I have one not-to-be-named insider's view and it doesn't seem pretty so far. As an aside, I tried to buy an upgrade license for my old copy of VMware Fusion last week. Their online store is hideously broken (as in, after more than an hour I still couldn't succeed in making a purchase). After calling sales and waiting on hold for 20 minutes, I finally gave up and just downloaded a pirated key from the internet (three minutes to find, tops). Seriously, I've never tried so hard to give someone money and met with such utter failure. I'm sure the people that run VMware's online store are a different team than the people that run their cloud offerings... but if this is a sign of their competence, beware. Jeff On Tue, Apr 19, 2011 at 1:15 PM, Brandon Wirtz <[email protected]> wrote: > I see it the opposite way on the decoupling… All my eggs in one basket is > scary, but trying to decide if my code will cost more to run on X vs Y, and > if the Performance will be the same on Z as on X is the very reason I want > off of Managed hosting solutions. > > > From: [email protected] > [mailto:[email protected]] On Behalf Of saidimu apale > Sent: Tuesday, April 19, 2011 1:11 PM > > To: [email protected] > Subject: Re: [google-appengine] Re: Startup Weekend and Google App Engine > > > > GEO distribution as a reason for serving from the cloud is rendered void by > the performance of the big players infrastructure. > > > > Raw performance isn't the only relevant metric when it comes to geo > distribution. Legal jurisdiction is a huge factor for some, especially if > some government (the US) decides to seize domains or force infrastructure > providers to drop clients. > > > > Lack of IaaS-vendor lock-in is another huge reason (the ability to switch > IaaS providers while still maintaining the same PaaS code). > > > > As the article states, the current PaaS market tightly integrates > PaaS-provider and IaaS-provider. Decoupling this is a win-win-win situation > for developers/VCs/managers etc etc. > > > > > > On Tue, Apr 19, 2011 at 3:53 PM, Brandon Wirtz <[email protected]> wrote: > > You ever raced GAE from brazil, against a Brazilian hosting Provider? I was > seeing latency differences of about 30ms. GEO distribution as a reason for > serving from the cloud is rendered void by the performance of the big > players infrastructure. > > > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of saidimu apale > Sent: Tuesday, April 19, 2011 9:59 AM > To: [email protected] > Subject: Re: [google-appengine] Re: Startup Weekend and Google App Engine > > > > Here's a tantalizing prospect on the "advent of private PaaS" in a blog post > by RightScale, on Cloud Foundry's potential. I am watching Cloud Foundry > very closely, if it matures well (a big 'if') then I'm definitely jumping > the GAE ship. The possibilities of choosing a PaaS provider *and* a IaaS > provider are simply too attractive. Imagine running your GAE app on Amazon's > IaaS, running on the exact-same GAE PaaS software. > > > > Good times ahead! > > > > http://blog.rightscale.com/2011/04/12/launch-vmwares-cloudfoundry-paas-using-rightscale/ > > Until now the notion of PaaS has lumped together the author of the PaaS > software and its operator. For example, Heroku developed its PaaS software > and also offers it as a service. If you want to run your application on > Heroku your only choice is to sign-up to their service and have them run > your app. Google AppEngine has the same properties. All this is very nice > and has many benefits, but it doesn’t fit all use-cases by a long shot. What > if you need to run your app in Brazil but Heroku and your PaaS service > doesn’t operate there? Or if you need to run your app within the corporate > firewall? Or if you want to add some custom hooks to the PaaS software so > you can punch out to custom services that are co-located with your app? All > these options become a reality with Cloud Foundry because the PaaS software > is developed as an open-source project. You can customize it and you can run > it where you want to and how you want. > > Of course you can also go to a hosted Cloud Foundry service whenever you > don’t want to be bothered running servers. This could be a public Cloud > Foundry service that is in effect competing with Heroku, AppEngine and > others, but it could also be a private service offered by IT or your > friendly devops team mate. This opens the possibilities for departmental > PaaS services that may have a relatively small scale and can be tailored for > the specific needs of their users. > > > > > > > > On Fri, Apr 15, 2011 at 3:20 PM, Jeff Schnitzer <[email protected]> wrote: > > On Thu, Apr 14, 2011 at 11:53 PM, Brandon Wirtz <[email protected]> wrote: >> To be fair... It's more like the partner in the restaurant saying, you >> have >> to use Canola oil, instead of Peanut Oil because we think there is less >> risk. So your fries won't taste as good, we're fronting the money, so you >> do it our way. > > To draw out that analogy a little farther, we'd have to add the fact > that you're also a MD-PhD who spent the last 10 years researching > heart disease, and the partner is someone who has read a few articles > on the Huffington Post. > > :-) > > 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. > > > > -- > > 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. > > -- > > 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. > > > > -- > 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. > > -- > 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. > -- 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.
