Closer To The Ideal

Nati Shalom writes about the crisis of scaling that hits startups once they become successful. Most startups are unsure if their idea will be successful, so they do not, initially, waste any energy planning to scale up. Instead, they do what is necessary to get to market as fast as possible. If they are then successful, they must then re-engineer their architecture to take scaling into account. Shalom offers some tips on how to do this. He also feels the problem can be avoided from the start:

Are we all doomed to go through this painful process when we are successful?

We seem to take it for granted that dealing with scalability is complex. When we start a new application it’s hard to know whether we’re ever going to be successful to the point where the investment in scalability is worth the effort. At this initial stage the important thing is time-to-market. We want to get our idea out there as quickly as possible. This is a reasonable desire as indeed most projects don’t take off.

Now imagine what would happen if dealing with scalability wasn’t that difficult. That would have change the entire decision making process, and would enable Twitter and many others to start with a scalable architecture from day one, avoiding this painful process.

So the question is what would is required to simplify building a scalable application to the point in which it is as simple as building it for a single machine?

From my experience, most challenges have already been faced by and dealt with others - so the first thing that I did was look at how others (not necessarily in the same industry) addressed this issue.

In this case, storage virtualization is a good example. At first, we used local disks. Local disks tend to get filled-up quite fast. It was very hard to deal with this problem as it required replacing the disk with a bigger one every time full capacity was reached. IT had to go through this process for every user and every application — very painful and costly. The solution came in the form of NAS and SAN, or network-attached storage. Instead of using a local disk, use a virtual disk that resides somewhere on the network. The user and the application don’t need to be aware of it, because they use a local disk driver that virtualizes the network devices to make them look as if they were just another local disk. The application scales but hasn’t changed as a result. We can add and remove devices as we wish with no changes to the application. Later on, if there is a more cost effective solution available, we can easily replace the devices.

We can apply the same concept of virtualization to the middleware stack — namely the data, the messaging and the processing — with the same degree of simplicity. The application interacts with a “proxy” that hides the details of how a message or update operation is routed, how fail-over is handled, how data is partitioned and so on.

With services such as Amazon EC2, and other cloud environments, this can be made even simpler, as we can have a pre-configured image and hardware ready for deployment. All we need to do is just deploy our business logic. (See an EC2 example here).

With today’s frameworks architectures, we don’t have to go through the same painful experience. We can build scalable architectures from the get-go. I would even argue that it takes less time to build applications with this approach than the traditional client-server approach.

I suppose Sam Ruby likes Erlang for these same reasons - automatic concurrency.

I do think that Shalom is under-estimating the degree to which emotions, self-esteem and uncertainty combine to ensure conservative choices that may be painful later on. His example of disk-virtualization is a fine representative - none of the start-ups I’ve worked with have choosen to use Amazon S3, even though they all might benefit from it later on, and it is relatively simple to use. But a lot of people starting a new venture will collect together people they like working with, and the entrepreneur who gets the project going will make use of the skills that his/her team already has, rather than asking them to learn a new skill, like amazon S3.

This entry was posted on Monday, June 2nd, 2008 at 12:23 pm and is filed under the tech industry. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.