In reading Vivek Kundra’s “25 Point Implementation Plan To Reform Federal Information”, I was struck by the anecdote regarding how the lack of scalability was the cause for outages and, ultimately, delays in processing transactions on the Car Allowance and Rebate System (CARS) or as it was more commonly known as Cash-for-Clunkers.  According to this document the overwhelming response overwhelmed the system leading to outages and service disruptions.  However, a multimedia company offering users the ability to create professional-quality TV-like videos and share them over the Internet scaled to meet rising demand that rose from 25,000 to 250,000  users in three days and reached a peak rate of 20,000 new users every hour.

The moral of the story is that the multimedia application was able to scale from 50 to 4,000 virtual machines as needed to meet demand because it was designed on a Cloud architecture.  While true, there is a very important piece of information lacking from this anecdote, which in turn could lead some to believe that the Cloud offers inherent scalability.  This piece of information is that the system you design must be able to take advantage of available opportunity to scale as much as have the facilities of the underlying platform support scaling.

In the comparison offered by Kundra, it’s clear that the system was appropriately designed to scale with the rapid growth in users.  For example, they may have had to add additional load balancers to distribute the load across increased numbers of web servers.  If they had a database architecture, perhaps the database was clustered and more nodes were added to the cluster to support the increased number of transactions.  If it was file-based, perhaps they were using a distributed file system, such as Hadoop and they were able to add new nodes in the system dispersed geographically to limit latency.  In each of these cases, it was the selection of the components and manner in which they were integrated that facilitated the ability to scale and not some inherent “magic” of the Cloud Computing platform.

It’s great that Kundra is putting forth a goal that the government needs to start seeking lower-cost alternatives to building data centers, but it’s also important to note that, according to this same document, many of today’s government IT application initatives are often behind schedule and fail to meet promised functionality.  It’s hard to believe that with these issues that the systems are going to be appropriately designed to run in a Cloud architecture and scale accordingly.  The key point here is that in addition to recommending a “Cloud First” policy, the government needs to hire contractors and employees that understand the nuances of developing an application that can benefit from Cloud capabilities.  In this way, the real benefit of Cloud will be realized and the Cloud First policy will achieve its goals.