Putting Your Web Site in the Cloud
How many CPUs do you have?
One of the most interesting changes to the web in the last couple of years is that computing hardware is moving beyond mere commodotization and into the realm of the metered service. Companies that formerly would have had to heavily invest in hardware (and the associated system administration costs) in order to deploy web sites are beginning to have a viable alternative: cloud computing, available in various flavors such as Amazon’s EC2, Slicehost’s virtual machine based hosting, or quick set-up hosts like WebFaction.
Instead of buying hardware to host your website, it is now possible to rent computer time at any capacity level. This allows businesses to essentially pay for only the computer power they need.
This is great, but implicit in this is that we need to change the way we build web applications. What is rapidly becoming the predominant hardware paradigm (via cloud computing) for web applications is in a direct disconnect with the technologies that we’re using to build them.
It has to do with how many CPUs (processors) the technology can handle.
The approach-du-jour in web apps is rapid development through frameworks that take advantage of powerful, dynamically typed languages like Ruby and Python. These frameworks allow people to build web applications very, very fast.
However, these languages are executed in runtimes that are not SMP (symmetrical multi-processing) enabled. In other words, the runtimes can only handle one processor at a time. There are numerous hacks in the web development world to get around this, mostly involving running multiple instances of the runtimes. However problems creep up – the well known scalability problems that Twitter has encountered have their roots in these issues.
So up on the bleeding, ragged edge of web development, we’re starting to look at alternatives from other industries. In the telephony world they’ve had to deal with these kind of scalability and reliability issues long before we were around, and they have some pretty impressive solutions.
Erlang, developed by Ericsson, is a language and runtime created from the ground up to live in an SMP world (originally its “cloud” was telephony equipment). There is a famous Erlang app which claims nine nines of reliability. That’s 99.9999999% uptime, or a few seconds every 30 years. Way more than any website needs.
Unfortunately, Erlang is, well, kind of weird. People coming from said Python or Ruby background will have to re-learn some very fundamental approaches to problems, and that’s not going to be easy. In fact it might not even be possible. Fortunately, Erlang compiles to bytecode (similar to the way Java and Python work) meaning that its possible to write a different compiler and perhaps uses a different language on the Erlang runtime (called BEAM).
So just today I noticed, (in what is clearly a really, really early incarnation) – a little project called Reia. Its pretty raw now, but it purports to be a Python/Ruby-like high level language that compiles to Erlang BEAM format, giving it all the SMP-loving, fault-tolerant and distributed goodness that comes with Erlang. I don’t know if Reia is the winner, but I feel pretty confident that creating a friendler programmer interface to the Erlang runtime is a winning proposition.