Thanks Lorenzo, I have looked at both of your links.
I realise that nowadays SLAs are more smokescreen than meaningful. For example, a Google service charge refund is of little consolation if a developer has 30,000 angry customers. When it comes to this kind of thing, prevention is better than cure. And if prevention is not always possible then some level of control is desirable in the recovery process. That is why "premium developer support", "guaranteed turnaround times" and "access to trained support engineers" are the noises I like to hear from the "GAE for Business" people. These are the only things that really matter at the end of the day. But I would leave the following proviso: For now, these encouraging noises are only words. In practice, GAE service problems are not going to be spread out nicely over time and space as might be the case with, say, a hardware manufacturer. A serious GAE outage will probably affect zillions of app deployments *simultaneously*. And there are only so many expert support staff which Google can have on standby. So the above noises need to be backed up by serious measures in the future, one of which might involve the special redundant backup cloud I suggested for customers willing to pay for added control and peace- of-mind. At a flick of a switch, or should I say: a click of a mouse, I would be able to activate a standby deployment until Google sorts out a major outage. But this is not trivial to implement - there are all sorts of issues re: DNS, data consistency, etc. Anyway, I'm sure Google is already very aware of where this is all heading. But it is easy to forget about these things when a major project like this is picking up pace and everyone is excited and energised. And tacking on solutions at the end can be difficult as many software developers have found to their cost with 24x7x365 systems. Things like backup and recovery are the "boring" bits which those poor old greying enterprise vendors (who employ people like me) do very well. Perhaps the vibrant and youthful culture which has brought so much success to Google could do with a few grand-daddies about the place. And no, this is not a plug for anti-ageism :-) We live in interesting times. On Jun 14, 1:21 pm, "l.denardo" <lorenzo.dena...@gmail.com> wrote: > Hello, > Google announced a "business" version of AppEngine some time ago > > http://code.google.com/appengine/business/ > > It's got an SLA which is published in draft > athttp://code.google.com/appengine/business/sla.html > > Prices for public apps are still not listed (and I guess it would take > quite a long time to get them published). I don't know if regular > AppEngine will benefit from a similar SLA, but in the Business FAQ > they state developers can "get these features by migrating your app to > Google App Engine for Business", so I guess no SLA will be published > for regular GAE. > > I hope terms stated in the SLA draft can help you figure out what you > can offer to customers. As a developer I'd better leave SLAs and > customer refunds questions to lawyers, since they can be more accurate > in evaluating their implications (sad but true) :-(. > > Regards > Lorenzo > > On Jun 14, 1:23 pm, rvjcallanan <vinc...@callanan.ie> wrote: > > > > > Hi All, > > > This is a roadmap question hoping for a response from a member of the > > Google App Engine Team. > > > When GAE finally moves out of Beta (is January 2011 too optimistic?), > > there is a general expectation that developers will be able to run > > mission-critical web apps with best-of-breed scaling, redundancy and > > downtime. Please correct me if I'm wrong in this assumption (and if I > > am wrong then that raises other obvious questions). > > > When that nirvana moment arrives, I expect that Google will have fine- > > tuned its SLA to reflect its confidence in the robustness of its GAE > > platform and associated infrastructure. > > > But what about GAE developers whose apps provide "critical" services > > to end-users - a CRM application would be a good example. In this > > case, the developer would be expected to provide an SLA to his > > customers. Obviously the two main technical considerations in framing > > this SLA will be the quality of the App Software (the developer's > > responsibility) and the reliability of the platform/infra-structure > > (Google's responsibility). > > > Looking purely at the platform/infra-structure side of things, a > > conservative end-user SLA might water down Google uptime guarantees > > just to give a little wriggle room. But the guarantees are not the > > real issue here. The difficulty lies in what recourse the end-user has > > to an SLA violation. If Google fails to meet it's uptime guarantees, > > e.g. due to a major outage taking a couple of days to stabilise, then > > what recourse can the developer realistically expect from Goggle if he > > has 10,000 angry business customers? > > > Of course this question is pertinent to all "hosting" companies. The > > critical difference here is the level of control which the developer > > has in a GAE scenario compared to, say, a dedicated server cluster. > > For example, in a dedicated server scenario, you could have a worst- > > case disaster-recovery plan in place to get your web app back on-line > > within say 8 hours. But with GAE, that level of control is completely > > relinquished to Google. And it is worsened by the fact that your app > > is mixed up with zillions of other apps in the GAE soup. > > > I'm not expecting miracle answers here. I'm thinking more in terms of > > how GAE developers can approach end-user SLAs, bearing in mind that a > > watered-down SLA could be a deal breaker for end-users. I'm wondering > > also if Google is thinking of offering enhanced GAE services for > > developers of critical apps, offering an extra level of redundancy > > using a special "backup" cloud on independent infra-structure. -- 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-appeng...@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.
