Posts Tagged: facebook

Programming / Technology — No Comments
1
Jun 08

Facebook chat uses Erlang to scale

I started playing with Erlang last year. Mostly that meant reading the Joe Armstrong book, looking at ejabberd and writing a little code. Sadly, I’ve not had the chance to go much beyond the “playing” stage. Anyway, I’ve got a soft spot for functional languages like Erlang since my Programming Language Theory class in undergrad where we used ML. I especially like the way Joe and the rest of the people behind Erlang have built it for concurrency via tiny processes that share nothing and have provided a framework for building apps that know how to operate correctly in soft-realtime. It’s a very different way of thinking about building systems and seems to be remarkably effective.

The Erlang guys have to be feeling pretty good to hear that Facebook has used Erlang as a core component of their new chat service. (High Scalability also has a good writeup.) As Facebook engineer Eugene Letuchy describes it, their implementation uses XHR long polling which means tons of open HTTP connections. Spread this out over 70 million potential users and it’s not hard to see that Apache would break down pretty quickly. Basically it sounds like they have tons of Erlang processes servicing these connections and holding messages and presence events for users in memory if there’s not an open connection to the client.

Eugene mentions the challenge of delivering presence information as being more difficult than real-time messaging. (Something I thought a lot about when building Effusia.) He lays out the issues inherent in broadcasting presence on every state change in the form of a nasty worst-case asymptotic complexity:

The naive implementation of sending a notification to all friends whenever a user comes online or goes offline has a worst case cost of O(average friendlist size * peak users * churn rate) messages/second, where churn rate is the frequency with which users come online and go offline, in events/second.

However, he doesn’t really go into any detail on how they solved this problem. I can only assume they used some form of periodic polling on a need-to-know basis and/or coalescing friend presence updates in such a way that they’re only occasionally sent to a user.

A few other interesting notes… Apparently they used C++ to do the chat logs as Erlang is not that great at raw I/O. They also apparently use Thrift to glue everything together. (Reminds me I need to look into Thrift in more detail.)

Technology — 3 Comments
24
May 08

Towards the Web OS

Cesar Torres analyzed the new Facebook profile design yesterday as did TechCrunch. Both come to the same conclusion: Facebook is trying to become a web operating system. Both cite the use of a Mac OSX-style menu design (a weak indicator of an “OS” in my opinion) but Cesar goes farther to mention Facebook’s application platform, chat client and data portability developments. So, does an app platform plus a menu bar plus chat an OS make? Even a nascent OS? My answer to that is that Facebook, while acting more and more like a web-based OS is just a part of the Web OS.

What is an OS?

The whole concept of what makes an OS is a bit hard to pin down. At this point, I’d love to offer up the definition of an OS from my undergrad operating systems book but it appears to be missing chapter one. Suffice it to say it would have said something about CPU management, process management and probably something about batch jobs (it was really old when I got to it in 2000). Instead I’ll quote Wikipedia’s article on the topic:

An operating system is the software component of a computer system that is responsible for the management and coordination of activities and the sharing of the resources of the computer. The operating system (OS) acts as a host for application programs that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications.

If you’re a programmer and you see something that promises to relieve you from the details of something, you know you’re seeing an abstraction. Programmers love abstractions. In the name of simplification, we layer abstraction after abstraction on top of each other until we feel like we’ve got something easy enough to be productive. (And then we write something on top of that.) We write an OS to hide the hardware, we write programming languages that hide the details of the OS, we write APIs to make tasks easier in the programming languages and on and on and on. Fundamentally, an OS is just an abstraction over the bare metal.

This definition of the OS as an abstraction layer for application development is, of course, pretty technical. I would say that most people consider an OS (if they were to consider it) as the thing that lets them run their email app, their word processor or their web browser. In general, it should fade into the background and let people get on with what they want to get done using their actual apps. If it does bring itself into the foreground it should be by providing shiny eye candy and not with shiny blue screens.

Here’s the kicker though… Beyond just running our apps, we also expect our OS to allow them to share data. As OSes have evolved, we’ve come to think of them less as a resource management tool and more of a collection of useful apps that can all work reasonably well together when facilitated by the OS environment. This goes back at least to the Unix concept of small programs that take an input, perform a useful function and provide an output. This allows for all sorts of nifty command line piping and chaining of outputs to inputs; all facilitated by the operating system. I believe you could say this pattern is the precedent for today’s mashups.

So here’s a working definition. An OS is the thing that manages the hard low-level stuff so people can write apps so we can get things done by using and combining those apps. So does a web OS do this but just on the web?

Are we there yet?

I think we do have a nascent Web OS but it’s not one that’s provided by a single entity. It’s not Facebook or Google. It goes across the web as a whole. Each of these services provides a component of the overall experience much in the same way that Unix utilities do. Though Facebook search reminds us of OSX Spotlight; search on the web OS is located at google.com (for now).

Of course, the Web OS is being built beyond just our user experience interacting with web sites through our browser. The data sharing of the Web OS is being enabled by a host of technologies available to application developers. At the lowest level, we have the fundamental architecture of the web itself, HTTP, which allows for any kind of resource to be located and accessed. We can use HTTP to access any sort of data, but the critical types of data to the web OS are the meta ones that we can use to actually describe data: XML, JSON and even HTML. These form the basis for all the APIs we’ve come to know and love from all the web applications out there that have our data. Over the past few years we’ve begun to scratch the surface of what we can do when we can pipe information from one app to another via the environment provided us by this Web OS. From Google Maps mashups to the nearly infinite number of Twitter apps, we’re beginning to leverage these services in all kinds of ways. Once application developers can begin to rely on these services to abstract away the complexity of performing certain tasks whether that’s raw data storage, identity, search, messaging or the social graph then we’ll have a true Web OS.

Right now, there are still too many barriers. Many (maybe most) apps don’t allow data to move from place to place or put up walled gardens around what APIs and platforms they do offer. With data portability, we’re moving in the right direction (primarily with social data at least), but we’re not there yet. And, of course, there are still tons of applications that don’t (and may never) live in the cloud and so can’t participate fully in the emerging OS.

If we’re not there yet, where are we going?

We’ve still got a long way to go yet with the Web OS, but the pieces are emerging. Applications are moving into the cloud and we’re in the early days of programmatic communication between our various web utilities. We’re progressively abstracting away the hard parts of building really complex and powerful systems. That’s why programmers obsess about abstractions; they make hard things simple. And when hard things become simple, you’ve just taken a step to making even harder things possible. Ultimately the Web OS goes way beyond the placement of menus in Facebook, it will provide us the platform to make the previously impossible possible.

Social Networking — 2 Comments
21
May 08

Serving the social graph and keeping the lights on: What Facebook and MySpace have in common with the power company

Mashable has a post today discussing Facebook’s 10% traffic decline from March to April as well as their year-on-year slowdown from 98% growth to 56% growth. This just adds to the recent meme of “Facebook kind of sucks” that has been going around for a while. For example RWW wants to make Facebook useful again and Scoble tweets about his version of the malaise.

The first issue seem to be with Facebook apps. They’re too spammy, too messy on the profile page and too pointless. I have to agree with this point. I just don’t know that there was so much missing from my poke experience that I need to be super-poked (or banana kicked or abducted by aliens or really receive a picture of a freaking cookie – but hey, I don’t have a $500 million company so what do I know?). Facebook is working to solve this problem by tweaking privacy settings, application notification rates, etc. Their long-awaited profile redesign should help as well.

The larger issue in my mind is that once you get on Facebook and get over the initial high of finding people you’ve not talked to in 7 years and exchanging a few wall posts, there’s really not that much to do. It’s great to connect with these people and get periodic updates on what they’re doing via the News Feed but it just doesn’t create a terribly sticky experience. There are some aspects of Facebook with real utility such as groups and events but they are really just small features that really aren’t much better than the alternatives.

I think the reason for both the issues above is that Facebook and MySpace are each aiming to be the utility company for social networks; ubiquitous and underlying everything else. Facebook even (in a phrase I have to feel like comes straight from Zuckerberg) calls itself a “social utility”. The problem with this approach is that utilities are not where the action is. Very few of us think about how awesome our power company is for powering our TVs; we just expect to pay a reasonable price and for the electricity to never go out. Utilities are what have to exist so we can get to the good stuff.

With the advent of the triple data portability initiatives from Facebook, MySpace and Google over the past couple weeks they’re taking even more steps towards becoming these utilities by providing their social graph data to others. In my opinion, it will be “the others” (and possibly Google) that benefit most from these developments. Sites targeting highly motivated niche communities will be able to spring up and use social graph data without having to force users into yet another “find and friend” cycle. Unique user experiences can be created that exploit the webs of links between people in the same way links between pages have been exploited on the web. Ultimately, these sites and applications will be the destinations for users looking to get value from social networking. We’ll go there, do the fun stuff (and maybe even spend the money). We’ll just expect Facebook and MySpace to fade into the background and keep the lights on.