Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Facebook Outage Highlights Need for Third Party SLAs

DZone's Guide to

Facebook Outage Highlights Need for Third Party SLAs

· Performance Zone
Free Resource

Download our Introduction to API Performance Testing and learn why testing your API is just as important as testing your website, and how to start today.

“The bigger they come, the harder they fall” isn’t just a mantra for proverbial Davids looking to take down Goliath. In the case of internet footprints, it’s just as applicable.

The Goliath in this case is Facebook. The social media behemoth went down yet again...for an hour [on Tues. Jan 27, 2015], and as expected, the impact was felt far and wide due to the prevalence of Facebook integration across the web.

The outage lasted from 1:10 thru 2:15 am EST, and though notorious hacker group Lizard Squad claimed credit for bringing them down, Facebook released a statement on Tuesday [Jan. 27 2015] that the problem was a self-inflicted error caused by an internal change to their configuration systems.

Either way, attack or not, the outage certainly had a significant impact on some of Facebook’s partners such as Instagram and Vimeo.

Facebook outagejpg

Again, this is hardly the first time that we’ve seen an effect like this. In a significant outage last June, we shone a spotlight on Spotify, which saw a performance impact due to their Facebook login integration. The problem at that time was that Spotify – along with many other sites – had clearly not yet updated their tags to the asynchronous loading option that Facebook offered.

Turning the attention this time to news sites, many of which have Facebook tags such as subscriber and commenter login portals, or sharing buttons on their homepages and individual articles. Of the 47 different news sites that Catchpoint regularly monitors, nearly a third (15, to be precise) saw significant performance impacts from Facebook’s outage.

This brings into question just how much this has affected the service level agreements (SLAs) that Facebook has with its many clients. With a social media network, the different third party tags that they provide represent a potential pitfall for the sites that host them, and therefore an SLA should be in place to protect those sites from any outages that Facebook experiences. Asynchronous tags can help mitigate the impact that the third party has on the load time of the hosting page if it’s slow to load, but they do not solve the problem if the availability is zero.

That’s why sites should always have SLAs with the third parties that they host. We see such agreements with data centers, bandwidth providers, and SaaS tools, but for some reason they are virtually non-existent with even more basic service providers such as adserving networks, social media logins, or other providers that have a deep impact on the functionality of a site or app.

This has to change. The need for vigilance over who you host on your site is a regular mantra you’ll hear from us, but that vigilance isn’t worth much if it doesn’t come with a legally binding agreement that holds the third party accountable for performance failures.

Find scaling and performance issues before your customers do with our Introduction to High-Capacity Load Testing guide.

Topics:

Published at DZone with permission of Mehdi Daoudi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}