I USED TO BE LIKE YOU.
I used to be a systems programmer, working on infrastructure used by banks, telecom companies, and other
engineers. I worked on operating systems. I worked on
distributed middleware. I worked on programming languages. I wrote tools. I did all of the things that hard-core
systems programmers do.
And I knew the rules. I knew that throughput was the
real test of scaling. I knew that data had to be kept consistent and durable, and that relational databases are the
way to ensure atomicity, and that loss of information is
never an option. I knew that clients were getting thinner
as the layers of servers increased, and that the best client
would be one that contained the least amount of state
and allowed the important computations to go on inside
the computing cloud. I knew that support for legacy code
is vital to the adoption of any new technology, and that
most legacy code has yet to be written.
But two years ago my world changed. I was asked
to take on the technical architect position on Project
Darkstar, a distributed infrastructure targeted to the mas-sive-multiplayer online-game and virtual-world market.
At first, it seemed like a familiar system. The goal was to
scale flexibly by enabling the dynamic addition (or subtraction) of machines to match load. There was a persistence layer and a communication layer. We also wanted
to make the programming model as simple as possible,
while enabling the system to use all the power of the new
generations of multicore chips that Sun (and others) were
producing. These were all problems that I had encountered before, so how hard could these particular versions
of the problems for this particular market be? I agreed
to spend a couple of months on the project, cleaning up
the architecture and making sure it was on the right track
while I thought about new research topics that I might
want to tackle.
more queue: www.acmqueue.com
ONLINE GAMES AND VIRTUAL WORLDS HAVE
FAMILIAR SCALING REQUIREMENTS,
BUT DON’T BE FOOLED:
EVERY THING YOU KNOW IS WRONG.
ACM QUEUE November/December 2008 11