Today (Nov 15th), Data Center Pulse hosted a workshop on a number of topics at the 7x24 Exchange conference here in Phoenix AZ. The workshop included a presentation and discussion on the Data Center Stack (stack.datacenterpulse.org) and how it can be applied. This blog talks to some of the presentation and discussion…….
---------------------------------------
We at Data Center Pulse believe that the traditional data center manager / architect / engineer's job has the opportunity to change and offer more added value to the CIO and the Stack (stack.datacenterpulse.org) is the tool to help you effect that change.
"Why are you saying we don’t add enough value?”, you say. "My data center staff keep the vital technology of our company up and running 24x7x365 and we keep on top of new IT device installs, changes and decommissions". While this clearly reflects our primary objective - uptime - unfortunately, more often than not, we are only remembered when things go wrong - nobody gets rewarded for delivering consistently excellent service anymore. We need to deliver the baseline service and add value above and beyond that nowadays.
At DCP, as data center owners and operators ourselves, we see many opportunities for adding value to the CIO in areas as wide ranging as energy efficiency (ok, kind of obvious but read on), data center IT and Facilities integrated design (or do you just do power and cooling and get frustrated about what 'those server/storage/network guys keep buying') and cloud computing (now hopefully you are scratching your head about the connection between your role and some esoteric architecture topic).
Why should you want your role to change? What frustrates us to want to change our role is that email you get - you know, the one you get in your inbox first thing with the subject 'the datacenter is too slow / expensive / inefficient / inflexible' (delete as appropriate or perhaps sometimes it is all of the above). What follows is usually a long night putting together Powerpoint slides for the CIO showing that a) the problems are in the datacenter, but they are to do with the IT kit not the facility and (this you wish you could put in a slide) b) you keep seeing the problem happening and you've got a pretty good idea how to fix it, if only you could sit that IT department down and talk to them.
And guess what, it doesn’t matter if you come from the Facilities side or the IT side. If you are working in the data center industry, you’ve done that Powerpoint one too many times.
So how do we go about adding value and fixing the problems and making that change in your role happen?
This is what drove us at DCP to create the Stack (stack.datacenterpulse.org). Born of our collective experience in driving data center architecture across different large enterprises, it is intended to be a tool for you to use as a Facilities- or IT-aligned data center manager to set up the conversations for you to start managing the data center service, not just the rack and stack operation and start adding more value to your company.
The stack simply sets out the groupings of technology and resources that need to be considered when designing a data center – from the basic resources of land, power, water through the distribution of power/cooling, spatial organization of the MEP and raised floor up into the IT area with server/storage/network and then into infrastructure services like virtualization and commodity application components like messaging.
So let’s talk quickly about a couple of ways that our DCP members attending the event today in Phoenix talked about their experiences applying the Stack to add value or how they envisage using the Stack.
Data Center Design – the Stack served as a reference model for creating and driving the discussion about the design of new data centers. Pushing that a stage further, members talked about the challenge of designing reduced resiliency data centers (Uptime tier 1 or 2) and communicating the reduction in expected service levels from the expected near-100% of Uptime tier 4) to the IT and application layers above, who would now be expected to design to anticipate failure (planned or unplanned) in return for better resiliency overall at a cheaper price and more solid execution of DR capabilities.
IT product selection – using the Stack, members discussed composing a cost model of all data center components that make up or supply a cabinet (power, RU, space, network ports, structured cabling etc) and using this to drive the right IT product selections. By holistically looking at the data center costs, you can concentrate on sourcing the components that make the most efficient use of all of your data center resources, concentrating on the most expensive elements.
Dialog with the application community – most application developers are not interested in data center design. Fact of life. They’d rather be coding and creating new applications for the business and this is fine – that drives up your stock price. However, there is an opportunity to sit down with the Stack and discuss how their application drives technology decisions and costs when they want to create cross-business application services like messaging, compute, authentication etc. Then, they want to achieve a lower cost in order to sell their services and you can use that opportunity and the Stack to drive a holistic data center design discussion.
Mechanical / Electrical Product design – members discussed several ideas to advance the efficiency of power and cooling in the data center (coverage on datacenterpulse.org). Facilities-aligned members can use the Stack in order to have a conversation with their IT-aligned colleagues about trends in IT (higher levels of the Stack) that are driving changes in MEP product requirements.
How do you use the Stack in these conversations? In the session today, we discussed parallels to the network OSI stack creation (http://en.wikipedia.org/wiki/OSI_model). Why was it created? Simply because different vendors looking to build components to internetwork computers at the time (server, NIC, bridge , cable vendors etc) had to come together and establish a common language and interplay rules for layers of functionality involved in internetworking computers. We are at a similar stage in the datacenter business – we need that common language and understanding of our respective functionality at different layers of the data center Stack in order to arrive at the optimum data center design, choose the best server to purchase, drive the best application design and specify the next MEP product design.
You don’t need to go out and become an expert in other technology areas. Facilities folks don’t need to take Cisco exams. Network guys don’t have to become Professional Engineers. However, what you should do is to learn the basic mechanics of what functionality is occurring at different layers of the Stack and how it contributes to the overall mission of the data center. Terms vary by layer and often language is the biggest barrier to entry to any dialog at any layer in the Stack.
Once you’ve done that, you can start to form and drive working groups on topics high on your and your CIO’s agendas, pulling in IT, Facilities, energy providers, regulators etc. to solve some of those problems before you get that Monday morning email!
In the coming weeks, we’ll follow up this blog with discussions that go into more depth on the above examples of the use of the Stack. We’d love to get feedback from you on potential or actual usage experience of the Stack and/or if you’d like to submit ideas to improve the Stack. Send it to stack@datacenterpulse.org.
I arrived early at the eBay San Jose campus as the rain continued to drench northern California. I joined a group of lively eBay employees from technology operations, product development and IT on a bus headed to Sacramento. We were on a journey to put our oldest data center to rest. This journey had started over a year and a half earlier, long before I had joined eBay. At that time, an aggressive plan was put into motion. The goal was to consolidate the data center portfolio to decrease costs, increase our availability and take eBay to the next level of Operational agility. It was a lofty goal.
As the bus continued to roll north on I-80, I saw the pride on the faces of the team as they reflected back on the project. They should be proud! This is one of the hardest problems to solve in IT. They had successfully decoupled the app and DB tiers, landed them in a temporary location, moved live databases and applications – all without causing a single outage to the site.
In February of 2009 I had a very unique event happen. It was by far, one of the geekiest things I had ever done. I was still working at Sun and we had rebuilt the Data Center POD concepts into Second Life. We had created a Data Center Island that allowed anyone to walk into this virtual world and watch how the data center can be transformed from traditional power and cooling to the new modular, highly efficient configuration with PODs. They could also interact with the PODs to see how hardware fit and things could move around. A virtual-physical data center. That was geeky enough, but try this on for size. Greg Papadopolous (Sun's CTO & controller of over $2B in R&D funds) joined me for a live webecast directly from Second Life to Industry Analysts. They had created avatars for both of us that made us look much younger, more dignified (and skinnier) than we really were.
