One concept I try and use in understanding the new world of feeds, open APIs and brittle but powerful web services, is what I call Feed/Portal duality. That’s a play on Wave/Particle duality (please excuse the spoon-feeding).
Why do I think its important to hold two slightly contradictory notions in our head as we offer web services and so on? Because we’re creating gardens without walls- we have to make people want to hang around in them, rather than being forced to.
How many people read my blog? I have no idea. I can look at page views, and or or numbers of bloglines subscribers, or look at alexa, but the point stands that there are two radically different mechanisms at hand for touching my content-one is my url, one is my feed. Oh yeah- then there is feedblitz, for people that prefer newsletter modes.
As many of you are aware, RedMonk.com is completely lame from a portal stickiness standpoint, which is why we’re working on a redesign right now. But our feeds rock, because the content is rich. So when it comes to Feed/Portal duality we’re definitelty skewed to Feed.
Intriguingly – Google is considerably stronger on Portal than feed/APIs. That is – people go to Google to do things. Yahoo would appear to have more APIs and feed-based services available, but hasn’t found a way to succesfullly turn its Feediness to dollars.
This morning I read VC Fred Wilson on The Bad Script Trip. While Fred has made his blog far stickier from a portal point of view, by adding a bunch of services into the mix using nice powerful brittle tools, he got into trouble when the 130 small pieces, loosely joined, started acting up. So by concentrating on Portality at the expense of feediness, Fred “broke” his own web presence. Is he going to stop adding all the new cool widgets to the site because of recent performance issues? No – he is coming down on the side of Portality.
Have I got to the point yet? Getting there. So while Cal Henderson’s architecture for Flickr undoubtedly scales, one of the things that makes it scale so well is the offline client the user runs on their machine, to upload photos.
So what are the feed/portal duality implications of the fact “over 40% of Salesforce.com’s traffic is Web Services“, according to salesforce.com CTO Chris Fry?
First off, read the articles, and then try and internalise the challenge of developing services for salesforce.com, which have to scale both in the portal, but also in the cloud. And finally understand why Chris knows that join functionality is so important– its good for user/developers, because they need it, but also for salesforce itself, because adding the functionality will reduce strain on its resources.
People building web presences, applications, and so on will increasingly need to think about Feed/Portal duality when they build out their infrastructure. Its just as important, if not more so, that the APIs scale, than the site does. We need to think about Portality and feediness, or whatever you want to call these things. Suffice to say there are two different axes of richness to consider.
One way to ensure scalability in the feed dimension is open data. Allow a developer to suck a dataset once a day, or whatever, that they then hit, rather than hitting your back end directly ever time, and you’ll have more scale.
Oh dear- I seem to be describing a three tier architecture. So much for feed/portal duality… Likesay, there is nothing new in IT. But the more open your data is, the less you need to worry about the resources required to scale it effectively – that might be a useful insight.
Why should enterprises care about feed/portal duality? One simple reason: related design patterns are going to dictate service oriented architecture (SOA) choices. What does scale mean in SOA? Are you processing locally or externally? There are two related focuses: scaling up and scaling up for consumabllity, scaling out and scaling out for consumability.
Would love some feedback on these ideas, if you have any. Thanks.
disclaimer: I have no financial relationship with salesforce.com