I explore software scale up: why it matters, what we aim for, and an how to. First I set the context of software scale up. Of how come it is a topic of interest for me now. And of the general programming concepts that are used to support software scale up. Second I set the two objectives that we are after when aiming for software scale up. And third I explore the how to of making (web) software scale up.
Why does software scale up matters?
Speaking of software practices that do not scale, we often qualify as "spaghetti code" some twisted and tangled code that makes direct functional calls to multiple parts of a software application. Likewise, we also refer to "dependency hell" a situation where an application requires numerous libraries that are version-specific and that may conflict with each other.
As I attend Hack Reactor in San Francisco, I have yet another opportunity to come back to the fundamentals of computer science and notably to algorithmic complexity and the Model View Controller software pattern (MVC). In fact, as I relate these two computer science aspects with my experience in research and industry, I (so!) fully understand how the sustainability of a software application depends upon design choices that I wanted to extend the topic a little further through this post.
What do we aim for when thinking of software scale up?
We aim to find the best practices that minimize both the cost of implementing new software functionalities and the cost of maintaining the application. In particular, we want to keep constant the marginal cost of developing new features (linear), thus avoiding an inflation in development cost of new functionalities as the application becomes more elaborated. And we also want the marginal cost of maintaining the application to decrease as its use grows (i.e. be sub-linear or, ideally, logarithmic), thus permitting the so-called economies of scale.
Side by side, the quadratic, linear and logarithmic growth that illustrates complexities impacting software scale up.
- to differentiate the actual data (M) from the layout (V) and the application control (C),
- to make data-atoms (M) agnostic to both the layout (V) and datasets (M-collections),
- to communicate data-atoms and layouts or datasets via events through the Publisher/Subscriber design pattern. Also, we use test driven development (TDD) frameworks like JasmineJS and MochaJS to parallel the development of the applications with a growing test suite that validates the proper functioning of the application.
Thus, to achieve the proper scaling of the application, we attempt to use the MVC software pattern and to be systematic in the use testing. This way we limit the dependency requirements by breaking into modules the application, we avoid repetition of programming logic and we parallel the development of any new functionality with accompanying tests.
Thanks. Justin Yek for discussing an early draft.