|By David Linthicum||
|June 8, 2009 01:00 PM EDT||
Those who approach virtualization these days are often taken aback by the complexity of the architecture when faced with the number of layers they must deal with to deploy virtualization. Most typically consider virtualization around data center optimization or private clouds, and find it difficult to get their bearings as they wade into their first virtualization project.
While the virtualization vendors do render assistance, the core issue is that those who deploy virtualization often need to deal with many domain-specific issues, such as architectural complexities around data, service, and process sharing and synchronization across virtualized environments. While there is a lot of information out there about what virtualization is, few understand the way to approach virtualization and the prevailing best practices. As a result, I hear about project after project that ends badly. Not due to the issues with the technology, but the results of creating the wrong solution and having to live with it. As one person put it, "We did not know what we were doing and it showed."
Core to this issue is that many believe the technology itself has magical powers, and that implementing VMware or Zen is the one and only step. Truth be told, this is an architectural exercise, thus many factors should be considered including the data and the use of data, services and the use of services, and processes and the use of processes.
For those who seek best practices in the world of virtualization, it may be best to look toward existing approaches and best practices around SOA. Core to SOA is the notion that we're going to break systems down to their functional primitives and built them up again as sets of architectural components, such as services, and align those services to meet the needs of the business.
What's critical here is to have a much better understanding of the business, the problem domain, and the underlying architectural components (e.g., data, services, and processes), before proceeding to the step that covers how all of that is going to work and play well in a virtualization environment. This intermediate step could be called: How to better configure the virtualization environment to meet the needs of the system or systems. It's a bit more work than you may have expected, but its well worth the effort, considering the risk that it removes.
In moving beyond the core architectural issues, we also need to consider governance, security, and testing, and the best practices around approaching those issues, and, most important, how you define success. Many of those who look to leverage virtualization have no idea what the core benefit is around their existing IT infrastructure, and thus need to establish a business case and goals that should be reached when implementing virtualization.
At the end of the day, virtualization is something that you do, as well as something you buy and implement. Those who do it wrong will fail, no matter what the technology can do. Those who define a healthy process around virtualization implementation will most often succeed. Who do you want to be?
|email@example.com 06/09/09 05:31:41 PM EDT|
So if you think it's bad for Virtualization (and you do appear to be discussing just Server Virtualization?) then think how bad it is for VDI? As there are so many more components and dependancies?
I recall how we had the same issues with introducing Citrix Winframe/Metaframe? It was so cool, and it just worked - yet typically if not done correctly with a bit of prior planning it can easily end up becoming the stick that is used to beat up the IT dept?
Sound familiar? ;-)
- Real-World AJAX
- SOA 2 Point Oh No!
- Semantic Mapping, Ontologies, and XML Standards
- SOA - Loosely Coupled...What?
- Joining Enterprises With Web 2.0
- Ten Things to Think About When Building the Perfect SOA
- Why Services Are Like Craigslist
- Cloud Computing & SOA: Getting the Links Straight Between Them
- AJAX, RIA, SOA & Web 2.0 Mashups - Mash What?
- What Level Is Your SOA?