I have spent a great deal of time lately working with the Cisco Unified Computing System (UCS). This computing platform is really quite impressive with its power and flexibility, but my expectations about the platform have really changed since I completed the UCS training. During the training classes that I attended, both the design and install courses emphasized that the Cisco UCS platform would be a collaborative platform that would bring the different groups like Storage, Network, and Server each working their own functional area of responsibility within UCS based on role permissions. That sounded great. The network team can create and trunk the VLANS and the storage team could add the boot targets as well as assign the LUNS. This platform is a true collective effort by all teams right?
Well needless to say this is not quite what I am seeing on different client’s sites, both small and large. Within smaller organizations the IT person or group is expected to be able to administer and maintain multiple different skill sets for all the systems in the environment. On the opposite side you have the very large organizations, where compartmentalizing really comes into play. I was a part of a pretty decent size virtualization project for the Acme Company (made up name). This project was a design and deploy of a new private cloud infrastructure that would be running on Cisco UCS platform. The second part of the project is all the P2V, V2V and P2P migrations with anything physical running on a UCS blade.
Since most of the blades would make up the internal cloud, the virtualization team was appointed the responsibility of the UCS platform. The idea of collaborate effort went right out the door once UCS, as a whole, had been assigned. The storage, network, and other teams were happy to help out with anything needed as long as it did not require going into UCS itself. The line in the sand has been drawn and in my humble opinion, no other team wants to claim any responsibility on a system they do not understand.
Does it really make sense to have all the different teams have access to their own part or is it better to have a person or team that controls the complete platform? There is really not a great deal the network team would do inside UCS except create and remove VLANs from the templates and the system. All trunking is done upstream. As far as the storage side of things, zoning and masking are still performed upstream, outside of the platform. Any boot to SAN will need boot targets written into the boot policy and not much more.
I am going to take a stand in that although the collective effort is a nice thought, I am not quite sure it is practical in the trenches of the larger organizations. Even if there is collaboration in the environment, there must be a person or group that has the ultimate responsibility of supporting the platform. For those of you that are running some kind of unified platform in your environment, how are the roles and responsibilities assigned?
This is an awesome topic and very perceptive of you to pick up on it. What you are seeing here is a vendor reacting to something that has been happening in a few places before UCS came along. In quite a few shops where virtualization was doing well, you would find a VMware team that was doing the networking, storage and compute/virtualization for their part of the infra and “plugging in” to the larger environment where the silos still ruled their individual technology segments.
UCS is a technology product that brings together everything bar the storage array into one piece and therefore, if you are working like the previous example of collapsing the silos just for the VMware-segment, then it’s a huge step forward. However, as you note, if your company is still siloed then it creates friction and this needs to be solved immediately.
I saw both situations across EMEA when I worked in the Cisco UCS team: small shops seemed to cope better because their staff were multi-skilled. Big companies fared worse, in some cases, but that wasn’t universal.
The answer in our (Cisco) case was to help the customer get a perspective on this (you are not collapsing ALL of the silos, just in one well defined area that you will “plug in” to the rest of the infra), help onboard the technology (hands on training from the perspective of the attendees) and operationalization (one-off work, regular ops, tools integration etc).
This is happening in a more extreme fashion with converged infrastructure where now the storage array is part of the unified structure. Again, I believe the best approach is to work out the right perspective (the Vblock is a special case leaf node that plugs into the infra/network) and then enable the customer to change/onboard/consume. In some cases customers are using this operationally disruptive technology to (a) onboard new technologies that their own standards are lagging on (e.g. new vSphere versions, or Nexus 1000v), and (b) by collapsing superfluous staffing structures they can free up staff for value-add activities like DevOps, cloud etc.
It isn’t going to go away and I think there will be several camps: (a) denial/it isn’t happening to me, (b) BAU/silos, and (c) embrace it and exploit the hell out of it.
I know where I am… what about you? 🙂
Nice work Steve!
Steve
Hi Steve
Great topic, and one that is very close to my heart.
I spend a lot of time with clients addressing just this point.
Assisting them move from silo’d technologies to a Unified one. I echo your observations as I also teach Cisco UCS to our staff and customers and certainly do mention the option to use Role Based Access Control (RBAC)to farm out the relitive admin responseibilites to the various specialists in those areas.
But thats all it is “an option”
Cisco UCS is all about options in my view and as such is very adaptable to ftting in with how a client wants to use it, and not neccersarily how Cisco UCS is best used.
Some customers would have grave concerns if these role options were not there. But as you say the reality is often that the VMware admin generally takes complete control of the UCS administration. Underpinned with the fact that most admin tools are working towards being intergrated into vCenter if not already.
And as you mention with a small ammount of training this is easily accomplished as once the main policies and templates are defined the BAU tasks are minimal. As Stevie Chambers aluded to
unified admins are fast becoming the norm and this trend is being catered for with the rise of unified automation / orchestration tools like EMC Ionix Unified Infrastructure Manager (UIM) amoungst others.
The emphasis on the infrustructure administration will reduce and rightly so, the focus should be on the applications, as that is where the true value to the customers business lies, the platforms on which they run should “Just work” and empower the application rather than restrict it. Simples!
One things for sure a great time to be in IT, as loads of great things happening now and in the near future.
Keep on bloggin’
Regards
Colin
Steve abd Colin,
Great replies and thank you. The mgmt team really like having the role based permission in place but I have yet to see anything that does not have a defined owner and if you are the owner that can do everything in UCS that saves you time having to submit a change and wait on others.
Greats comments thanks again!!