Facebook's Secret Sauce

I would say there have been Three Ages of the Internet.

The first was the Internet era proper, where only the US government and universities (and maybe a few other organisations) had it. There was email of course, and really cool stuff like Archie and Gopher (whatever they were) that you could access on text-based terminals.

Then there was the Web, which was nice and graphical and coincidentally came out at roughly the same time as the extremely popular Windows 95. The Web through Windows made the Internet something for regular folks, not just geeks. There was surfing and search, pleasurable as well as useful. The Web soon gobbled up email too (webmail changed the user-facing protocol from SMTP and POP to HTTP). And blogs became a way for the little guy to communicate his own views to the world instead of just consuming the output of established media. That was the first step towards mass participation.

Then there came Facebook. More than Picasa and on par with Skype, Facebook has suddenly made the Internet a must-have for everyone. I'm betting Facebook and Skype have driven Internet usage to new highs, both in terms of bandwidth consumed and in terms of market penetration. And along the way, Facebook has sucked the oxygen out of blogs. Ask me. I should know.

That deserves the title of 'third generation Internet'.

Skype's appeal is easily understood. It's the videophone of science fiction that the Telco monopolies never gave us. (Thanks, guys.) But what is it with Facebook? If it's just a place where friends hang out and exchange news and funny stories, would it really have become all that big?

I've been thinking a lot about this, because I'm a latecomer to Facebook, having resisted it for a while. Now I find I'm thinking of it as 'Wastehook', an addictive way to spend time that I later regret. What made Facebook so addictive to a person who resisted it so much to start with?

Yes, it's cool that we can keep tabs on all the people we've ever known. But there's more to it than that.

I think the one thing of absolute genius that Facebook has pioneered is the 'friends of friends' concept. 'Friends of friends' gives you visibility just beyond the horizon of your circle of contacts. You get to know of people who are somewhat interesting because of the friends you share. Sometimes, they turn out to be people you know too! Bonus points for the thrill in such cases.

'Friends of friends' are people our friends like and trust, and since we like and trust our friends, their friends are people we're already favourably disposed towards. We don't mind reading the things they say. Sometimes, they say witty and wise things. Facebook is a lot more interesting because of these people. It's not just our boring and predictable friends. It's these people, unknown but not quite irrelevant, who bring a bit of variety to the experience. It's somewhat interesting when a friend puts up photos of themselves, but a lot more interesting to read what their friends have to say about it, even if we don't know many of them. We can join in the conversation and politely add to what they're saying, and nobody minds. A nice polite party with decent people we could be friends with. That's Facebook.

'Friends of friends' prevents Facebook from becoming a stale backwater, a stagnant pond, an eddy in a stream. It's not quite the wide blue ocean, though. It's just a safe little harbour. 'Friends of friends' expands our circle just enough to make Facebook an interesting place to hang out, but not so much that it becomes overwhelming or irrelevant.

I'd say that's Facebook's secret sauce.

[What about Google+? Well, Google+ pioneeered categories of friends, but Facebook quickly neutralised that advantage. An authoritative source informs me that Google+ has a rough equivalent to 'friends of friends' based on followers and following, so the effect could be similar. But my prize for pioneering the next generation of the Internet goes to Facebook in any case, not Google+.]

Does Redis Undermine a Key REST Tenet?

While I have always admired the elegance of REST's resource model and its standardised verbs and status codes, there are two things about the RESTful style that I think are drawbacks when building complex applications. One is its client/server model rather than a peer-to-peer model, which I think would have been more generic and useful, especially when unsolicited notifications need to be supported. The second, which is what I want to talk about now, is the insistence on statelessness (or alternatively forcing anything stateful to be either managed by the client or modelled as a resource). This is an acceptable approach for application domain-specific elements, but there is also a domain-neutral class of session-stateful elements that are useful for providing Qualities of Service (such as a sliding window of message sequence numbers for reliability, or session keys for security). These are common requirements that any application may require. This kind of session state is fundamentally different from domain-specific state, e.g., a shopping cart in an e-commerce application which would not be relevant to any other type of application.

The lack of support for this application domain-neutral subset of session state within the RESTful style of design costs us the ability to provide Qualities of Service in a uniform way (which the much-disdained WS-* is able to do using standards like WS-SecureConversation/WS-Security and WS-ReliableMessaging). [Many will point out that RESTful applications can use SSL for security, but the SSL protocol is not itself RESTful, and it breaks the cacheability and routability of REST operations.] So Qualities of Service end up becoming an application responsibility in RESTful applications, which has always struck me as a bit of a cop-out on the part of the protocol.

REST has standardised many other aspects of interaction and turned them into a uniform protocol that interacting systems can use. I would like to see QoS-related session management also similarly standardised and "pulled into the protocol", even if that protocol is not HTTP but something else (WebSockets?).

I have often wondered exactly why statefulness is considered "evil". There are two reasons, as far as I can tell - scalability and failure recovery. Session state occupies memory, so holding session state for multiple clients impacts the scalability of a server. Also, holding session state within a server makes it less easy for clients to switch to another if the one holding its session objects goes down. We'll need to have session-aware clusters rather than stateless farms of servers to provide failover, which again doesn't scale linearly.

Two considerations make these arguments weaker.

The first is that we are not talking about application-specific session state like shopping carts and the like. We're talking about relatively tiny data elements that are domain-neutral and dedicated to providing Qualities of Service, such as sliding windows of sequence numbers for reliability, and security tokens for message encryption. These aren't huge, perhaps a few hundred bytes at most.

The second is that the advent of NoSQL databases has given us a way to delegate the storage of session state. It's now becoming recommended best practice to store session state in a NoSQL database like Redis rather than in memory. Delegating session storage is an alternative to session-aware clusters, since the servers can now be a simpler stateless farm and access the NoSQL database for shared session state. What's impressive about Redis in particular is that the complexity of its GET and SET operations is claimed to be of Order(1), i.e., constant time. This means that (in theory at least) one can increase the number of servers using a Redis datastore indefinitely with no impact on performance.

Now, a horizontally scalable farm of servers can share a Redis datastore and use it to hold the individual sliding windows of message sequence numbers for a number of clients, and also their security tokens. Scalability is no longer a problem, because the data elements are small and the storage/retrieval operations are of constant-time complexity. Failover is also not a problem since the servers themselves are stateless and switchable at run-time.

It would be good if a standard and application domain-agnostic mechanism could be evolved to provide security and reliability to REST-based interactions, using Redis-style scalable session storage. This may be the long-awaited successor to REST, which Rohit Khare's ARRESTED style attempted to do (but which has no practical implementation to date).

That will then leave client/server as my only bugbear with the RESTful style. We'll need another extension to handle that.

The Return of JavaScript - My Thoughts Crystallise

I wrote some months ago that JavaScript was back. I've been watching developments in that space with close interest, and a few glimmerings of "the right way forward" have begun to suggest themselves to me.

The first aspect pertains to the language itself. The JavaScript Renaissance has brought with it a desire to do things right the second time around. JavaScript doyen Douglas Crockford has lectured extensively (and even written a book) on the need to use only "the good parts" of JavaScript and avoid the bad ones. It's excellent advice, but to a new generation of JavaScript programmers, I suspect it may not be enough to post warning signs around bad features. We need a way to make it physically impossible to use JavaScript's "bad parts".

Enter CoffeeScript. While I haven't played with it too much, I like what I see here. [Update 24/09/2011 - I *have* played with it for a few hours now, and I really like!] There has been some skepticism about CoffeeScript from a section of the JavaScript old guard, but that's to be expected. The best answer to such skepticism is from ThoughtWorks's latest Technology Radar document, which is well worth a read in itself.

First, even if it seems a trifle off-topic, read what Thoughtworks thinks about GWT, which is a way to write visual components in Java and have JavaScript-based widgets automatically generated for a web application that runs within a browser:

GWT is a reasonable implementation of a poor architectural choice. GWT attempts to hide many of the details of the web as a platform by creating desktop metaphors in Java and generating JavaScript code to implement them. First, in many ways, JavaScript is more powerful and expressive than Java, so we suspect that the generation is going in the wrong direction. Secondly, it is impossible to hide a complex abstraction difference like that from event-driven desktop to stateless-web without leaky abstraction headaches eventually popping up. Third, it suffers from the same shortcomings of many elaborate frameworks, where building simple, aligned applications is quick and easy, building more sophisticated but not supported functionality is possible but difficult, and building the level of sophistication required by any non-trivial application becomes either impossible or so difficult it isn’t reasonable.

Now read what Thoughtworks says about CoffeeScript:

Some readers may be confused by our advocacy of Coffeescript given our general dislike for GWT, because on the surface they seem similar: tools that generate JavaScript. However, it is the level of abstraction that differs. GWT has an elaborate component model, which tries to hide details about the underlying language (JavaScript) and platform (the web). Coffeescript tries to make it easier to write proper JavaScript, avoiding pathological but default “features” of JavaScript, and does not build a layer that tries to insulate you from the platform.

I think they've nailed it. I have been ambivalent about GWT for a while, but couldn't quite put my finger on why (i.e., it's a "reasonable implementation of a poor architectural choice"). They've also very cogently argued why CoffeeScript doesn't fall into that category.

So my first takeway from the JavaScript Renaissance is that today's developers should code in CoffeeScript and not in JavaScript itself. If Java and Scala are two languages that compile to Java bytecode and run on the JVM, then think of JavaScript and CoffeeScript as two languages that "compile to JavaScript" and run within a JavaScript engine. The runtime behaviour is unchanged, but you use the language that works better for you as a developer.

CoffeeScript is JavaScript with the sharp edges removed. I'm sold. [There is an issue with E4X, which I'll cover when I talk about Nodejs, but it applies equally to CoffeeScript. In short, there's no support for E4X, and I want it!]

Beyond the choice of language, the direction is not so straightforwardly clear. It's tempting to say that the future of JavaScript on the client is CoffeeScript plus jQuery, and the future of JavaScript on the server is CoffeeScript plus Nodejs. But there are some issues.

To paraphrase Thoughtworks's critique of GWT, jQuery is an elegant way of working with a horrible object model (the DOM). I don't know if there is any way to replace the DOM with a better client-side abstraction, but until then, the best of client-side goodness will remain somewhat unsatisfactory.

Nodejs is the server-side angel in white from all accounts, but I've heard some valid grumbling about Node as well. The Spanish outfit ASPL has a BEEP implementation called jsVortex. This JavaScript-based server pre-dates Nodejs, and ASPL was reportedly keen to explore Node as the underlying platform for the next version of jsVortex. However, they quickly realised that Node had no support for TLS at its core. This is not the same as supporting HTTPS, because HTTPS support obviously exists in Node. Think of TLS as HTTPS-like capability for any protocol, and since BEEP is a framework to create protocols à la carte, and since security is a ubiquitous and pretty strong requirement for most protocols, the lack of TLS support within Node is a serious deficiency for them and for anyone who wants BEEP on the Nodejs platform.

[Most people might go "BEEP who?", but in my opinion, this is a technology that was sadly delayed by over a decade, perhaps because of personality politics caused by creator Marshall Rose's less-than-smooth interactions with powerful members of standards bodies, who then blocked BEEP from becoming a standard until very recently. If we'd had BEEP 15 years ago, I suspect SOAP and WS-* would have looked very different, and perhaps REST would have looked different too. That's how powerful it is, and I still think it will change our lives one day.]

Well, so there's a piece of work to be done to enable TLS within the core of Nodejs, but that's not all.

WSO2's Mashup Server was another under-appreciated piece of server-side JavaScript from many years ago, and one of its best features was its support for E4X. It's understandable why WSO2 would be keen on E4X, because their enterprise middleware suite is based on SOAP/XML, and a JSON-only approach would hinder interoperability between Mashup Server and the rest of their product suite. Like everyone else in the server-side JavaScript space, WSO2 is looking at Nodejs as a possible underlying platform for the next generation of Mashup Server, but the leading lights of Node are reportedly not keen on supporting E4X at all. I wonder what the problem is. Surely supporting XML (through E4X) in Node wouldn't come at the cost of supporting JSON! At least the CoffeeScript guys have an excuse for not supporting E4X (not that I'm letting them off the hook for that reason!) because not all browsers support E4X and they don't want to be browser-specific. But Nodejs? I think the throat to choke is V8. If V8 supports E4X, then so will Node, and then there'll be pressure on CoffeeScript to support it too, since both Mozilla and V8 do. I asked them for this 3 years ago, but no dice. Ahem, Google...?

Then there are the various flavours of web frameworks for Nodejs (Backbone, Express, Geddy, etc.), but where is SpringFramework.js? Where is the Grails, Roo or PlayFramework equivalent? I certainly hope server-side JavaScript revs up to an equivalent level of maturity as server-side Java double quick. [Server-side Java meandered a fair bit and had many mis-steps along its journey, so server-side JavaScript could get there far faster by learning from Java's mistakes.] Judging by the level of activity in the Nodejs ecosystem, we need not fret on this account. It's just a matter of time before the current effervescence and flux give way to a stable yet rich multi-layered platform.

So that's my current view in a nutshell:

* Use CoffeeScript and not raw JavaScript from now on

* jQuery is great on the client side, but will no one rid me of this turbulent DOM?

* Nodejs is The One on the server side, but lacks some critical features (e.g., TLS and E4X). I don't know if they know about broken TLS, but they don't seem to think E4X even belongs in the to-do list, which is a pity if true. I'd like to be proved wrong.

* We need better server-side frameworks, and these are already on the way. We just need to wait till the dust settles to pick a winner.

I'll post updates as my view evolves.

The Zen of Tight Coupling and Loose Coupling

After my talk on SOA at WSO2Con 2011, I was inspired to create this fun, Zen-style instructive presentation on what really constitutes tight and loose coupling.

Enjoy!

A Geek's Dream Address in Colombo, Sri Lanka

With apologies to Freddy of My Fair Lady:

I have often walked down this street before;
But the pavement always stayed beneath my feet before.
All at once am I several stories high.
Knowing I'm on the street where you live.

[...]

People stop and stare. They don't bother me.
For there's nowhere else on earth that I would rather be.
Let the time go by, I won't care if I
Can be here on the street where you live.

This road was very close to the Cinnamon Lakeside Hotel where I stayed when I was in Colombo to attend WSO2Con 2011:

That's the address I'd like to have if I ever relocate to Colombo :-)

Back from WSO2Con 2011

I'm back home in Sydney after a very enjoyable week in Colombo attending WSO2's 3-day conference as well as the pre-conference and post-conference tutorial sessions flanking it.

Over the next few days, I'll be posting a detailed trip report with my impressions of the highlights of the conference. In this post, I want to record my overall impressions.

I was highly impressed by a few things.

One, I could not but be impressed by the rapid rise to prominence of a visionary software company. The "Open Source middleware" niche has only one serious player with a complete range of offerings. That's WSO2, a five year old company. This relative newcomer is giving established players like IBM, TIBCO and Oracle a good run for their money. I have no doubt that middleware prices will come down in a few years from their current extortionate levels to something much more reasonable, and the credit will go in large measure to WSO2's disruptive impact on the market.

Two, I also had to marvel at the achievements of a country. I spoke to a few Indian delegates at the conference, and we all agreed that in spite of the huge number of Indian IT professionals and some very large Indian IT companies, no one in India has achieved (or even attempted) what a relatively small Sri Lankan company (WSO2) has pulled off. In hindsight, it shouldn't have been too hard. Take some software products from the Apache stable, enhance them to make them usable by corporate customers, release the lot again under an Apache licence, and charge customers for just support and professional services. It takes some vision of course, but a lot more courage and conviction, and WSO2's CEO Sanjiva Weerawarana has that in spades. It has been his determination that Sri Lanka should be a leading Open Source nation, not just in terms of usage but in terms of contribution, that has led to the success of WSO2. Today, I'm told Sri Lanka ranks third in the world in terms of Open Source contribution, behind the US and Germany. It would be good if Indian companies and professionals took inspiration from their smaller neighbour and started contributing to the world through Open Source.

I was also very glad to see the number of Sri Lankans (not just WSO2 employees but also others from Universities and the like) using Ubuntu Linux on their laptops. I felt right at home after a long time of appearing like a curiosity. Indian and Australian professionals, on the other hand, seem to have sold their souls to Microsoft (or else to Apple). Any argument that Linux is "not there yet" is just an excuse. These people have been using Linux exclusively and are none the worse for the experience. They also have a bit more cash left in their pockets as a result of their choice :-).

Three, I was very impressed with the way the conference was organised. Everything went like clockwork. Events started and ended (largely) on time with very few overruns. Sri Lanka follows Indian Standard Time, but fortunately, the other connotations of the term have not been infectious ;-).

There were distinguished speakers from around the world, giving the conference an international flavour. This was not just a Sri Lankan affair.

IBM Fellow C Mohan giving the main keynote speech of the conference

Gregor Hohpe, author of Enterprise Integration Patterns, giving another keynote speech on the final day of the conference

eBay's Distinguished Architect Sastry Malladi gave a talk and participated in a "fireside chat" to talk about, among other topics, eBay's use of WSO2's ESB to process a billion transactions a day

David Schumm of the Institute of Architecture of Application Systems (IAAS), Stuttgart, talking about BPM research at his institute based on WSO2 Business Process Server and similar products

Dmitry Lukyanov, Head of Integration Solutions, Alfa Bank, Ukraine, talking about his bank's positive experience with the WSO2 middleware suite

Cognizant's Principal Architect Dipanjan Sengupta's presentation demonstrating the interoperability between IBM's WebSphere Service Registry & Repository (WSRR) and WSO2's Governance Registry, was very well received

Catering was top-class, though some of the Western delegates found the food excessively spicy. (I had no complaints, except that I have probably put on some weight ;-). The hotel accommodation and local transport were great and there were no snafus of any kind. It was testimony to the conscientiousness and attention to detail that the people involved displayed.

Four, I realised that the conference was a showcase not just for WSO2's technology but also for Sri Lankan culture. Every evening, after the main technical events were over, there was some cultural program or the other that was fascinating. Day One had an elephant ride (with people able to feed the elephant by hand before the rides got started).

There was also a very interesting talk and slideshow by a conservationist on "human-elephant conflict" and possible solutions, with very moving and often tragic stories about individual elephants. Then there was a set of folk dances that I can hardly do justice to with mere words or even pictures.

Day Two's cultural event was a Jam Session, where WSO2's employees enthralled the crowd with their musical talent.

That, and the musical talents of CTO Paul Fremantle and VP (Business Development & Product Design) Jonathan Marsh, made me think one needs to have musical ability as well as software competency in order to work at WSO2!

Fremantle and Marsh present a musical mashup (In India, it would be called a Jugalbandi)

On Day Three, a well-known local group "Bathiya and Santhush" (rather like Shaan or Hariharan in India) performed and the whole crowd danced to their music. The lyrics were in Sinhala, but the beat had universal appeal.

That was WSO2Con at a glance, and I'm sure next year's event will be even bigger and better. Those who missed this year's experience should try not to miss the next!

(Disclosure: I am in advanced negotiations with WSO2 to join them in a suitable role reporting to the CTO. While this obviously makes me an interested party, I promise not to make any statements or representations about the company and its products that I do not sincerely believe in. My decision to consider a position with WSO2 is itself driven by my conviction that (1) their product suite is fit for purpose and very good value for money, (2) the company operates in accordance with the ideals of Open Source - there is no proprietary version of any of their products, and (3) there is a good cultural fit because I like the people and the company culture (they never use the word "resource" for people) and found myself getting along very well with people across the organisation. Regardless of my relationship with the company, I'm determined to remain a voice that readers of this blog can trust, because I'm acutely conscious that my independent stance on technology matters has always been my biggest source of credibility as a commentator.)

Gregor Hohpe's Talk at WSO2Con 2011 on Enterprise Integration Patterns

I had the pleasure of attending Gregor Hohpe's keynote speech on the third and final day of WSO2Con in Colombo. (The conference was a hugely successful affair, by the way, judging by the quality of the talks and the fact that the attendance far exceeded expectations.)

Gregor's talk was a reference to his famous book "Enterprise Integration Patterns", and was titled "Enterprise Integration Patterns - Past, Present and Future". (For all his achievements and fame, Gregor is an endearingly unassuming man, as I found when I spoke to him person-to-person. He's also a very humorous speaker, and kept the audience in titters during his keynote.)

When he came to the Future part of the talk, one of the many gems he let slip was his insight that his famous book was really about Messaging Patterns, in which case it would be the first of four volumes (the other three devoted to Conversations, Processes and Events). He specifically called for two things from the audience and the community in general - some ideas on notation for these more complex patterns, and for exerting guilt-inducing pressure on him so he would actually write the books!

I have been interested in the Distributed Computing area for a long time (I would in fact have called these "Distributed Computing Patterns", because they are not specific to enterprise contexts, and the purpose of the interactions isn't always integration).

In any case, this is how I see the four volumes of the book that Gregor described, and how they would relate to each other. I would like to mail him on these ideas and I'm sure I'll have an interesting conversation.

"Messaging" is really the most generic description of a class of distributed computing systems. It also takes a top-down, system-wide focus (a "God" view). One can think of specific subsets of these generic interactions, and one can also shift focus from the overall system to a particular node. So, as we add a statefulness aspect to messaging, we begin to enable conversations. And as the purpose of the conversations becomes coordination (one participant controlling the others), we have (process) orchestration. Somewhere along the way, we can explicitly consider multi-way messaging, i.e., between multiple peers.

When we shift focus to a single node, we have an event-driven system because incoming messages at any node are "events". And when we take a set of event-driven nodes and consider them in aggregate, we have a choreographed system, where each node is ignorant of the existence of other nodes and only responds to events, and the system as a whole "works" because of these inter-related events. The design of a choreographed system is really the design of appropriate events, since the previous step (event-driven systems) has already designed the behaviour of the individual nodes.

So that's my simple view of the Distributed Computing universe. I also have a more complex diagram that I created a few years ago to explain how the various facets of distributed computing are related.