Recently in Business Category

Why Scalablity Matters

Several years ago, everyone was going nuts about scaling, how to make applications scale -- so that we, the administrators, engineers and creators of the applications could build out our infrastructures accordingly and -- scale the application by growing the pile of hardware under it. Google did this best, using three servers in the datacenter to provide the storage necessary to support gmail and other applications. The failure of one system resulted in the remaining two computing parity of that storage, but providing still providing that information much as a RAID5 controller in a server would, yet without the added cost of that add-on controller or the labor to install that controller. There are many examples of innovative ideas that Google has been able to harness; this is not meant to be an exclusive list.

 In attempting to scale applications, we tried to break the parts apart so that we could take best advantage of the computing power we had available at commodity rates -- single or dual processor white boxes. With the invention of the multi-core processor however, the ability to scale a single-threaded application quickly became extremely important.  The hard limit of 2.8GHz of cheap silicon capped processing speed. No longer could processing be monolithically streamlined into a single processor core. It is now necessary to atomicly multithread applications to take advantage of the multiple cores, and to divide the processing power among as many cores as possible. In effect, we've created Crays on a single slab of silicon -- multiple processors connected together with high-bandwidth interconnects. And like the users of those Crays, we have to sit back and think about the problem mathematically and determine how many pieces we can break the problem into to get them processed and completed in the environment we have been given by the manufacturers. We now have 42U of white-box server processors in one or two pieces of silicon in a 2RU box! Technology is grant indeed, but can our educational models keep up? Can we truly impart the necessary mindset on the current generation of computer scientists to allow them to keep an open mind and solve the problems before them with any combination of hardware the manufacturers provide?

As a systems administrator, my job has become difficult. In previous times, it was easy to watch the system load and processes and determine when a server was loaded enough to provision more hardware, or to kill off rogue processes that were hogging resources. In the present day and age, it is now necessary to determine how many processors are in use, and that the workload presented to them is properly distributed. While my application administrators are able to spread the load over multiple servers, each server should be appropriately loaded before spending money allocating the next server. So both the multi-core server, and virtualization technologies play into each other. By reducing the amount of spare capacity to a minimum, costs may be kept down. Excess capacity may be sold to other organizations (this is what Amazon does). At the end of the day, my bosses and customers are demanding the most services, with the most uptime with the least amount of dollars spent. And I want to deliver that.

But I cannot do that if my vendors and application providers do not support me. Contracts that specify a fixed number of cores the application may be run on limit the infrastructure that I can deploy to support that application. I may have 4 2.8GHz cores in one server, and another with 32 or 64 cores running at 900MHz. If I run the cluster-designed software on the 64-core server, it's going to make anything running at less than 32GHz and quad-processor look like a VW Diesel Rabbit at an F1 race. We need to re-think our billing paradigm based on per-core performance, and break our application into atomic chunks that can take advantage of the cores and cheap IO we have now. We've scaled a rack's worth of computing into a single chip. We're not getting faster, we're getting smaller. We need our applications and OSes to support us and adapt to the conditions. And we need our programmers to be open-minded about where changes in the electrical engineering world will take them. Look at breaking the problem apart instead of building one pipeline to achieve an answer. Hopefully, we can make our future brighter, one red-hot screaming CPU core at a time.

About this Archive

This page is an archive of recent entries in the Business category.

Apple Mac OSX is the previous category.

DNS is the next category.

Find recent content on the main index or look in the archives to find all content.