3: stored procs – yes. Agree, thats what they are best for. Hopefully they have some great developer tooling for building them.

4: as long as you can get that part of the mousetrap with the database.com offerring then its great. Big question is IF. Mind you, cognos make a whole business out of reporting alone, so yes – agree.

5: This is true, hopefully speaking to my point about developer tooling in point 3.

6: Peer to peer versus grid compute, ok – well, Map-reduce and other distributed algorithms like SETI are just that – specific algorithms for specific tasks. My points hold firm: this will need changes to telco infrastructure and on-premise technology, changes to the cost model of bandwidth and especially changes to the approach of application development (especially LOB style apps) to be done before you could expect this to really take off and be useful for the enterprise.

As an example, look at the HUGE effort Intel has gone to with developer community-centric communication to drive adoption of parallel programming techniques to gain the promised performance levels of their CPUs. This is a big change – so in the words of Panteen; “don’t expect it to happen overnight. But it will happen”.

6 and a half: did I mention map-reduce is still i/o intensive? in order to reduce, you still need to map – and you have a monolithic SaaS database with network latency to map from. ouch.

The bottom line is this: I never said never (I never do (doh! I just did)).
I just said it was waaay premature to say anyone was ‘squashed’.

Regards
Joe

1. Most of the transactions do not result in a large result set, so no problem there. They shift a record or two back and forth, or perhaps a small handful of records that typically correspond to a form. I can fill out my expense reports or whatever other form-based Enterprise app I may like from CRM to ERP all day long in this mode. A great deal of object persistence type computing works out this way too.

2. For those cases that could yield the large result set, you never give the user the large result set anyway, you cursor them through it. If you didn’t, your software isn’t going to scale. Trust me on that, been there, built a lot of that.

3. The exception, when you did want to crunch through each and every record of a large result set is what I’m calling crunching. But an awful lot of that kind of crunching doesn’t necessarily benefit from pulling the data out of the DB either. Depends on the problem. In many cases you may be better off to leave it in the DB and attack it with stored procedures rather than hashing through it record by record in Java or what have you. However, even if your app does require this, I have an answer, hold that thought.

4. If I want a report, SFDC already has a better mousetrap for that than most any other SaaS vendor anyway, so it still works for that scenario because Force.com reports will certainly talk to Database.com. I’m nutty to try to build reports myself from scratch unless its a very small number of canned reports. The Open Source reporting solutions stink. Been there done that and talked to many other SaaS companies in the same situation.

5. What’s the value from the service provider? DBA, scaling, monitoring, and all that jazz. The database is the lion’s share of your operations overhead at a SaaS company.

Now let’s touch on that crunching and peer-to-peer again. Ever look at how grid computing works? Ever hear of SETI@Home? Gee, I guess I could actually wind up crunching pretty well with this architecture after all provided I can shard my crunching activities effectively so they have some locality of reference with respect to the data they have to see.

Hey wait, that’s what Map-Reduce is all about too, eh? You could think of Map-Reduce as how to shard your processing chore in the face of truly lousy I/O bandwidth. Works pretty good.

Never, say never!

Cheers,

BW

Azure – done in the past? Built for their own use? Not really. Amazon and Google – well, it is how they do it, so agree there – but tradition is not the motivation for them whatsoever.

Having integrated levels of service and reliability up and down the stack is where the excitement is…and separation of the ‘stack’ reduces the ability of one vendor to provide quality of service, reliability, fault tolerance and (drum roll….) performance for the end solution being developed. It becomes nobody’s fault – and as an enterprise, you can bet your bottom dollar that if my app is running like a slug I want to know who’s head is going to roll.

I think the reality is though, that it would be the blink of an eye for Google or Amazon to make a driver to connect to their database infrastructure and with it they could crush Salesforce. They are more established and have existing APIs and users. But they don’t.

The bit I really struggle with in your comment is the bit around ‘centralized crunching’ … seriously, I was not even thinking about real number crunching – (and you’re right about it sucking). But rather, any transactional application that deals with data would be a big, fat fail. Eventually you are going to want result-sets, eventually some guy wants a report and the next thing you know you’re bringing that data home again -be it cached or permanent.

As for peer to peer – that concept is about streaming content between distributed end-points; either unidirectional chunks like torrents, or bi-directional ‘thin’ streams like Skype. Either way, it’s kind of the antithesis of ‘database.com’ – you have not ‘solved’ anything by SaaSing it because all you did was move the monolithic transaction elsewhere on the network – and its on a network that is out of your control with crappy latency issues.

Even if ‘database.com’ uses globally distributed big-table, muscle-server heaven with oodles of bandwidth to spare to service your requests; unless the rest of your end-point solution-stack matches that level of service delivery and reliability, what’s the point?

ka-chow! I am back where I started – talking about integrated solution stacks…

Easy, because that’s how it had been done in the past, in at least two of the cases they were building the platform for their own purposes, and those purposes involved a bunch of centralized crunching.

Like I said, centralized crunching won’t tolerate the latency, if nothing else. But there are tons of different kinds of apps that don’t have to do all that centralized crunching. Why else do you think peer-to-peer can be so successful for many applications, some of which even involve significant amounts of data?

Cheers,

BW

One of the biggest issue with all the databases, even the distributed non-relational ones like Mongo is data throughput. If you have locally hosted apps talking to a cloud hosted database you are in for a lot of optimization work and will probably still find your performance sucks. Why do you think Azure, Google and Amazon host the whole stack on a single platform?

Phil lost his load well ahead of the game! There is a whole pile of work: changes to telco infrastructure and on-premise technology, changes to the cost model of bandwidth and even changes to the approach to application development to be done before you could expect this to really take off and be useful for the enterprise.