I love it when a mashup comes together!
“I love it when a plan comes together.” Those were the memorial words spoken during many episodes of “The A-Team,” a U.S. television show than ran from 1983 through 1986. During the show, a group of good-hearted Army veterans would ride to the rescue of an opposed.
The word “ride” is meant literally, as the team’s mechanic would often improvise a single-use mobile combat vehicle using scrap parts, baling wire and duct tape.
“The A-Team” episodes were funny, if a bit predictable. What I remember most fondly were the montages where Sgt. “B.A.” Baracus assembled the impressive, yet patchwork, combat vehicle.
His work reminds me of what’s going on today in the world of mashups, using internal applications, commercial components and Internet-based APIs. Need a calendar? Repurpose the Google APIs. Need some storage? Throw something onto Amazon S3. And so-on.
While I’d be hesitant to rely upon ad-hoc mashups for a true business-critical applications, it’s hard to deny that they offer a great blend of agility, rapid prototyping, platform neutrality and cost savings. The benefits are seductive – and genuine. On the other hand, ad-hoc mashups don’t offer any type of guarantee on scalability, reliability or even consistency. Documentation? Ha! Support? Good luck! Predictable performance? In your dreams.
What’s worse, of course, is that the more we use mashups – and the more often that the things that we’re mashing up are themselves mashups – the poorer our performance, scalability and reliability are going to be.
If your application depends on two services that each have 99% uptime, then your app will only have 98% uptime. If your app needs ten services that each have 99% uptime, then you’ll experience 90% uptime.
The combat vehicles built by “The A-Team” were perfect for their one-time use, which generally required intimidating some urban bullies. They can’t be compared to genuine mil-spec equipment.
Similarly, ad-hoc mashups are ideal for appropriate uses, including proof-of-concept systems, throw-away apps and rapid prototyping. But don’t even think about driving one into a real battle.