Cisco Blogs

Learning from the First Private Cloud, Part 2

June 8, 2010 - 3 Comments

So, following up from my last post, do I think mainframes were the first private clouds?  In a word, no.  However, I think there are some key lessons to be learned from the era of big iron computing for organizations looking to roll out private clouds today.


While a lot of the technology is the same (virtualization, clustering, shared resources), there are some significant differences, including the rapidity of re-provisioning (think weeks or months), responsiveness to end user requests (there wasn’t), and the ability to self-provision (ha!).


I guess my point is that the shift to private cloud is less about technology and more about how you run your IT shop.  I cannot take credit for this insight–my compatriot James Urquhart made this point about a year ago.  However, when chatting with customers, many of them still tend to see this as a technology led transition and not a people/process-led transition.  The risk at the end of the day is that you end up with cloud infrastructure missing some of the key benefits of private cloud computing–you may see improved agility but might not see the TCO reductions you were expecting.


So, operationally, there are a couple of things I think we can learn from the days of IBM and DEC big iron:


Break out the Excel.  Because everything was so expensive, we had to make sure we squeezed every last bit of use out of a piece of hardware.  There was no “just throw hardware at it” mentality because most companies simply could not afford that approach.  For private cloud to really return business results, IT organizations need to be able to bring back this kind of discipline–be able to maximize utilization and avoid band-aid fixes.  Some of it is making sure you invest in the right level of instrumentation for your data center and some of this developing the operational capabilities to be able to do the analysis and planning.  Of any group in the data center, the storage folks seem to have the best handle on this–perhaps because it seems like many of them are ex-mainframers. 🙂  


Kick your customers out of the data center.  Back in the day, going to the IT department often seemed like a trip to the soup nazi–you made a request and you got what you got.  End users would seldom dare to offer an opinion about infrastructure–it was certainly frustrating for end users, but at the end of the day, IT’s level of control kept things running smoothly.  In the interim years, as the power shifted to end-users for infrastructure decisions, chaos has ensued in the data center with the resultant spiraling of infrastructure TCO.  At some point, you need move your customers back out of the infrastructure business.  However, instead of doing it with a big stick, do it with trust.  As you start freeing up cycles for you team, have them start engaging with your customers to learn their business–become consultants.  If your customers believe you truly understand their needs and can trust you to address those needs, they will be more willing to get out of the infrastructure business–they have enough other things on their collective plates to worry about.


So, there are a couple of things to chew on.  Perhaps they clicked for you or perhaps they did not.  Either way, if you are looking at cloud solutions, either public or private, make sure you spend at least as much time on the operational aspects as you do on the technology and vendor selection.


PS Since John and Fred were the only ones brave enough to offer comments on the last post, they will be getting the aforementioned prizes.


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Omar,love your blog, thanks for driving the dialog. Agree that mainframes are not private clouds for many of the points you raise and the point that they were developed from a centralist approach with limited need beyond a fixed environment. I doubt we are heading back to a dump-terminal, given the requirements for mobility, which were minimally existent back in the day when network engineers had lab coats. Today's business environment is global, running 24x7x265 and we need to be able to connect-in where we are, when we want and on any multifunctional device that we choose to use. I believe this is more business led, then people/process or a technology led transition, as it was triggered by the needs of the business to maximize what they already owned within their data centers, reduce costs and improve shareholder value. Virtualization, allowed a consolidation phase, but it's also driving new approaches and technology to solve business challenges. In areas where innovation enables business, I would see this as technology-led and common when enabling adjacent opportunities, that prior to the technology did not exist or were not fully developed. While I appreciate vendor lock-in concerns, there is an inherent benefit that you will only get with standardization, which should be manageable and geared primarily towards satisfying the business requirements with the best you can afford.

  2. as to Kick your customers out of the data center"", to some extent they may even leave on their own. When I first joing my current employer 1 business unit wanted to be briefed on every change. We communicated better and ran clean, did formal meetings etc. the next year when I asked 'do you want to do this again' they said no, just keep doing what you are doing. So I agree if you have things running smooth, people will let you keep things running.As to ""Break out the Excel"" i dont think anyone writes code to perform any more, they assume that resources are infinite and the speed of light does not exist. That being said, if we can decouple people from the hardware they are not able to ask for 8 Gig of RAM for a server running 32 bit Windows.....As to your first comment, the technology showed what was possible and business demand got internal people to ask themselves why cant we do this? Its process driven now, but the first 20% was external technolgy and process. But i agree with our conclusion if just virutalize your existing process you will not do well (which is what business people are told, dont just automate your exising process)."

  3. Hi Omar,Perhaps you could use this topic for a Podcast?,Brad Reese