Wednesday, December 13, 2006
Thoughts on Virtualization
This is the third of a planned six postings from insights gained by attending the the 451 Group Conferences...
Dann Connelly of Johnson and Johnson (Disclaimer: I am a shareholder of J&J) seemed to an EA-Oriented perspective to the discussion on virtualization where most folks are talking about vendors and their products while not talking about architecture, organizational structure and characteristics of leadership required to make virtualization successful. I suspect like in most enterprises, there are folks who intuitively get the need for grid and virtualization resulting in less effort spent selling it inside the walls while others within the same organization are dense and lack a single technical bone making it a challenge to figure out to characterize technical discussions in a way that helps them understand not only what the technology does but how it can be best leveraged for competitive advantage.
My only recommendation to anyone pursuing grid and virtualization approaches is to first champion strong technical leadership and become savage in the elimination of non-technical management. Doing the right thing from a technical perspective along with coming up with the right organizational structure will simply emerge once you eliminate the impediments from allowing it to happen quickly.
While the folks in the 451 Group do not cover enterprise architecture, hopefully they would be game to do some future research into how the technologies they do cover fit into an overall enterprise architecture context. Once you understand the human aspects of technology, downstream vendors can become more empowered by ensuring that their offerings align with our thinking which makes the sales cycle easier resulting in benefit for all involved parties.
Anyway, some of the common themes that were passionately discussed was the disgust that large enterprises have against the large software vendors in terms of licensing. Grids and virtualization enable the movement of workload and eschew notions of pinning things to particular CPUs or geographies yet vendors seem to want to be an impediment to large enterprises who believe that grid can help them solve interesting problems.
From the vendors perspective, they tie licensing to CPUs because it is something that they can audit for and is easily accounted for yet is pretty much removed from any notion of how much value their software is actually providing. Dann suggested that us enterprisey types collectively form a single unified position stating exactly how we believe licensing should be coupled to return on value (distinct from return on investment) and to come up with a model that vendors should embrace.
Another problem space discussed in terms of virtualization that seems to get zero coverage is the simple fact that there is no book, documentation, courses, etc that truly teach enterprises who to write enterprise applications that are meant to run on thousands of CPUs.
About a year ago, in my blog I mentioned that I was of the belief that multi-core CPU vendors such as Azul Systems while having interesting technology in order for it to be successful they also had the duty of helping folks write software that can consume their interesting technology. Grid and Virtualization are begging for someone to take on this task.
Consider the fact that minimally, the ability to get a workload to run in parallel is dependent on at least two things. First is the ability to take a business-oriented problem and get it to be decomposed. Remember that most enterprises grew up on COBOL so procedural thinking is still the norm. Second, is that we have been further trained by J2EE vendors to not even think about how multi-threading works.
One of the more interesting discussions on Java and its VM was that many folks felt that the term VM in this context was abused. To understand this perspective, one would need to ask themselves the following questions:
Another unstated trend seems to be enterprises writing these types of applications that run on several thousand CPUs in either Java or C++. It also seems as if no one is noodling how to take all that legacy COBOL, Powerbuilder, Visual Basic, etc code and get it to work in a grid implementation. Maybe this is an opportunity for a venture funded startup as a lot of money could be made.
The one discussion that didn't happen was the fact that no one talked about either Smalltalk and/or Ruby on Rails. This was either not on anyone's radar or simply thought of as a second-class language. I am curious to know how if possible Smalltalk could participate in a grid implementation. Maybe I could gain insight from the likes of Gary Short and James Robertson in this regard...
| | View blog reactionsDann Connelly of Johnson and Johnson (Disclaimer: I am a shareholder of J&J) seemed to an EA-Oriented perspective to the discussion on virtualization where most folks are talking about vendors and their products while not talking about architecture, organizational structure and characteristics of leadership required to make virtualization successful. I suspect like in most enterprises, there are folks who intuitively get the need for grid and virtualization resulting in less effort spent selling it inside the walls while others within the same organization are dense and lack a single technical bone making it a challenge to figure out to characterize technical discussions in a way that helps them understand not only what the technology does but how it can be best leveraged for competitive advantage.
My only recommendation to anyone pursuing grid and virtualization approaches is to first champion strong technical leadership and become savage in the elimination of non-technical management. Doing the right thing from a technical perspective along with coming up with the right organizational structure will simply emerge once you eliminate the impediments from allowing it to happen quickly.
While the folks in the 451 Group do not cover enterprise architecture, hopefully they would be game to do some future research into how the technologies they do cover fit into an overall enterprise architecture context. Once you understand the human aspects of technology, downstream vendors can become more empowered by ensuring that their offerings align with our thinking which makes the sales cycle easier resulting in benefit for all involved parties.
Anyway, some of the common themes that were passionately discussed was the disgust that large enterprises have against the large software vendors in terms of licensing. Grids and virtualization enable the movement of workload and eschew notions of pinning things to particular CPUs or geographies yet vendors seem to want to be an impediment to large enterprises who believe that grid can help them solve interesting problems.
From the vendors perspective, they tie licensing to CPUs because it is something that they can audit for and is easily accounted for yet is pretty much removed from any notion of how much value their software is actually providing. Dann suggested that us enterprisey types collectively form a single unified position stating exactly how we believe licensing should be coupled to return on value (distinct from return on investment) and to come up with a model that vendors should embrace.
Another problem space discussed in terms of virtualization that seems to get zero coverage is the simple fact that there is no book, documentation, courses, etc that truly teach enterprises who to write enterprise applications that are meant to run on thousands of CPUs.
About a year ago, in my blog I mentioned that I was of the belief that multi-core CPU vendors such as Azul Systems while having interesting technology in order for it to be successful they also had the duty of helping folks write software that can consume their interesting technology. Grid and Virtualization are begging for someone to take on this task.
Consider the fact that minimally, the ability to get a workload to run in parallel is dependent on at least two things. First is the ability to take a business-oriented problem and get it to be decomposed. Remember that most enterprises grew up on COBOL so procedural thinking is still the norm. Second, is that we have been further trained by J2EE vendors to not even think about how multi-threading works.
One of the more interesting discussions on Java and its VM was that many folks felt that the term VM in this context was abused. To understand this perspective, one would need to ask themselves the following questions:
- Should any VM be pinned to a particular CPU implementation?
- Can I run two or more discrete applications dynamically within these VM?
- How should virtualization work at each layer of the stack (e.g. Operating System, Java VM, J2EE, etc)?
Another unstated trend seems to be enterprises writing these types of applications that run on several thousand CPUs in either Java or C++. It also seems as if no one is noodling how to take all that legacy COBOL, Powerbuilder, Visual Basic, etc code and get it to work in a grid implementation. Maybe this is an opportunity for a venture funded startup as a lot of money could be made.
The one discussion that didn't happen was the fact that no one talked about either Smalltalk and/or Ruby on Rails. This was either not on anyone's radar or simply thought of as a second-class language. I am curious to know how if possible Smalltalk could participate in a grid implementation. Maybe I could gain insight from the likes of Gary Short and James Robertson in this regard...
