One of the interesting things I learned at Uptime Institute is the timing was right to explain why I named my company Green M3.  I told the story of how I started the company in response to a WSJ article. And, next let me tell you why Green M3.

I have as my tag line Monitoring, Metering, Managing ...

But, these 3 words starting with M where created after I figured I wanted to call my company Green M3.

Nicholas Carr's post triggered my own post on containers.

UPDATE: There's more on the data center philosophy of the 'Soft Boys in this interview with Manos and one of his colleagues. On the attraction of containers: "One of the things we like about them is we can take a bunch of servers and look at the output of that box and look at the power it draws. At the end of the day, we can determine, 'What is the IT productivity of that unit? How many search queries were executed per box? How many emails sent or stored?' You can get into some really interesting metrics. A lot of people say you can't look at the productivity of a data center, but if you compartmentalize it - not as small as the server level, but at some chunk in between - you can measure productivity."

Now that people are talking about containers and thinking down the line of evaluating performance per the container, it makes it easier for me to explain Green M3.  I tested this on a bunch of people, so let's put in down in writing.

In coming up with a method to evaluate Green performance in the data center, I needed a way to think and have the right mindset in looking at the problem. Then I hit upon abstracting to what it is you wanted, and computing needs to be measured in a universal way.  Processor technology, RAM, HD, network, various I/O technologies confuse the issue, and cloud the ability to evaluate things side by side. Computing is delivered in a box - 1U, 2U, 4U, Rack, but side by side comparison's are still hard as solutions required multiple servers.

How do you evaluate the IT solution implementation in one technology vs. another?

Then I started to think of things as the space it takes to encompass the solution. Characterize the space in abstract terms - KW required, Cooling required, network connectivity, compute power, and other TCO factors. Define the space, how big it is, what it does, and what it costs.

What is a universal unit of measure? The cubic meter. The M3 is meant to communicate cubic meter = meter x meter x meter, not Monitoring, Metering, and Managing. But, this is too hard to put in a tag line. 

A rack is 1.2 cubic meters.

A 40 foot container is 67.5 cubic meters.

A 20 foot container is 33 cubic meters.

This gave me the right framework, architecture method to evaluate different implementations.

If you apply the Green M3 method you can calculate the cubic meters of white floor space and compare it to the cubic meters required in a container, and associate a cost and performance per cubic meter. People tend to think of square meters/feet. But, to be efficient you need think about the metrics per cubic meters.

The good thing is I named my company back in Nov 2007, before containers became popular, and Christian explained to Nicholas Carr a benefit of containers. Also as background, part of what helped me understand this method is working as a distribution logistics engineer 20 years ago for HP and Apple where I learned to think in terms of boxes, pallets, and shipping containers. I remember working at Apple, when the Mac Plus was being introduced, and people were getting all excited about the Mac Plus vs. the Mac 512k. But, in distribution I told people it is just another box, it is no bigger, doesn't weigh anymore. It doesn't make any difference to us, other than we'll ship more of them.

When you abstract a technology how does it effect the cubic meter of data center computing?

I'll work on more on documenting the Green M3 Method, but here is the start.

I heard about this project a while ago, and thought it was naive at the time, giving end users the ability to monitor and set their power usage #'s.  I can tell these guys are not User Interface developers.

An easy UI I would have done is have a button to turn the system on and off.  The algorithms for on and off should be modified unseen from the users.  You test whether they are willing to keep the system on and when they turn it off to override it.  Expecting millions of people to play around with a dial to set energy savings is asking too much from users to guess on what dial settings are right for them.

Keep in mind when you want your users to save energy they need a simple User Interface. Do you want to save energy? Yes or No.  Don't give them a bunch of choices that will confuse them and waste their time.

The results were written in the NY times

The homeowners could go to a Web site to set their ideal home temperature and how many degrees they were willing to have that temperature move above or below the target. They also indicated their level of tolerance for fluctuating electricity prices. In effect, the homeowners were asked to decide the trade-off they wanted to make between cost savings and comfort.

The households, it turned out, soon became active participants in managing the load on the utility grid and their own bills.

“I was astounded at times at the response we got from customers,” said Robert Pratt, a staff scientist at the Pacific Northwest National Laboratory and the program director for the demonstration project. “It shows that if you give people simple tools and an incentive, they will do this.”

And thank god, they finally figured out that the UI needed to be simpler.

After some testing with households, the scientists decided not to put a lot of numbers and constant pricing information in front of consumers. On the Web site, the consumers were presented with graphic icons to set and adjust.