SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Salesforce’s Database.com: Fat SaaS Here We Come!

Posted by Bob Warfield on December 7, 2010

Salesforce is skating to where the puck will be ahead of the other players once again–there’s a reason they’re so much bigger than the rest of the SaaS players.  This time it’s all about their latest development in the hotly contested PaaS (Platform as a Service) market.  They’ve introduced a fascinating new offering called “database.com” (what do you suppose they paid for that domain?). 

What is this database.com offering?

Larry Dignan pegged it best, among the various posts I read.  He says it’s a full frontal assault on the incumbents like Oracle, and that Salesforce is building out a stack, only the stack is delivered as a service that lives in the Cloud.  That’s exactly what’s happening.  Imagine writing software that talks to your database server via an API.  That part isn’t hard, because that’s how it already works.  Now imagine that you don’t own the database server; it lives in the Salesforce Cloud and you rent.  They take care of it and promise to use all the tricks they learned scaling Salesforce.com to make your database scale like crazy too.  Pretty cool!

The initial responses from the rest of the blogging world are also interesting:

Phil Wainewright says they’ve squashed all the little PaaS players.

Klint Finley reports that Progress software is building out drivers (ODBC, etc.) so your apps can directly call Database.com as their DB.

– Sam Diaz and many others are focused on the Oracle rivalry.  Can this be good for Oracle’s share price?  Will their database hegemony finally start to crack?  And what does it mean to the budding NoSQL world?

Obviously there is a lot of crystal ball work to be done here, and a lot of study of the available information.  Most of all, we’ll have to wait to get our hands on Database.com before we can really understand what it means.  But I did want to finish this post by talking about Database.com’s relationship to what I’ve been calling “Fat SaaS”.

We’re moving beyond the debate about SaaS versus On-premises.  On-prem isn’t dead, but it sure isn’t getting any stronger, while the SaaS world keeps gaining momentum.  The truth is that it is a superior model.  There used to be a lot of feeling that IT was afraid of it, and that this is what was holding it back.  But we’re starting to see considerable evidence IT not only doesn’t fear it, but that they’re embracing it wholeheartedly.  More importantly, we’re seeing the SaaS world start to move beyond simple questions (to multitenant or not to multitenant is actually a pretty simple question) and onto how to evolve to the next level.

Fat SaaS is a model that pushes as much business logic into the client as possible and leaves the server-side largely acting as a data store.  Given the availability of rich User Experience tools like Adobe Flex with AIR (for creating desktop apps), as well as the onset of the mobile app phenomenon, together with the difficulties of scaling in a multicore world, it’s a logical development.  After all, if you survey an Enterprise, do they have more cpu’s tied up in client devices, or in servers?  Which cpu’s are more over worked and which ones have more bandwidth available?

I’ve written about the Fat SaaS idea before, and I think it’s one of the logical next developments we’ll start seeing like crazy.  Database.com just opened the door to making it even more logical, because what else would talk to such a thing but a Fat SaaS application?  Doing a bunch of centralized number crunching won’t be nearly as happy as a Fat SaaS app with the inevitable latency that comes with having your database in a different Cloud than the software that’s consuming the data.  The client is already used to that being the norm.

Now, getting back to Phil Wainewright’s proposition that it has squashed the other players, I don’t think so.  It may be hard on the little players, or it may not.  Remember, Benioff is trying to out-Oracle Oracle.  But even Oracle hasn’t succeeded in squashing the Open Source DB movement, not even after acquiring MySQL.   It’s more popular than ever.  In the end, neither Salesforce nor Oracle have to squash these littles guys.  They’re after the higher end anyway. 

What I want to see is competition.  Who will be the first to put up a service on Amazon AWS that delivers exactly the same function using MySQL and for a lot less money?  You see, Salesforce’s initial pricing on the thing is their Achille’s heel.  I won’t even delve into their by-the-transaction and by-the-record pricing.  $10 a month to autheticate the user is a deal killer.  How can I afford to give up that much of my monthly SaaS billing just to authenticate?  The answer is I won’t, but Salesforce won’t care, because they want bigger fish who will.  I suspect their newfound Freemium interest for Chatter is just their discovery that they can’t get a per seat price for everything, or at least certainly not one as expensive as they’ve tried in the past.

I’ll be watching to see whether the prices come down and whether competition develops.  I fully expect both will be underway before we know it.  Meanwhile, Bravo Salesforce–you’re showing the rest of the world how it’s done!

Related Articles

Good interview by Don Fornes of Eric Stahl, Director of PM for Database.com:

12 Responses to “Salesforce’s Database.com: Fat SaaS Here We Come!”

  1. […] Bob Warfield has a partial answer: Who will be the first to put up a service on Amazon AWS that delivers exactly the same function using MySQL and for a lot less money?  You see, Salesforce’s initial pricing on the thing is their Achille’s heel.  I won’t even delve into their by-the-transaction and by-the-record pricing.  $10 a month to autheticate the user is a deal killer.  How can I afford to give up that much of my monthly SaaS billing just to authenticate?  The answer is I won’t, but Salesforce won’t care, because they want bigger fish who will.  I suspect their newfound Freemium interest for Chatter is just their discovery that they can’t get a per seat price for everything, or at least certainly not one as expensive as they’ve tried in the past. […]

  2. […] Comments Salesforce's Da… on Salesforce’s Database.co…Salesforce’s Databas… on Forget SaaS vs On-Prem, Here a…Salesforce’s D… […]

  3. […] Bob Warfield has a partial answer: Who will be the first to put up a service on Amazon AWS that delivers exactly the same function using MySQL and for a lot less money?  You see, Salesforceâs initial pricing on the thing is their Achilleâs heel.  I wonât even delve into their by-the-transaction and by-the-record pricing.  $10 a month to autheticate the user is a deal killer.  How can I afford to give up that much of my monthly SaaS billing just to authenticate?  The answer is I wonât, but Salesforce wonât care, because they want bigger fish who will.  I suspect their newfound Freemium interest for Chatter is just their discovery that they canât get a per seat price for everything, or at least certainly not one as expensive as theyâve tried in the past. […]

  4. […] high prices for additional storage and other commodity capacity for years with Salesforce.   I already commented that Database.com’s $10/user per month for authentication is way too expensive.  Dennis Howlett […]

  5. Oh come on – kinda premature guys.

    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.

    • smoothspan said

      Why do they host the whole stack on a single platform?

      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

      • Bob, you know I love your insights and generally agree with your point of view on them – but on this one – I disagree.

        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…

  6. smoothspan said

    Follow it through, Joe, because most Enterprise software doesn’t work the way you describe. It works this way:

    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

    • RE: Points 1 and 2: I think the more subtle point about what I am making about result sets is that a latency in data * frequency of transaction is inversely proportionate to application responsiveness and usability. I would expect small result sets going back and forth not big ones – but the fact they go back and forth – probably between a web-based intermediary before being presented to the end user means it would make a difference.

      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

  7. […] and I’m a big believer one whose ultimate incarnation I’ve taken to calling “Fat SaaS“.  A pure Fat SaaS application minimizes its dependency on the Cloud and moves as much […]

  8. […] PaaS environment) and more recently my Enterprise Irregulars sparring partner Bob Warfield has been pushing the notion of Fat SaaS. In fact I’m wondering what happened to that blog post Bob promised us in the wake of his […]

  9. […] PaaS environment) and more recently my Enterprise Irregulars sparring partner Bob Warfield has been pushing the notion of Fat SaaS. In fact I’m wondering what happened to that blog post Bob promised us in the wake of his recent […]

Leave a Reply

 

Discover more from SmoothSpan Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading