What can we glean from the na14 outage? Will Salesforce protect you? Here’s what you need to know.
The na14 outage on May 10 has raised a lot of discussion around trust in cloud applications, data backup strategies and even outage clauses with SaaS vendors. The analogy that comes to mind for me is an airplane crash. While it’s a tragedy with very graphic scenes, people keep flying since air travel remains one of the safest modes of transportation. And losing transactions for 3.5-4 hours is certainly graphic from a business operations perspective.
In response to the outage, I’m getting asked interesting questions from the Salesforce community and LinkedIn on external data strategy, which is my area of expertise. I actually had not considered this question until after reading the coverage, but can external objects save your organization from future outages?
Salesforce Connect was introduced a couple of years ago to provide seamless real-time access to back office systems, so organizations no longer have to copy data into Salesforce to be treated as native objects. These federated objects are accessible via OData and called external objects.
No. Salesforce connect provides data integration and federation, not high availability.
Yes and No.
We'll start with how it would have helped. Let's say your external objects are setup against an Oracle database behind the firewall and a Postgres database hosted in Heroku. If those transactions were made completely on external objects, the transactions would be persisted to Oracle or Postgres for which external objects were created. So there would have been no data loss on those objects on May 10, unless your external databases were also down. But if both Salesforce and your external databases happened to be down at the same time, there are probably bigger things to worry about than data loss.
Now for how it wouldn't help, at least not from the perspective of any data persisted in the Salesforce platform. Any updates made on standard fields with indirect relationships to external objects would still be lost. However, updates made on external object fields would be preserved in Oracle and Postgres, and you would be able to figure out what parent objects may have been updated from external database transaction records.
We run Salesforce on na13 and I trust Salesforce. Salesforce Connect is not a high availability strategy, and trying to run an entire Salesforce org as external objects just does not make sense. But I am a big proponent of this technology for its intended purpose of allowing flexibility for Salesforce orgs to configure where the data resides for a single version of truth. As a best practice, I continue to recommend that we keep our Salesforce data in Salesforce, and our remote data sources in external databases exposed as external objects.
If you’re new to external objects, you can check out my tutorial published on Salesforce Developers to learn more. Building a Data Integration Proof of Concept Using Lightning Connect
Sumit Sarkar is a Chief Data Evangelist at Progress, with over 10 years experience working in the data connectivity field. The world's leading consultant on open data standards connectivity with cloud data, Sumit's interests include performance tuning of the data access layer for which he has developed a patent pending technology for its analysis; business intelligence and data warehousing for SaaS platforms; and data connectivity for aPaaS environments, with a focus on standards such as ODBC, JDBC, ADO.NET and ODATA. He is an IBM Certified Consultant for IBM Cognos Business Intelligence and TDWI member. He has presented sessions on data connectivity at various conferences including Dreamforce, Oracle OpenWorld, Strata Hadoop, MongoDB World and SAP Analytics and Business Objects Conference, among many others.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.