Branching Late

We met with a number of technology analysts in the last week to discuss version 4.0 of our product and one conversation stands out as particularly interesting in my mind. The discussion centered on how to arrive at the best strategies for consolidation and/or virtualization for a particular set of servers that are part of a larger environment.

The analysts were describing cases they've seen where a strategy was decided upon early, and that this strategy dictated the end result and prevented the exploration of other options. They referred to this as "branching early", where a path is committed to early in the process, even if it not optimal. An example would be to say "we're going to take those servers at that location and virtualize them all" without proper consideration of what is on the servers or whether location is a true constraint on the virtualization process.

I contrasted this with the preferred approach of "branching late" and holding off on committing to a path for a set of servers until you having performed various types of what-if analysis. For example, the servers in question can first be analyzed for database and app server consolidation potential, which helps avoid putting I/O intensive apps on virtualized platforms (and also saves on expensive VM licenses). They can also be kept in a larger pool and a location constraint can be applied or lifted, allowing exploration of other options by effectively allowing an analyst to say "now let's see how much consolidation we can do if we allow ourselves to go across locations."

By keeping target servers grouped together and using constraint models to analyze the possibilities, rather than breaking them up along specific lines and committing to a strategy prematurely, this "late branching" technique is a much more effective way to determine the "optimal transfer function" for a set of servers.

We met with a number of technology analysts in the last week to discuss version 4.0 of our product and one conversation stands out as particularly interesting in my mind. The discussion centered on how to arrive at the best strategies for consolidation and/or virtualization for a particular set of servers that are part of a larger environment.

The analysts were describing cases they've seen where a strategy was decided upon early, and that this strategy dictated the end result and prevented the exploration of other options. They referred to this as "branching early", where a path is committed to early in the process, even if it not optimal. An example would be to say "we're going to take those servers at that location and virtualize them all" without proper consideration of what is on the servers or whether location is a true constraint on the virtualization process.

I contrasted this with the preferred approach of "branching late" and holding off on committing to a path for a set of servers until you having performed various types of what-if analysis. For example, the servers in question can first be analyzed for database and app server consolidation potential, which helps avoid putting I/O intensive apps on virtualized platforms (and also saves on expensive VM licenses). They can also be kept in a larger pool and a location constraint can be applied or lifted, allowing exploration of other options by effectively allowing an analyst to say "now let's see how much consolidation we can do if we allow ourselves to go across locations."

By keeping target servers grouped together and using constraint models to analyze the possibilities, rather than breaking them up along specific lines and committing to a strategy prematurely, this "late branching" technique is a much more effective way to determine the "optimal transfer function" for a set of servers.

Comments

[Michael Nearing]

This is a very interesting area of discussion.
However, virtualization might not always be the most effective solution. With virtualization being all the latest craze for many good reasons, a lot of companies are taking a blanket approach to virtualization. Depending on the application in question, virtualization might not necessarily be the best approach. An equally interesting area of discussion would be the one around when and when not to virtualize and what the input variables to this decision making process would be. I am curious as to your thoughts on this. It might make for an interesting topic in a later post.