Work has been keeping me busy. That’s a good thing. An update, I’ve been with “The Company” for a while now, and it’s been a real eye opener. I’ve never actually met my boss face to face. Or most of my coworkers. This is a big company, and it’s REALLY spread out. (50+ countries) It sort of congeals in a few places, not surprising one of those places in NYC. There’s a sizable location on the other side of the river too, in Hoboken, NJ. That’s where I’m headed. Hoboken NJ.
I’ve been asked to deliver the opening remarks and slides for the “WTF are we all doing here? and how are we going to correctly consolidate and leverage vmware?” slides. I don’t really deliver slides in a sort of stuffy big company delivery method, I’m interested in seeing how it’s received. (Turns out it wasn’t received at all, my slide deck was cherry picked by PMO)
The interesting thing that we’re seeing is the reason I was told I was brought on.
“How do we fix VMware?”
This isn’t my first dance card, and I’m sure it’s not yours either. One of the most interesting things happening (at least to me anyway) is that companies of all sizes, have moved from the “what widgets do we need” to the “wait a second, this is REALLY going to muck up policies, procedures, and a host of other things we tolerate around here”.
Like any big enterprise, “The Company” has a way of handling virtualization. First it’s treated as sort of that “sure no big deal we can throw some servers out there and consolidate a few boxes, this is nothing!” Then usually the engineers start tackling the widgets angle of virtualization. This $STORAGEDEVICE does X and Y really neat! Look how it ties into my $SERVERPLATFORMOFCHOICE, or $SHINYBOLTONVMWAREPRODUCT is pretty cool, we should deploy this because it would solve $RANDOMTECHNICALPROBLEMTHATHASBOTHEREDADMINS.
The scope and success for the long term of any virtualization effort within most every sized company can be determined by the following questions.
Identifying the key components however are difficult for most engineering shops without close coordination with the operations group. For whatever reason, the size of the rift between the two organizations usually has a noticeable impact on the success of this effort.
With no coordination, it’s common to see an implementation that doesn’t account for complete monitoring, or proper capacity planning.
The next steps always determine how long it takes for an enterprise to move forward. Hopefully at this point the engineering teams involved are paying attention and say get the environment the proper planning, care, and feeding it needs. Usually this happens when you’ve got a business sponsor that’s driving the project, or a really sharp architect with history on the business side. The issue with relying solely on the administration or engineering teams, is that the bigger picture issues are often not addressed.
“Here’s the servers we’re using, here’s our storage, here’s the network gear, here’s what version of software we’re running” none of this data by itself will drive a successful virtualization project in an enterprise. It needs to be addressed as an entire platform to manage.
The idea, “we’re not deploying servers in a datacenter, we’re deploying datacenters within our datacenters” should start creeping in at this point.
————
I never finished this article.. The company didn’t have business sponsorship…. I moved on when I was told it wasn’t going to get it either.