Skip to page content or Skip to Accesskey List.

Work

Main Page Content

Scalability S New Meaning

Rated 3.72 (Ratings: 4)

Want more?

 
Picture of DevilM

Matt Liotta

Member info

User since: 11 Mar 2002

Articles written: 6

The word scalability has long been used in software development circles to describe the capacity of a system to handle increasing load or demand. Software developers would assess the scalability of their applications by investigating both how well their application responds to increasing load with fixed resources and how well their applications take advantage of additional resources. The goal was to achieve perfect scalability also known as linear scalability.

Strictly defined, linear scalability, relative to load or demand, means that with fixed resources, performance decreases at a constant rate relative to load or demand increases. Linear scalability, relative to server resources, means that with a constant load or demand, performance improves at a constant rate relative to changes in resources.

Scalability in the Real World

That is all well and good, but it seems awfully academic. Why were software developers in corporate America dealing with this issue? Simply put, corporate America�s computing resources couldn�t keep up with the increasing load or demand that was placed on their applications. Software developers had no choice but to make scalability a priority when building their applications.

Vendors also fell victim to this same trend. If they wanted to sell enterprise software they had to make sure it was scalable. Their marketing departments got involved and soon every enterprise software application was touting its scalability. Religious wars ensued as vendors and software developers tried to show how much more scalable their applications were than their competitors.

Scalability and Language Selection

Much of the flak languages like VB and Java got were because of their perceived performance challenges. This led to a very typical comparison between software languages.

In the one camp, dominated by the language C, software developers would tout their language�s efficiency and pure speed of execution. The other camp dominated by languages like VB and Java, software developers would tout their ability to produce complex applications in significantly less time than that of their C counterparts. This debate still goes on today, but it is mostly moot because of the realities of the post dot-com era.

During the dot-com era money was flowing like water. Companies were

building applications to handle load or demands that seem very unrealistic

today, but seemed perfectly reasonable at the time. These companies bought the best equipment and people money could buy. When the money started drying up this method of software development dried up as well.

The New Meaning of Scalability

The new reality was simply learning to do more with less. Software developers needed to produce more functionality quicker than ever. There simply wasn�t time to make it scale. This forced many managers to start seriously looking at languages like VB and Java instead of C. Thus many software developers started using less efficient programming languages and paid little attention to scalability and more attention to functionality.

The funny thing was that many developers were finding that their applications were able to support greater demand than expected. So much more than expected, that managers were becoming less worried about the scalability of their applications and more worried about the scalability of their development teams. What caused this apparent change in attitude? A law that has governed the computer industry since its inception caused this change.

No need to rehash the now famous law proposed by Moore. The point is simply that while no one was looking, the computing resources in corporate America were growing faster than the demands put on them. It now cost less to buy a bigger machine than it does to build a more efficient program. Scalability has taken on a new meaning indeed.

Scalability of People, Not Applications

Today the word scalability is used more to describe the capacity of a software development team to handle increasing production requirements than the applications they produce. Instead of assessing applications, managers now asses the scalability of their development teams by investigating both how well their team can respond to increasing production demands with fixed resources as well as how well their team can take advantage of additional labor resources. It will be interesting to see what new development methodologies are used to help software development teams be scalable.

Matt Liotta started his development career at the age of twelve by building C applications for faculty at Emory University. He built his first web page soon after the release of Mosaic 1.0. Excited by early web applications, Matt saw the potential to replace legacy client server applications. At Emory University he built an enterprise calendaring system, the faculty poster project, a Y2K compliance tracking application, and a prototype for an electronic research administration system.

Since then he worked with an early ASP, Cignify, to build their transaction processing system for payroll time data. For this project, Matt created a message queuing system to connect significant bodies of code in C++ and VB with the main application server. He also built a code distribution system for Consumer Financial Networks, as well as the first online account management system for Grizzard Communications. Matt did consulting around San Francisco for companies such as Williams Sonoma and Yipes Communications.

Soon after, he built gMoney's Group Transaction System using an innovative XML messaging architecture for ColdFusion that matches conceptually with the now popular web services paradigm. He also wrote a C++ knapsack algorithm to realize nearly a 20-fold improvement over a similar approach written entirely in CFML. Later at TeamToolz, he designed a highly secure and scalable network architecture for ColdFusion to support N-tier transport agnostic distributed applications. He then went on to implement a cutting-edge content management system for DevX. He is now President & CEO of Montara Software, which he recently founded.

Matt is also a frequent speaker on web architecture:

  • Moving Legacy Applications to the Web (Emory Web Developers Users Group, Atlanta --Feb, 98)
  • The Benefits of Web-based Enterprise Calendaring (Emory Web Developers Users Group, Atlanta -- Aug, 98)
  • Monitoring and Managing Services Remotely Using TAPI (Atlanta Visual Basic Users Group, Atlanta -- Nov, 99)
  • Scalable, Extensible Cold Fusion Architecture (Bay Area ColdFusion Users’ Group, San Francisco; Aug, 00)
  • Scalable, Extensible Cold Fusion Architecture II (CF_Scale Conference, Washington, D.C. -- Nov, 00)
  • Cold Fusion Scalability Panel (CF_Scale Conference, Washington D.C. -- Nov, 00)
  • Introducing CF Espresso (including white paper) (CF_South Conference, Orlando -- Feb, 01)
  • Utilizing Reverse Proxies (Web Services World, San Jose -- Apr, 01)
  • Cold Fusion on Linux (A CF Odyssey Conference, Washington, D.C. -- Jun 01)
  • Architecting Web Services (Web Show 2001, San Francisco -- Sep, 01)
  • Code Techniques in MX Panel (Bay Area ColdFusion Users' Group, San Francisco -- Jul, 02)
  • ColdFusion Cruise, May, 03

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.org Evolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.