What Is Missing in Current Software?

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.

This entry was posted in Software Development and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.