Salesforce.com: Blame the database vendor

Salesforce.com: Blame the database vendor

Summary: Phil Wainewright writes about the salesforce.com service outage that happened this week.

SHARE:
TOPICS: Salesforce.com
4

Phil Wainewright writes about the salesforce.com service outage that happened this week. He inlcudes some comments from victims and salesforce.com's press statement about the problem and resolution. Here is a portion of the salesforce.com statement:

On Tuesday, December 20th,, some salesforce.com users experienced intermittent access (between approximately 9:30 am and 12:41 pm ET & 2:00 pm and 4:45 pm ET) on one of the company’s four global nodes.  The root cause of the intermittent access was an error in the database cluster. Salesforce.com addressed the issue with the database vendor. By Tuesday afternoon EST, the system was running normally for all users.

The sentence in bold (my emphasis) in the carefully crafted statement implies that database vendor (Oracle, I assume) was somehow at fault--an error in the database cluster. It's good to acknowledge the specific problem that caused the outage, in the quest for transparency, but pointing the finger at the database vendor is transparently trying to shift the blame.

salesforceoutage.jpg

eWeek's report includes comments from Bruce Francis, salesforce.com's vice president of corporate strategy:  

"We never point fingers at vendors whenever we have problems," Francis said. "Our database infrastructure is composed of many different components from many different vendors and Oracle is one of those vendors," Francis said. "We don't believe it is good corporate policy to identify vendors" whose products might be involved in a system outage, he added.

The company is pointing fingers, at an 'unnamed' database vendor, rather than focusing more on its own culpability. Salesforce.com, as a full-service hosting, on demand, software-as-a-service provider is solely responsible for what it delivers to the customers, no matter what happens inside its data centers.

The reality is that running your own infrastructure or outsourcing it to a salesforce.com isn't going to always deliver five nines, but procedures and service-level agreements should be in place that protect customer interests, including rebating customers for lost hours of service. In this case, the customer has someone to blame, and point a finger at, other than their own IT department...  

Topic: Salesforce.com

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • semantics may be important

    While I don't disagree that Salesforce's statement seems to incriminate some database vendor, it's important to point out an alternative interpretation of the statement.

    written: "Salesforce.com addressed the issue with the database vendor."

    possible interpretation: "Our database-driven application had a significant performance problem and our database vendor worked with us to show us how to fix it."

    Database apps are notorious for performance problems caused by queries that result in full table scans. Every database app developer has been bitten at least once by this: the failure to understand what the query actually does, and how it should be constructed to take advantage of indexed fields.

    Our campus has had problems recently with an application purchased from a vendor that uses another vendor's database engine. (All names withheld to protect the guilty, I suppose.) We are somewhat at the mercy of BOTH vendors, but it does appear (from the second-hand reports I've received) that the app vendor has written some stuff that isn't supportable in large-scale deployments because it is not database-efficient.
    GDF
    • DBMS performance

      Some DBMS vendors' products are much more vulnerable to "rogue queries" and much more prone to table scans (even if indexes are available) than others. Again I mention no names, but they know who they are.

      I would say the quality of the optimiser is one of the deciding factors in DBMS selection. The less the programmer has to think about optimisation the better (assuming that the programmer has expressed the query correctly from a logical point of view).
      jorwell
  • I think it's "blame Oracle"

    http://www.oracle.com/corporate/press/2005_jul/salesforceonoraclegrid2.html

    What's not clear if it's an Oracle problem or if Salesforce.com IT staff pulled some stupid human tricks.
    george_ou
  • Will anyone buy it?

    When tires start comming apart and SUVs start rolling, does everyone yell at FireStone or at FORD? Even after FORD buys you BRAND NEW TIRES, do you still blame FORD or FireStone?
    Roger Ramjet