Test Lab Cloud/Virtualization in the SMB space

As an introduction to this blog, I wanted to break ground in a two areas that I am extremely passionate about: Test Lab Infrastructure and virtualization. Why are these two concepts linked? To start, test lab infrastructure continues to be the most expensive, most under-utilized, and least managed environment in any large enterprise. In the absence of any non-disclosure agreements, I can point to literally dozens of Fortune 500 companies that I have consulted for, where the test environments are a morass of servers, environments, and software tools with very little financial visibility and even less architectural and financial planning. In six years of consulting, the only somewhat successful case I have seen was the largest Boston-based investment services firm, where I DID see evidence of a virtualized test lab architecture in place. In this space are tremendous opportunities for improvement and thus IBM's cloud computing services offerings have the greatest legs in the marketplace.

So if the larger, more successful enterprises do not focus on managing test environments and want companies the size of IBM to manage it for them, what do small- and medium-sized companies do to test their software? How do they afford a test infrastructure on limited start-up and VC funding? Where do they carve out the time to build the one infrastructure that will last them the entirety of their business's lifespan (even longer than their production environment, once it gets stood up)?

Here is the rub: Small business does not have an inexpensive test lab solution, not hardware-based and not Cloud/Virtual,  not testdev cloud from IBM, not SAAS from HP/Mercury, not even Google, whose innovative approach to SAAS in the SMB marketplace SHOULD have a test lab offering and doesn't.

Below is an article I found, espousing the virtues of software as a service in the SMB space for VoIP applications:

http://voipstreet.wordpress.com/2009/08/25/is-saas-a-fit-for-the-small-business-market/http://bmighty.informationweek.com/hardware_software/showArticle.jhtml?articleID=218600642

Take an example of a small software business, struggling with releasing alpha versions to promote to potential investors and show to prospective clients. If they develop in J2EE, Ruby, or any other portable development platform, they probably build most of their code on isolated desktops (where they are prone to security and scalability issues) or (worse) on production servers that will get "converted" once the product goes live. It can take days of effort to isolate and stage the code necessary to produce the released product in production and the likelihood that SDLC-type testing is nearly impossible as it was not developed with that waterfall or iterative (read: agile) processes in mind. At that point, it is too late to turn back, so why not start with the development and QA environments from the start?

Fortunately, good test process translated into an SDLC-compliant environment is fairly easy to build uniformly and with highly repeatable template designs, using release management concepts to build, maintain, operate environments and increasing the level of automation required as the budget and sophistication of the business grow. In the diagram to the left, I illustrate a conceptual design of a Test Lab in a Box prototype, under active development. This highly virtualized hardware environment can be built inexpensively, operate in using open source software model, and use virtualization solutions which match the budget and timeframe of the development and testing efforts.

In this diagram, the development environments are physically isolated from the test environment and later phases of production deployment, even if they share common storage and management frameworks. From a network standpoint, each environment is isolated by VLAN and they can be further physically isolated with inexpensive network hardware, especially for performance testing purposes. Also note that operating a Production environment is NOT within scope of this solution and yet storage and management Production-level code can be accomplished in Staging and DR/Backup environments, permitting developer access for troubleshooting code and infrastructure issues. Testing and resolution of these issues can also be accomplished in this environment, without impacting production environments, visible to the SMB customer.

Using a straight services model, this physical environment can be either "rented" or "provisioned" with an initial services contract and maintenance agreement.