David against Goliath: MySites versus the Facebook and Google App Engine

Many developers have asked us how MySites Services compare to apps on Facebook or Google App Engine, so here is a comparison explaining a bit why we think development on MySites is a lot smoother than on Facebook and Google App Engine.

All three contenders use different technologies for development (like Django or FBHTML or JavaScript) we don't want to compare them to each other in detail but rather look at how complex development is in general by looking at how many technologies a developer needs to understand to use the platform and how easy they are to use for normal end users.

We are looking at all the difficulties developers on the various platforms have to overcome to write their own apps with the various engines. The more difficult something is, the more points we give, as you need to climb more hills. In total we think that MySites offers the best balanced solution that lets you be more productive than on any other platform.

1. Getting Started

Getting started with a new technology is always hard. One wants a super simple intuitive technology with good examples, technology and a supporting community. The barrier to entry is that developers need to know an ever increasing catalog of technologies.

Facebook: If you're developer on Facebook you need to understand SQL, FBJS, FBHTML, Unix (for the hosting), also existing Facebook apps are not OpenSource so you cannot improve existing services. Added together this gives us a complexity score of 5.

Google App Engine: Python, Django, GQL, Unix (server-side hosting), existing Google apps are not OpenSource -> Score: 5.

MySites Services: One needs to know JSON and JavaScript -> Score: 2 (And yes: all apps on MySites are open source.)

2. Hosting and Scaling

Facebook
1. Developers need to apply before they can write an application on Facebook (Who's your daddy?)
2. You need at least one server on the Internet that will host your Facebook application.
3. You need to pay for the traffic (yikes!).
4. If you intend to write an application that is popular (who doesn't?), you need to worry about scaling and hosting your app on many servers, which in return requires serious $s, killing some more student hacker projects.

We think the last two points are very tough problems for developers compared to the other points that's why we count them double in the score (Scaling server-side applications is a problem which probably only some hundred guys at Google fully understand).

Score: 6

Google App Engine
1. Developers need to apply before they can write an application on Google App Engine (There's a limited number of available accounts).
2. You need to deal with developing and maintaining your code in a server environment.

From our understanding, Google will host your application, so you do not need to pay for the traffic and you do not need to worry about scaling other than designing your application according to Google's scalability guidelines.

Score: 2

MySites Services
You do not need to apply to become a developer, everyone can be a developer on MySites. We fully host your application and make sure it scales. You use your favorite web browser for development, so you do not need to worry about the server-side.

Score: 0

3. From a user perspective: How easy is it to use applications?

Facebook: You need to trust applications before you can use them, you cannot use the application without being logged in on Facebook, additionally you may need to give an application access to some of your private data in order to use it (undress before use). -> Score: 3

Google App Engine: Google's applications usually do not require one to be logged in on Google accounts, we presume that this will be the same for the apps made with Google App Engine. So all a user needs to do is to open the application in the browser. -> Score: 0

MySites Services: Open the application in your web browser, score: 0.

Summary

We personally think mysites has a huge potential and is an interesting offer. We are curious to hear your thoughts and comments on our MySites Services adventure.

There are many other criteria one could look at. Right now the biggest defect of MySites is that we do not yet have millions of users, but we are working on this :-), and as soon as we support openid, etc. this is less and less of an argument. In general, we prefer applications like youtube that you can use without logging in as compared to Facebook.

The future will be interesting: We want to enable everyone to write apps that can be used by the entire world. We are all about lowering the barrier to entry for developers.

(Thanks to Armin Roehrl for reading a draft of this post.)

Torture Testing for Ruby

Torture testing can be a very helpful technique for making your code more stable, especially when you're dealing with ruby libraries of which parts are written in C or C++. Torture testing basically means that you generate random input for your code and then see if your program behaves strange (eg generates a core dump).

Here is a trivial example of how to use the class TortureTesting with an array. It will call the specified methods in random order and with random parameters.

obj = [];
TortureTesting.run(n=2000,
[obj, :unshift, [:any]], # Random numeric, float, or string parameter
[obj, :unshift, [:string]], # Only random strings
[obj, :unshift, [:numeric]], # Only random numbers
[obj, :pop, [] ],
[obj, :unshift, ["foo"]], # Parameter not randomized
[obj, :unshift, [23]] # Parameter not randomized
)

torture.rb:

$stdout.sync = true
$big = 2**34
class TortureTesting
class << self
def string(size=rand(20))
@cs ||= (0..255).to_a
(0...size).collect { @cs[Kernel.rand(256)].chr }.join
end
def float(max=$big) rand * max end
def numeric(max=$big) rand(max) end
def any() self.send([:numeric, :float, :string][rand(3)]) end

def run(n=2000, *args) @calls = args; torture(n) end
def rand_param(k) return self.send(k) if Symbol === k; k end
def randomize_parameters(d) d.map {|p| rand_param(p) } end

def torture(n=2000)
puts "Starting torture: #{n}"
n.times {|c|
$stdout.write "#{c}\r"
obj, method, parameter_description = @calls[rand(@calls.size)]
begin
obj.send(*([method] + randomize_parameters(parameter_description)))
rescue Exception => e
end
}
end
end
end

(Thanks to Lincoln D. Stein's who first explained me how to use this idea for testing cgi programs.)

James Hamilton's Take on Cluster Computing

James Hamilton of Windows Live Services wrote a compelling paper On Designing and Deploying Internet-Scale Services (PDF).

Here's what I think are the most intriguing bits:

- Never shut down your services normally. (p. 2)
- One pod should not affect another pod [great for testing new versions of a cluster] (p.3)
- Correlated failures are common [a switch failure may affect lots of computers] (p. 5)
- It must be easy to host the entire service on a single system (p. 7)
- Soft delete only [Great for debugging] (p. 9)
- Avoiding latencies is the thoughest problem (p. 10)

Google's Lessons of Real Hardware

Interesting slide:


Taken from Jeff Dean's slides on Google - A Behind-the-Scenes Tour. [via Geeking with Greg]