Thoughts on Virtualization - Sprawl, Stall, Mainframes and Servers

| 3 Comments | No TrackBacks
There has been some discussion of virtual sprawl vs. virtual stall - what they mean and why they occur. Late night rumination led us to the following thoughts:

Virtual sprawl
is primarily a problem of management - determining and implementing the policies, procedures and workflows necessary to monitor and maintain control over the proliferation of logical assets. 

Virtual stall is primarily a problem of fundamental architecture, i.e. how you will deliver services and how you will structure IT operations - at some point, it appears to be at 30 - 35% infrastructure virtualization - the business managers (hopefully) and the IT staff realize that they are on a path which will fundamentally alter how they operate.

For more go here!

No TrackBacks

TrackBack URL:


Good distinction, Richard. More and more companies are realizing the benefits of virtualization for their companies, but are consequently struggling with issues of virtual sprawl, keeping track of their virtual resources as they add more and more to their network. Since every application and its middleware run on a dedicated virtual server, instead of running 100 physical servers, enterprises may now have 1,000 virtual servers. Virtual sprawl can cause problems in many different aspects of virtualization, but one that is particularly easy to solve is application deployment, which can be automated with deployment automation software. This software helps ease the strain of having to deploy across increasing numbers of servers, eliminating much of the tedious, manual work that wide networks create for IT departments. Have you seen many expanding companies using deployment automation solutions to control their virtualized environments?

Richard, there are a few ways to answer your question. Most simply, many IT experts simply do not believe in the existence of full automated deployments, whether in a virtualized or non-virtualized environment. And without the knowledge that this is possible, it tends to be an issue that is, for the most part, ignored. Looking more specifically at SaaS, though, deployment efforts are typically done by the vendor hosting the software, and thus ease of use and ramp-up time are the most important features. SaaS vendors include deployment in their service model and thus charge their customers for it, but it tends to be unmentioned to the customer. For PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), deployments remain the customer’s responsibility, but as mentioned, automated deployments are largely unheard of by most IT managers. Overall, the lack of attention that deployment automation solutions are getting seems to be mostly due to a lack of awareness by IT managers, as well as a lack of communications between SaaS vendors and their customers. We look forward to reading more about this topic from you!

Leave a comment


Type the characters you see in the picture above.

About this Entry

This page contains a single entry by Richard Ptak published on November 2, 2010 8:58 AM.

Chevron CIO on how to increase maturity of BSM was the previous entry in this blog. signs sponsorship agreement with BSMReview is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.