Brandon Smith

OSCON '06 Review Four: Codependency in the Age of Mashups

31 July 2006

David Sklar gave an excellent presentation about service dependency in the age of mashups. The irony of the presentation is that David's connection to the projector kept crapping out every 15 seconds or so. A presentation on dependency when a dependency to the presentation kept failing. Wow. Sorry I had to spell that one out.

I've compile some notes from David's session:

Web2.0 is:

  • Always on
  • Depends on remote resources
  • Haps parts that are out of control of the primary creator
This is new-ish...Or is it?

Thingsto think about Web 2.0 and mashups:

  • Dependency
  • Risk Lock-in
  • Uptime
  • Outage
  • Integration
  • APIs
  • Timeouts
  • Injection Attacks
  • Service Guarantees
  • Use restirctions
  • Non-portable data
That's alot to consider. Often its neglected.

Today's Topcic:

  • WOPR, give us grace to accept with serenity the dependency mitigation strategies that cannot be implemented, courace to implement the strategies which should be implemented and the wisdom to distinguish the one from the other.

  • What is your app dependent on?
  • What happened to the app when one of those dependencies has a problem?
  • Today's focus is primarily on web service consumers rather than produces.

"Dependency"= Not Yours

  • Physical control
  • Ornganizational Control
  • Intellectual control

Whatare your dependencies?

  • Server
  • Content created by others
  • Real-time external network calls
  • Internal network calls
  • Per-machine software
  • Per-machine hardware
  • Power+networking
  • Code
  • Who wrote the code?
  • Who know how the code works?
  • Who wrote the docs?
  • Who knows the places in which the docs are wrong?
  • Who knows how to hire more people who knows what they need to know?
  • Business
  • Who supplies data feeds?
  • How many of your co-workers are in the national guard?
  • What are your copyright and patent risks?
  • What do your SLAs say?
  • Are the penalties in the SLA really helpful?

Uptimeis not binary

  • Mitigate real-time dependencies with mdoes of degradation based on:
  • Data freshness
  • App features
  • Read-only/read-write data

Data Freshness

  • Avoid live web service calls when possible
  • Make calls "offline", sanity-check results, and cache
  • Build local data store (when possible) for when remote service has blips

Features

  • Segment your app into potentiall non-interdependent parts
  • Can a detal page go without its map?
  • Can you turn off an ad network?

Read/Write

  • Perhaps just for internal issues, but:
  • Provide statis/read-only access to app whil preventing data-changing operations
  • Feature segmentation on personalization

Provider Switch

  • Use ad netwokr G instead of Y
  • Use map provider Y instead of G
  • Lack of common APIs can requrie custom development...look for the rise of meta-API standards
  • APP, S3, "ad HTML" already filling that need?h

Monitor

  • How do you know when something needs to change?
  • Automatic degradation
  • Alers based on timing + response content

with manual switchover

Itall comes back to balance

  • In the end, everything really is insurance
  • Mitigation cost <= (occurrence probability * occurrence cost)
  • Cost = money + goodwill
  • What are the likely issues you will run into?