John Willis Honors Me with Inaugural Cloud Cafe Podcast

I am the inaugural guest in John Willis's Cloud Cafe podcast series. I couldn't be more honored.

Those of you who have been following this whole "what is Cloud Computing" debate may have had the opportunity to see the conversations between several bloggers regarding how to define cloud computing and related technologies. John Willis, of the John Willis ESM Blog, is making a key contribution by taking on the challenge of classifying vendors in this space. As I had some issues with his classification of Cassatt, he thought the best way to resolve that was to invite me to launch his new series.

Two things were resolved in this podcast.

First, I learned first hand what a classy guy John is. He handled the interview very well, let me talk my butt off (a talent I got from my minister mother, I think) and had several observations over the course of the conversation that showed his tremendous experience in the enterprise systems management space. I feel quite sheepish that I ever hinted that he wasn't being forthright with his audience. Lesson gratefully learned; apology gladly offered.

Second, John and I were always much closer in our visions of cloud computing, utility computing and enterprise systems than it might have appeared at first. Our conversation raged from the aforementioned "what is cloud computing" question, to topics such as:

• the relationship between cloud and utility computing,
• the cultural challenge facing enterprises seeking the economic returns of these technologies,
• how cloud and utility computing revolutionize performance and capacity planning, and
• where Hadoop and CloudDB fit into all of this.

In the end, I think John and I agreed that cloud computing is more than just virtualization on the Internet. I very much enjoyed the conversation, and I hope you will take the time to listen to this podcast.

Got questions or comments? Post them here or on John's blog; I will check both.

Finally, I will be working to get Cassatt's entry in John's classifications updated as a result of the discussion.

Green Aware Programming

monkchips writes about "green aware programming", as coined by Christopher O’Connor, vice-president strategy and market management, Tivoli. I responded and pointed out that "green = cheap" in the utility computing world.

Analyzing the Green opportunity

I just want to quickly bring Ken Oestreich's analysis of the Green Grid meeting in San Francisco (Day 1 and Day 2), and its aftermath to your attention. Pay special attention to the aftermath post, as it is one of the most well thought out statements of the status and opportunity for the Green Grid organization I have seen.

Ken really knows his stuff with respect to the Green Data Center movement, so if you have any interest in the subject at all, subscribe to his blog. His earlier analysis of DC energy efficiency metrics is an all time classic on the subject.

The IT Power Divide

The electric grid and the computing grid (RoughType: Nicholas Carr): Nicholas describes the incredible disconnect between IT's perception of power as an issue

...[O]nly 12% of respondents believe that the energy efficiency of IT equipment is a critical purchasing criterion.

and the actual scale of the issue in reality

...[A] journeyman researcher named David Sarokin has taken a crack at estimating the overall amount of energy required to power the country's computing grid...[which] amounts to about 350 billion kWh a year, representing a whopping 9.4% of total US electricity consumption.

Amen, brother. In fact, the reason you haven't heard from me as often in the last two to three weeks is that I have been steadfastly attending a variety of conferences and customer prospect meetings discussing Active Power Management and SLAuto. What I've learned is that there are deep divides between the IT and facility views of electrical efficiency:

• IT doesn't see the electric bill, so they think power is mostly an upfront cost issue (building a data center with enough power to handle eventual needs) and an ongoing capacity issue (figuring out how to divide power capacity among competing needs). However, their bottom line remains meeting the service needs of the business.

• Facilities doesn't see the constantly changing need for information technology of the business, and sees electricity mostly as a upfront capacity issue (determining how much power to deliver to the data center based on square footage and proposed Kw/sq ft) and an ongoing cost issue (managing the monthly electric bill). The bottom line in this case is value, not business revenue.

Thus, IT believes that once they get a 1 Mw data center, they should figure out how to efficiently use that 1 Mw--not how to squeeze efficiencies out of the equipment to run at some number measurably below 1 Mw. Meanwhile, facilities gets excited about any technology that reduces overall power consumption and maintains excess power capacity, but lacks the insight into what approaches can be taken that will not impact the business's bottom line.

With an SLAuto approach to managing power for data centers, both organizations can be satisfied--if they would only take the time to listen to each other's needs. IT can get a technical approach that minimizes (or has zero effect) on system productivity, while facilities sees a more "optimal" power bill every month. Furthermore, facilities can finally integrate IT into the demand curtailment programs offered by their local power utilities, which can generate significant additional rebates for the company.

Let me know what you think here. Am I off base? Do you speak regularly with your facilities/IT counter part, and actively search for ways to reduce the cost of electricity while meeting service demand?

Links - 09/10/2007

Brave New World (Isabel Wang): I can't begin to express how sorry I am to see Isabel Wang leave the discussion, as her voice has been one of the clearest expressions of the challenges before the MSP community. However, I understand her need to go where her heart takes her, and I wish her the best of luck in all of her endeavors.

(Let me also offer my condolences to Isabel and the entire 3TERA community for the loss of their leader and visionary, Vlad Miloushev. His understanding of the utility computing opportunity for MSPs will also be missed.)

MTBF: Fear and Loathing in the Datacenter (Aloof Architecture: Aloof Schipperke): Aloof discusses his mixed feelings about my earlier post on changing the mindset around power cycling servers. I understand his fears, and hear his concerns; MTBF (or more to the point, MTTF) isn't a great indicator of actual service experience. However, even by conservative standards, the quality and reliability of server components has improved vastly in the last decade. Does that mean perfection? Nope. But as Aloof notes, our bad experiences get ingrained in the culture, so we overcompensate.

CIOs Uncensored: Whither The Role Of The CIO? (InformationWeek: John Sloat): Nice generality, Bob! Seriously, does he really expect that *every* IT organization will shed its data centers for service providers? What about defense? Banking? Financial markets? While I believe that most IT shops are going to go to a general contractor/architect role, I think there is still a big enough market for enterprise data centers that markets to support them will go on for years to come.

That being said, most of you out there should look at your own future with a service-oriented computing (SOC?) world in mind.

An easy way to get started with SLAuto

It's been an interesting week, leading up to the Labor Day weekend, but as of this morning I get to talk more openly about one project that has been taking a great deal of my time. As I have blogged about Service Level Automation ("SLAuto"), it may have dawned on some of you that achieving nirvana here means changing a lot about your current architecture and practices.

For example, decoupling software from hardware is easy to say, but requires significant planning and execution to implement (though this can be simplified somewhat with the right platform). Building the correct monitors, policies and interfaces is also time intensive work that requires the correct platform for success. However, as noted before, the biggest barriers to implementing SLAuto and utility computing are cultural.

There is an opportunity out there right now to introduce SLAuto without all of the trappings of utility computing, especially the difficult decoupling of software from hardware. It is an opportunity that the Silicon Valley is going ga-ga over, and it is a real problem with real dollar costs for every data center on the planet.

The opportunity is energy consumption management, aka the "green data center".

Rather than pitch Cassatt's solution directly, I prefer to talk about the technical opportunity as a whole. So let's evaluate what is going on in the "GDC" space these days. As I see it, there are three basic technical approaches to "green" right now:

1. More efficient equipment, e.g. more power efficient chips, server architectures, power distribution systems, etc.
2. More efficient cooling, e.g. hot/cold aisles, liquid cooling, outside air systems, etc.
3. Consolidation, e.g. virtualization, mainframes, etc.

Still, there is something obvious missing here: no matter which of these technologies you consider, not one of them is actually going to turn off unused capacity. In other words, while everyone is working to build a better light bulb or to design your lighting so you need fewer bulbs, no one is turning off the lights when no-one is in the room.

That's where SLAuto comes in. I contend that there are huge tracks of computing in any large enterprise where compute capacity runs idle for extended periods. Desktop systems are certainly one of the biggest offenders, as are grid computing environments that are not pushed to maximum capacity at all times. However, possibly the biggest offender in any organization that does in-house development, extensive packaged system customization or business system integration is the dev/test environment.

Imagine such a lab where capacity that will be unused each evening/weekend, or for all but two weeks of a typical development cycle, or at all times except when testing a patch to a three year old rev of product, was shut down until needed. Turned off. Non-operational. Idle, but not idling.

Of course, most lab administrators probably feel extremely uncomfortable with this proposition. How are you going to do this without affecting developer/QA productivity? How do you know its OK to turn off a system? Why would my engineers even consider allowing their systems to be managed this way?

SLAuto addresses these concerns by simply applying intelligence to power management. A policy-based approach means a server can be scheduled for shutdown each evening (say, at 7PM), but be evaluated before shutdown against a set of policies that determine whether it is actually OK to complete the shut down.

Some example policies might be:

• Are certain processes running that indicate a development/build/test task is still underway?
• Is a specific user account logged in to the system right now?
• Has disk activity been extremely low for the last four hours?
• Did the owner of the server or one of his/her designated colleagues "opt-out" of the scheduled shutdown for that evening?

Once these policies are evaluated, we can see if the server meets the criteria to be shut down as requested. If not, keep it running. Such a system needs to also provide interfaces for both the data center administrators and the individual server owners/users to control the power state of their systems at all times, set policies and monitor power activities for managed servers.

I'll talk more about this in the coming week, but I welcome your input. Would you shut down servers in your lab? Your grid environment? Your production environment? What are your concerns with this approach? What policies come to mind that would be simple and/or difficult to implement?

Links - 08/16/2007

Convergence of Virtualization and Green Data Center Trends Could Be Perfect Timing for Microsoft (ITBusinessEdge: Kachina Dunn): Kachina notes that Microsoft may gain the most from the way the virtualization market is setting up. Combine that with the comments that Chris Kanaracus made about Microsoft's "compute cloud" strategy, and you begin to get the feeling that Mr. Softy may out-engineer its rivals in utility computing technology. I hope not, because (like VMWare) they are still obsessed with locking people into their platform. We need that utility computing portability standard!

Ozzie Reveals More Details of Cloud Development Platform (RedmondDeveloper: Chris Kanaracus): Another good breakdown of Microsoft's "PaaS" (Platform as a Service) play. Ray's comments at the end of the article give me the feeling that Google, Amazon, Salesforce.com and others are not free and clear of MSFTs influence, yet.

"We believe we are the only company with the platform DNA that's necessary to viably deliver this highly leveragable platform approach to services. And we're certainly one of the few companies that has the financial capacity to capitalize on this sea change, this services transformation."

Grid computing: Term may fade, but features will live on (ComputerWorld: Barbara DePompa): Barbara discusses the view of many that the term "grid computing" may go extinct in the face of virtualization and utility computing. My own opinion is that "grid" has actually had its definition narrowed back to its roots: grid computing platforms provide resource allocation to job-based computing processes, like batch data processing, image rendering and HPC. Utility computing is the term that applies to all "computing on demand" applications, including grid applications.

Automation and going green in the data center (NetworkWorld: NewDataCenter): Someone at NetworkWorld saw the light at Next Generation Data Center in San Francisco earlier this month. I just wanted to welcome them aboard, and invite them to explore the importance of SLAuto to both automation and green practices.

Links - 08/14/2007

What I Learned at NGDC: Technology is Ready, Users are Not (GridToday: Derrick Harris): I worked the Next Generation Data Center show (which was piggybacked on LinuxWorld this year), and have also spent the last 18 months trying to convince system administrators to adopt NGDC practices. What Derrick says here generally rings true, though he is perhaps more skeptical than I would be at this point. Of course, if we could make it easier to get started in the NGDC world...stay tuned.

In search of the green data center (statesman.com: Brian Bergstein [AP]): If there is one statement that clearly defines the resistance of most system administrators to simple energy savings practices, such as--oh, I don't know--turning off unused servers, it is the following:

"There are probably two key metrics for the IT guy: 'no downtime' — if the boss's e-mail doesn't work, he hears about it right away — and 'no security breaches on my watch,' " says Eric Birch, executive vice president of Degree Controls Inc., which sells a system that increases electronics cooling efficiency. "They normally do not know, don't care and aren't measured by their electric bill."

Man, how true, how true. Guess what folks, in environments like dev/test labs where "no downtime" is not the same as "no loss of productivity", its time to change our view. SLAuto can be used to automate the power state of servers based on a variety of policies, including schedules, utility events and even--oh, I don't know--extended disuse.

This article also mentions a variety of good technologies to look at if you are building a power-efficient data center.

SaaS invades enterprise software markets (ZDNet: Phil Wainewright): One of the reason SaaS vendors are making some headway (though not on all fronts, according to the article), is the fact that ERP apps require lots of expensive infrastructure and operational support. In fact, these inefficiently coded processing hogs make up a huge part of many IT department operations budgets, and probably register a significant impact on the Facilities budget, as well. SaaS is one form of utility computing that mitigates those costs for businesses that don't want to be in the IT operations business. Stating the obvious for many, I am sure, but one question that comes out of the practice is how will these SaaS users protect themselves from failing infrastructure that they don't own?


EPA REPORT GIVES DATA CENTERS LITTLE GUIDANCE (SearchCIO.com): The early reviews are in, and this report seems far from a home run. However, it is a start, and that even debate over its effectiveness can only help make us more aware of power consumption issues. What is really interesting is the view that several interviewees had that software was a big part of the problem:

"Boergermann said the software industry should share in the responsibility in reducing power consumption. For example, many business applications require huge amounts of server processor capacity to run simple tasks, which cause servers to consume more energy. Boergermann said he has one application that manages his bank's property appraisals. He said just scrolling through a window causes the application to use 100% of its server's capacity. He said an application shouldn't hog so much energy for such a simple task...

...Gartner's Kumar, who said he generally admires the decades-long energy efficiency efforts by leading hardware vendors, especially HP and IBM, also wondered why the Microsofts, Oracles and SAPs of the computing industry have gotten off easily."

Links - 08/09/2007

Technology companies tout greener credentials, but significant improvements are well off (Associated Press via Technology Review): This article is a layman's explanation about the energy consumption imposed by data centers, and the reasons behind that consumption. There are some interesting statistics here (most of which are recycled--pardon the pun), but the article is light on possible solutions. Remember, the entire purpose of SLAuto is to deliver the required service levels for your business using the most cost (and energy?) effective resources necessary to do so.

"Why is Amazon Web Services partnering with NaviSite?" (Isabel Wang): An overview of several interesting trends around utility computing in the managed hosting market. My comments:

1. NaviSite is providing an interesting service here, and one I think will need to evolve to an automation model eventually. Today it looks like your same old monitoring-only "management" environment, but with a few interesting hooks who knows.
2. I love the PlanetWide Media story only because it is one of the first example of "Web 2.0" infrastructure mashup that I've seen. Why not Web 3.0? Because I would bet right now that Planet Media is economically locked in to LayeredTech for the foreseeable future (i.e. the cost of moving their software would negate the benefit of moving it).
3. Hmmm. Perhaps the future goes so far as to divide mindshare into recombinable building blocks. (OK, sorry, the BS meter pegged on that one...)
4. Isabel wraps up with a comment about the long tail of computing itself, which I believe is the real next revolution in IT that will drive new businesses and perhaps even industries. I believe Nicholas Carr agrees, but we shall have to wait an see.

Green data center scuttlebutt from NGDC conference (Server Specs: SearchDataCenter.com): The interesting part of this video to me is the description of the GDC panel discussion as "sniping". I agree, and that's why I left early. Nothing interesting came out of the discussion other than the fact that each major vendor is still months or even years away from actually reducing the energy burden of the data center market (reinforcing the AP article above). I say watch for solutions that may be a little more short term.

Links - 08/08/2007

As you can see on the upper right hand column of my blogspot page, I have added myself to the findtechblogs.com realm. Seems like a very cool service, and its already given Ken Oestreich some visibility. (See below.)

The CMDB - An anemic answer for a deeper crisis (Fountnhead; Ken Oestreich): Ken is, of course, a collegue, so I may be a little biased, but I love what he is saying here. Basically, if you are keeping a CMDB, you are keeping manual records of the state of your data center. If you automate with a system that tracks its actions, then you have an automated way to keep those records. I think he washes over the legal requirements for a CMDB a little bit, but other than that, you need to read this. I learned of this post via Google Alerts, and findtechblogs.com.

Nirvanix To Challenge Amazon S3 (TechCrunch): A San Diego startup is daring to challenge Amazon's S3 dominance of the nacent Storage-as-a-Service market. Judging from the comments, these guys have their work cut out for them.

Green Grid lays out 2007 roadmap (Between the Lines; ZDNet): This was the only interesting piece of news to come out of the Green Data Center panel at LinuxWorld, IMHO. When combined with the EPA study, it looks like a trickle of real science being injected into the "green" hype. Its still all talk at this point, but I expect to see some useful tools and guidance from both sources. I hope that optimizing to service levels is one of the key criteria, though.

Want to save gas? Stop leaving your car idling in the garage!

History doesn't repeat, but it sometimes rhymes...

I remember the seventies, when gas prices skyrocketed (the first time) and there were suddenly all these tiny cars on the road. One member of my mom's congregation even showed up one Sunday with this crazy little car that ran on a motorcycle engine. It was made by some new car company called Honda, and it was one of the first years that Civics were sold in America.

As a nation, we clamored to change our lifestyles--ditching heavy steel muscle cars for sporty (or utilitarian) little "economy cars". Our approach to solving the energy crisis was to increase the efficiency with which our cars consumed energy. Note, however, it was not (by a long shot) to reduce the amount of driving we did.

Now flash forward to today, and take a look at the current energy crisis in America's (and the world's) data centers. Electricity is expensive, and growing more so (except for those lucky enough to have subsidised power). Add to that concerns about global climate change, and you've got company after company scrambling to be "green".

Again, however, note that the target is not to do less computing than we did before. In fact, if anything, the demand is increasing for information technology and business automation. I believe pushing the automation envelope is going to take more computing power than we know.

So, like the automobile vendors of the seventies, today's systems vendors are working hard to release "energy efficient" models of servers, laptops and desktops. They do this ostensibly to give us all a good feeling about what good stewards of our tiny planet we are, but in reality its all about saving money. None of this changes our worst behaviour, however; our tendency to leave as much capacity running as possible at all times, "just in case".

Of course, the server that uses the least amount of power is the one that is turned off. That's where Service Level Automation comes into the picture. As noted in the past, one of the key aspects of a good Service Level Automation platform is the capability of shutting down anything that isn't serving an immediate business need. Traditionally, I've always talked about this in relation to scale-out applications--your SLA platform should shut down servers not needed to meet current demand in such applications. Now, however, I want to talk about three use cases where SLA enhances the day to day power consumption of all applications in the data center.

1. Job-specific management. OK, think of every server you've touched in the last six months. How many of those served a short term purpose (e.g. getting a software release out the door), but frequently spend days unused for any purpose. I remember going days or even weeks between placing builds on staging servers in my previous life. Service Level Automation should be able to detect unused software payloads, and shut down that equipment until needed again by that or any other payload.
2. Time-specific management. Almost every data center (especially development and test labs) have systems that are hit hard during some portion of the day, then remain idle for the remainder. SLA should provide the capability to not only schedule system shutdowns, but to actually look at that status of systems to determine which are best candidates for shutdown. In other words, go beyond automating "blind" scheduled events to delivering intelligent management of system power cycles.
3. Power emergency management. One of the great benefits of living in the San Francisco Bay area is the incredible ingenuity of our power utility in encouraging companies to conserve power and "be good neighbors" in a power emergency. PG&E offers rebates to companies willing to join Demand Response programs, where they agree to voluntarily reduce electric consumption to help the utility avoid the infamous "rolling blackout".

The Silicon Valley Leadership Group has recently been hosting a series of events around "Energy Efficient Data Centers", one of which targeted how SLA could deliver on all three of the above. The response was tremendous--so much so that my employer has asked me to join a team building a simple targeted solution to these problems based on our already innovative SLA platform. I can't say much more right now, but I certainly will communicate all that I can as soon as I can.

By the way, the first lesson I've learned from all of this is that power measuring capabilities varies widely from data center to data center. Some companies can't tell you anything more than their monthly bill, others can show you power consumption over time at the individual server level. Part of the issue is that there are no "simple" power metering solutions at the server level...power controllers (i.e. iLO2) are just now starting to give management systems access to the power measurement tools on Intel and AMD boards. MPDUs have some good features, but they vary widely from vendor to vendor.

You can't control what you can't measure, so get on board system vendors! Give us the tools we need to measure and manage those beautifully efficient next generation servers. Heck, give us the tools we need to measure and manage all those older systems we have out there now. That would be more green by far than just squeezing another milliamp out of a MIP.