If we look closely at the software today, we will find some important pieces missing. For example, the software code defines logical behaviors of a system, but not the performance and scalability aspects. In other words, the operational aspects of the software are not clear even if you have a software product.
It may be too abstract. Let’s borrow a sample from physical world – today’s software is like construction blueprint that does not include sizes, therefore it can be used to build another one anywhere with a quite different size. Just imagine the white house in Washington D.C., and the miniature one in the Legoland in Carlsbad close to San Diego.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
While it’s uncommon to find a construction blueprint without size, it’s the norm in software development today. You can install same software on your laptop or a super powerful server.
This is not necessarily a bad thing. In fact, it’s good in the sense that same software can be used by a small startup or by a big corporation – you just run it on different servers with different configurations to support different loads. From this perspective, it is a great thing that one piece of software fits all (Not always true, read this article on Google’s thinking). You don’t need to create different versions of software for different sizes mostly. Even you want to do this, there is no obvious way to support this with today’s software development approach.
The sizing has in fact been delayed to the deployment phase and owned by the operation teams who pick running environment (hosts, storage, network IO, databases, and other middleware), create configurations, and provision initial data. It’s obvious that these choices have big impacts on non-functional aspects of software, like performance, scalability.
I don’t anticipate that runtime factors will be included in software code explicitly anytime soon, and I doubt it will ever. But I think we do need a scientific and systematic way to model the performance and scalabilities of software so that we can get infrastructure requirements based on the software SLAs. Because it’s hard to use pure mathematic formulas here, the model is more likely a combination of mathematic formulas and test samples. In fact, how it’s modeled and implemented is not as important as the result, therefore can be left to professionals.
With cloud computing model, this model can be transparent to the customers. I will discuss it more in future articles.