English – Page 3 – JanWiersma.com

Where is the open datacenter facility API ?

For some time the Datacenter Pulse top 10 has featured an item called ‘ Converged Infrastructure Intelligence‘. The 2012 presentation mentioned:

Treat the DC infrastructure as an IT system;
– Converge in the infrastructure instrumentation and control systems
– Connect it into the IT systems for ultimate control
Standardize connections and protocols to connect components

With datacenter infrastructure becoming a more complex system and the need for better efficiency within the whole datacenter stack, the need arises to integrate layers of the stack and make them ‘talk’ to each other.

This is shown in the DCP Stack framework with the need for ‘integrated control systems’; going up from the (facility) real-estate layer to the (IT) platform layer.

So if we have the ‘integrated control systems’, what would we be able to do?

We could:

Influence behavior (can’t control what you don’t know); application developers can be given insight on their power usage when they write code for example. This is one of the needed steps for more energy efficient application programming. It will also provide more insight of the complete energy flow and more detailed measurements.
Design for lower level TIER datacenters; when failure is imminent, IT systems can be triggered to move workloads to other datacenter locations. This can be triggered by signals from the facility equipment to the IT systems.
Design close control cooling systems that trigger on real CPU and memory temperature and not on room level temperature sensors. This could eliminate hot spots and focus the cooling energy consumption on the spots where it is really needed. It could even make the cooling system aware of oncoming throttle up from IT systems.
Optimize datacenters for smart grid. The increase of sustainable power sources like wind and solar energy, increases the need for more flexibility in energy consumption. Some may think this is only the case when you introduce onsite sustainable power generation, but the energy market will be affected by the general availability of sustainable power sources also. In the end the ability to be flexible will lead to lower energy prices. Real supply and demand management in the datacenters requires integrated information and control from the facility layers and IT layers of the stack.
…

Gap between IT and facility does not only exists between IT and facility staff but also between their information systems. Closing the gap between people and systems will make the datacenter more efficient, more reliable and opens up a whole new world of possibilities.

This all leads to something that has been on my wish list for a long, long time: the datacenter facility API (Application programming interface)

I’m aware that we have BMS systems supporting open protocols like BACnet, LonWorks and Modbus, and that is great. But they are not ‘IT ready’. I know some BMS systems support integration using XML and SOAP but that is not based on a generic ‘open standard framework’ for datacenter facilities.

So what does this API need to be ?

First it needs to be an ‘open standard’ framework; publicly available and no rights restrictions for the usage of the API framework.

This will avoid vendor lock-in. History has shown us, especially in the area of SCADA and BMS systems, that our vendors come up with many great new proprietary technologies. While I understand that the development of new technology takes time and a great deal of money, locking me in to your specific system is not acceptable anymore.

A vendor proprietary system in the co-lo and wholesale facility will lead to the lock-in of co-lo customers. This is great for the co-lo datacenter owner, but not for its customer. Datacenter owners, operators and users need to be able to move between facilities and systems.

Every vendor that uses the API framework needs to use the same routines, data structures, object classes. Standardized. And yes, I used the word ‘Standardized’. So it’s a framework we all need to agree up on.

These two sentences are the big difference between what is already available and what we actually need. It should not matter if you place your IT systems in your own datacenter or with co-lo provider X, Y, Z. The API will provide the same information structure and layout anywhere…

(While it would be good to have the BMS market disrupted by open source development, having an open standard does not mean all the surrounding software needs to be open source. Open standard does not equal open source and vice versa.)

It needs to be IT ready. An IT application developer needs to be able to talk to the API just like he would to any other IT application API; so no strange facility protocols. Talk IP. Talk SOAP or better: REST. Talk something that is easy to understand and implement for the modern day application developer.

All this openness and ease of use may be scary for vendors and even end users because many SCADA and BMS systems are famous for relying on ‘security through obscurity’. All the facility specific protocols are notoriously hard to understand and program against. So if you don’t want to lose this false sense of security as a vendor; give us a ‘read only’ API. I would be very happy with only this first step…

So what information should this API be able to feed ?

Most information would be nice to have in near real time :

Temperature at rack level
Temperature outside of the building
kWh, but other energy related would be nice at rack level
warnings / alarms at rack and facility level
kWh price (can be pulled from the energy market, but that doesn’t include the full datacenter kWh price (like a PUE markup))

(all if and where applicable and available)

The information owner would need features like access control for rack level information exchange and be able to tweak the real time features; we don’t want to create unmanageable information streams; in security, volume and amount.

So what do you think the API should look like? What information exchange should it provide? And more importantly; who should lead the effort to create the framework? Or… do you believe the Physical Datacenter API framework is already here?

Good API design by Google : http://www.youtube.com/watch?v=heh4OeB9A-c&feature=gv

Everything is ‘Sustainable’

Not only is everything Green (especially in IT) and everything ‘low-PUE’ (especially in the Datacenter), but everything seems to be ‘sustainable’ also:

Credit: XKDC

The ‘green’ PUE monster…

My fellow Datacenter Pulse (DCP) colleague Mark Thiele wrote a good article on the use of PUE in the datacenter industry. He basically argues that you should look at the TCO of the datacenter and have a holistic view (like we promote with the DCP stack)

He opens with the ‘my PUE is better than yours remark’ we see going around in the industry. This is mentioned before by the Green Grid; the misuse of PUE. (I have written several articles about this issue on my Dutch datacenter blog)

Well guess what… we kinda created this monster ourselves;

Commodity

Datacenter are going commodity. Differentiation is in efficiency; looking at all the signs in the datacenter industry: the datacenter is becoming a commodity. The general idea is that any successful product will end up a commodity. See Simon Wardley’s excellent presentations on this subject.

Example signs are:

Factory production of datacenter units. (See Mark’s “The Manufactured Assembly Line Data Center” and “Your Next Data Center – Can You Say: Cookie Cutter”.
Facebook ‘opensourcing’ their datacenter design. eBay’s Open RFP is kinda in the same area.

(got lots more, but for an other blog and beyond the point now…)

Most of this leads to technology being available to everyone. You still need a big budget to start building a datacenter but cost is coming down thanks to advances in IT technology (like: do we still need to build TIER4?) and facility technology. Great example is the option to build modular and from an assembly line. This reduces datacenter production cost and you can spread CAPEX across time.

For any commodity product the competitive advantage diminishes, prices go down and if you’re in the market of selling the stuff: your differentiation is on price and efficiency.

So we push towards efficiency and lowering our operational cost, to be cheaper that the competition. It doesn’t matter what type of datacenter owner you are (enterprise, cloud, co-lo, whole sale..) the competitive advantage is in the operational cost. Everyone already has a SAS70, ISO27001, ISO9001, PCI, etc.. certificate. Everyone can get and build the technology and at some point it doesn’t pay off to worry about the small engineering details anymore; the cost are too high to get enough competitive advantage in return.

Marketing & Sales

If you’re in the datacenter co-lo or whole-sales business then your marketing and sales guys are trying to look for the (next) USP.

With the datacenter efficiency on the rise, it’s nice to have a single figure to tell your customer you are more efficient that the competition (and able to offer lower prices with it..).

PUE presented a great opportunity to get a nice USP for our sales guys. And I can’t blame them: it’s hard to sell a (going) commodity product and it’s something our customers are asking for.

Sustainable & marketing

The whole ‘green wash/hype’ (before the economic crisis) added to the misuse of PUE from a sales and marketing perspective. Everyone was, and still is, building the next greenest datacenter on this planet. It would be nice to have a single figure to promote this ‘green stuff’ and tell the world about this new engineering marvel… and PUE is happily adopted for this.

On the enterprise/cloud datacenter owners side it’s not very different.. it’s just another angle. Especially the larger datacenter (cloud) owners are pushed from a marketing perspective thanks to organizations like Greenpeace. They demand full disclosure of datacenter energy use and sustainability on behalf of the world’s population.

PUE is a nice tool to get some of the pressure off and tell the world you have the greenest datacenter operation, like Facebook, Google, Microsoft and others are now doing. The problem with those numbers is they don’t say anything without the full context. And like Mark says in his article; it doesn’t say anything about the full datacenter stack.

Sustainable & Government

The really interesting thing I have been dealing with recently is government and PUE.

Many state and local government organizations are looking at datacenters from an energy use perspective. This focus is thanks to reports from research and governmental institutes (for example EPA) and organizations like Greenpeace.

Government can either use the ‘carrot (subsidies) or stick (penalties)’ approach but it always requires some kind of regulation and some form of measurement. They happily adapted PUE for this.

The main problem with this is that PUE is not ready to be audited. Sure general guidelines for PUE calculation are available, but it still doesn’t have all the full details and leaves opportunity to ‘game the system’. It also doesn’t address the full holistic datacenter approach and the fact that you cannot use PUE to compare different datacenters.

Datacenter customer

Some of the governmental organizations are also using PUE for their co-lo tenders. And they are not the only ones. More and more RFP’s on the datacenter market state a specific PUE number or target with additional credits for the lowest number.

I can’t blame the datacenter customer; the datacenter is a pretty complex facility box if you’re not educated in that industry. It would be nice to just throw some numbers at it like TIER1-4 and PUE1-2 and select the best solution provider on the market…

I can’t blame the datacenter owner for the answer with ‘the best possible number he can think of’… they just want the business…

Datacenter vendor

As usual I’m part of the problem also. When I go shopping for the next big thing in datacenter technology, PUE is always part of the conversation.

Datacenter equipment vendors (especially cooling and power) are happy to throw some numbers my way to convince me that their solution is the most efficient.

The PUE numbers are on the equipment spec sheets, on the vendor website and in the sales meeting… but at the end I always have to conclude that our little number dance really doesn’t tell me anything. Just like Mark mentions: I go back to TCO.

Our own monster

So… we created this monster as a datacenter industry. Owners and consumers. Government and industry groups. I can also assure you that this will continue and will also happen to some of the great other Green Grid initiatives like CUE, WUE and the Maturity Model. It’s just a way of trying to put a number on what can be a very complex stack of functions called ‘the datacenter’.

Only way to diminish the monster is to educate our industry colleagues and our customers. And stop throwing the numbers around…

For the record1: the use of PUE

Don’t get me wrong, I love PUE and have used it successfully many times to benchmark my own data centers and prove to senior management that we progressed in efficiency. It’s also the way the EU Datacenter Code of Conduct works: show progress every year by calculating the PUE for the same datacenter with the same calculation method. This way you will have apples – apples situation.

Its just that I don’t like the way PUE is used in the above examples…

For the record2: On datacenter and green

Full disclosure: Datacenters are not green and will never be green. They consume large amounts of energy and will consume more energy in the future. All thanks to Jevons Paradox and the fact that we start to consume more CPU/Storage if prices go down…. And yes, someone has to build datacenters for all the CPU’s and disk’s…

See GreenMonk – Simon Wardley on ‘Cloud & Green’

I do think that:

1. We should aim to build the most efficient datacenters on the planet. It should not only focus on energy consumption but on all resources used for build and operation.

2. We cannot keep up with the rising demand from an energy-grid perspective. We should start looking for alternative ways for datacenter builds and deployment.