Mashup Fragility
Sunday, June 4th 2006 | Ismael Ghalimi
Online composite applications — also known as mashups — are a great way to build new functionality better, faster and cheaper. Problem is, the more individual components are used, the more single points of failure are created, and the more fragile the application becomes. Several approaches can be used to work around this problem.
Replication
For commodity components that are available from multiple sources — stock quotes for example, the invocation of a failed remote service could generate an exception that would be caught by an exception handling procedure responsible for invoking a backup service that would offer the exact same piece of information, through a similar interface.
Passive Caching
Some feed processing services such as Feed Digest already cache the content of feeds they aggregate. In a similar fashion, most online services should provide caching for the information they depend upon, and provide a mechanism for notifying consumers — JavaScript badges or end-users — that they are accessing potentially-obsolete information.
Active Caching
When content is aggregated on a web page from multiple sources using JavaScript badges, active caching could be enabled by using a remote caching server. Whenever the badge would receive content from a remote service, it would store a full copy onto the remote caching service and use the last copy stored in the event that the remote service would go down. The same approach could be used when aggregating content on the server side.
Monitoring
When using service cascading, identifying that a service went down can be more difficult that it seems, because downstream services might keep publishing good-looking information based on default values or caching mechanisms. In order to address this issue, active monitoring services could be developed. They would constantly monitor all services used in a cascade, poll them and compare outputs against pre-defined acceptable ranges, then notify application owners whenever something is deemed to be wrong.
These are just preliminary ideas for adressing a problem that will become more critical as more and more users rely on Office 2.0 for getting their work done. I am sure that many other solutions will be devised, and eventually provide a distributed computing infrastructure more reliable than anything available today. In the meantime, I have created a new entry into the Office 2.0 Bug Tracker.
UPDATE: FiveRuns could be used for monitoring.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mashups don’t have SLA, service governance, or fail-back policies, so they’re not reliable for time critical applications.
But that’s exacly what makes them better, cheaper and faster. Most applications are just not that time critical, people are very adept at routing around failure, and things that are simple to build are also simple to fix.
So instead of dealing with plumbing, you just deal with end-user needs. And they keep the cost low, most of the good ones are weekend hacks.
Trying to fix mashups would end up breaking them.
Assaf,
I agree with the analysis, and the term mashup might not be appropriate for what I am describing. Composite application might be better suited, even though it usually relates to something else. I need a term for production-ready mashups. Any idea?
Then you have to start with a definition of production ready, state the expected QoS and work backwards from that.
Let’s say you need five nine uptime and have a five year roadmap for your application. Choosing replication assumes redundancy, and while you get redundancy with stock quotes and weather reports, you don’t get that with eBay listings or Amazon reviews. Those are single source. If they go out of business, change their API or simply decide to block you, your application goes down. You need some sort of agreement.
Let’s say you want a badge on your corporate Web site, and you found the right one. But it bothers you when it disappears because their ISP is down. Should you cache?
Now, what would happen if they decided to change their color scheme to flaming red and put ads for p*rn sites? You might want to get the data instead, store it locally, and then render it yourself.
Isn’t that service integration?
Assaf,
It is. I just would like a catchier name for it…
My bias is showing. I think mashups are great because they’re simple to build, easy to use and cheap to own. And that just means you don’t have to worry too much about piping and infrastructure. Enterprises need more mashups, not less.
It’s the 80/20 rule, think Excel instead of nine fives. Sometimes you absolutely need all these features, cost aside. But most of the time, you want something lighter with less barriers to entry.
There’s clearly a place for provisioning and redundancy and end-to-end management. But there’s also a place for rapidly building new things. If you can rapidly build it, you can rapidly change it. And if you can rapidly change it, you can rapidly improve on it.
Sometimes you improve because something broke, most often because something better comes along. Instead of optimizing for “what if it breaks?†you’re optimizing for “what if I want to change it?â€
So you call them Enterprise Mashups then, right?
Interesting conversation gentlemen. Assaf, I like your rationale behind Enterprises needing more mashups. What do you think is the size of the market for these quick Enterprise mashups? Do you see Enterprises creating a culture of mashup creation across their communities?
I see enterprises creating a culture of mashup creation in their community and gaining from that. There’s a subtle difference which also answers your first question: the size of the market can be as little as one.
Say you’re building chips for use in cell phones. The size of your direct market are companies that make these phones, you can count them on one hand. But your community is made of your employees, your customers’ employees, your suppliers, your outsourcing partners, your consultants, etc.
If you can make them more productive, get new products out faster, cut down development cycle, find cheaper sources, predict market trends, you’re ahead of the game.
The traditional approach to integration (EAI, portals, application servers) came out of client-server but ended up being the new mainframe. It takes too long to get anything done.
We need to bring back the PC running Lotus 1-2-3. That way users at the edge can self-help themselves to something better. Maybe you’re creating a mashup that only two people use, and it’s a horrible hack done in a day, but it could end up saving millions in sourcing materials at lower cost.
You are right. Maybe self-help needs to be taken a step ahead. Let the users at the edge make their own mashups. Take away the ‘hack’ part of it and suddenly you have interested users giving themselves mashup capabilities that end up saving the millions in sourcing costs or helping them get products out faster or such.
car play mat…
Relevant search results and links for car play mat…
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment