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.

One thought on “Just Because the Cloud Offers Scalability, Doesn’t Mean That You Automatically Inherit It”
  1. That’s a great point JP. The public Cloud leverages the Internet, which everyone can agree is a very successful Ultra Large Network Architecture. You can have applications accessed via the Cloud, that are not ‘of the Cloud’, because most the apps are based on Service Orientation and Object Orientation and the web is based on Representational State Transfer (REST).

    I can’t imagine the nasty legacy apps the government must harbor and how much they spend to maintain them each year. There is no magic cloud button for them, though it might appease some lawmakers and lobbyists.

    It’s great to see someone speak truth to power. Folks need to look before they leap otherwise they are just moving their old stuff from an old house to a new house. App modernization is critical for scalability and agility.

    On that note, SOA in and of itself doesn’t do the trick either as their is nothing about a ‘web’ service that has anything to do with the Web. While Modularity is good, it’s just a state, not a purpose. Modularity facilitates interoperability, but Service Oriented apps have little re-use in practice and even mildly complex Service Oriented composite apps are difficult to design, expensive (in terms of middleware and indirection), and challenging to maintain (change an interface, break all dependent apps).
    When we built our system, we chose a hybrid REST approach that uses Resources (information addressable by a URI) to create a linked data layer. The approach yields enterprise-strength applications based on web-architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *