So this time I tossed my digital camera and PC out of my bag and experimented with my iPad. With the iPad, I do not need a mouse or USB memory. Its charger is smaller and much lighter. Here’s what I found out.

Pros:

1. The shoulder bag got much lighter (1.8 pounds vs. 4.2 pounds). This is helpful. If you are in the US, you can carry a heavy bag from your car for the short distance to your place of meeting. In Japan, you walk a lot, and the heavy bag is not very convenient, especially in crowded trains at rush hours.
2. The always-on feature helps me to use it without booting up. If I don’t use audio or video applications, it lasts long enough to get to Japan (some ten hours).

3. Even without an Internet connection, I can check calendars and documents via DropBox and Documents.

4. Support for English and Japanese works flawlessly.
5. Power consumption of the iPad is less. It consumes 12W while my HP PC uses 65W.

Cons:

1. An iPad is basically a read-only device and is not really suitable for writing, except for short messages in email and other documents.
2. An iPad does not support USB memory unless in a special format, which does not help me very much. I do not want to upload sensitive files to the Internet via DropBox.

Now how did I cope with the two cons? This may not work for you unless you have a situation similar to mine. I travel to Tokyo and Osaka. I have close relatives living in these cities with a PC and an Internet connection. So if I need to use a PC, I borrow theirs and both problems above are solved.

From an energy efficiency point of view, an airplane can be lighter, consuming less fuel, and power consumption by an iPad is lighter, too.

With the two problems fixed, I would be happier. Incidentally, on this trip, I converted one of my relatives from a PC to an iPad. In Japan, Apple iPads are still very popular. She does not carry her PC around or write long documents, and she has minimum exposure to computing technologies. So far she is happy.

Some people project 2013 will be the year of the cloud, and hybrid clouds are talked of as one of the trends for the year to come. See here, here, here, and many other places.

As I said before, much of hybrid cloud is just talk and not reality, and there have been several showstoppers before now.

Some of the many factors making it hard to implement hybrid clouds are mainly technical:

Technical problems

Virtual machine (VM) file format

1. Public cloud: Amazon Web Services was the first to implement a public cloud, and AWS is now the de facto standard for public cloud. It uses its own proprietary file format (Amazon Machine Image, a.k.a AMI) running virtual machines on the Xen hypervisor. Their file format is not the same as the original Xen VM format. So even if you are running Xen hypervisor for your cloud, you cannot enjoy interoperability with AWS without converting your VM’s file format. For example, Citrix virtualization environment is based on Xen, but its file format is virtual hard disk (VHD), which is also the file format for Microsoft’s virtual machine.
2. Private cloud: In the enterprise market (private cloud), VMware’s VM file format (VMDK) is the de facto standard.
3. Hybrid cloud is an attempt to use both private and public clouds to process IT demands by optimizing suitable in-house and outsourced IT infrastructures as needed. So when we want to move VMs back and forth between public and private clouds, we need translations each time we move them across the cloud boundary. It may not be very hard to do so, because there are some translation tools readily available from vendors like Amazon and VMware (vmkfstools). It may be straightforward to move VMs that are not in execution, but VMs in execution are generally hard to move with their execution state intact. See the next.

Physical movement of VMs

• If we want to exploit public and private clouds for an application in execution, that execution instance may be transported between two or more clouds to find the most suitable execution environment. One big issue is the distance between clouds. VMware’s vMotion allows you to transport your VM up to something like 100 km (80 miles) but no farther. With this physical restriction, what you can do with hybrid cloud may be limited by the distance between clouds.

Various support environment

• Cloud is not just virtualization but needs a comprehensive environment, such as management and support, including tools and security considerations. Each cloud tends to come with its own environment and idiosyncrasies, so what you can do easily in one cloud may not be as easy in another cloud. This would make managing a hybrid cloud cumbersome.

To date, most discussions on hybrid have been at a very abstract level and not at all concrete. People have talked about what we could do with hybrid cloud without referring to its concrete implementation. Recently, I came across yet another brand-new cloud company that claims to have solved the aforementioned problems. Greg Ness recently sent me email with a press release and wanted to show what CloudVelocity, his new company, is doing in the area of hybrid cloud.

I am by no means an expert in hybrid cloud computing or any kind of cloud computing, for that matter, but let me try to review how hybrid computing is implemented with their technologies. To support hybrid cloud, VMs need to move back and forth between private and public clouds. How can we implement such a move? Because an execution space is not shared between a public and a private cloud, we cannot literally move a VM across the clouds. What we do is to make a copy of a VM executing at one cloud and transport its execution status to a cloned VM at another cloud. Then we can disable the original VM and enable the cloned one. If a VM is not in execution, it is not that hard. But if it is in execution, it is much harder.

If both private and public clouds are implemented with the same technologies and the distance is less than, say, 100 km, the same VM could be transported with a utility like vMotion. But in most cases, two cloud environments are not the same (see the technical problems described above), and the distance could be greater. Also, you can move only virtualized applications but not traditionally maintained applications, because you cannot assume all the applications have been virtualized into a VM format.

We need to have carbon copies of VMs and non-VM versions of applications (that need to be virtualized) on the other side. That means you need to have carbon copies of your applications running on a public cloud. This sounds like a disaster recovery (DR) system.

Disaster recovery/fail-over system

In such a system, you duplicate the applications that are running at the primary location and operate them with options at the secondary location. These options include active-active and active-passive configurations. Active-active means that the machines (and thus applications) are live at both the primary and the secondary locations at the same time, with data being copied from the primary to the secondary sites. In this scenario, when the primary location cannot operate any longer for any reason, the secondary location can take over seamlessly. The active-passive configuration may not guarantee complete synchronization, because the passive one in the secondary location does not run until the primary location can no longer support applications.

In any event, if we duplicate the whole thing for the secondary site, as in the case of DR in an active-active fashion, the duplicated copies are always in the secondary site with dedicated servers. This situation is the farthest from cloud computing in spirit, especially for public clouds.

What we need is a solution like this:

• Copies on the other side made only when needed (on-demand).
• Noninteroperability problems overcome:
• Resolve VM file format and other incompatibilities among major cloud systems, such as AWS, Rackspace, Microsoft, and OpenShift.
• Handle physical vs. virtual applications in an IaaS cloud environment.

Now back to CloudVelocity. I visited Greg Ness and Rajeev Chawla, CEO, at their headquarters in Santa Clara. They claim to have implemented a solution to solve the problems discussed above.

From left: Rajeev Chawla (CEO) and Greg Ness (VP Marketing). See here for their bios.

They have developed a comprehensive system for implementing hybrid cloud that they call One Hybrid Cloud Platform (OHCP), which is depicted in the following picture. Applications move across the cloud boundary in five steps:

1. Host discovery—Inventory your private cloud (data center), which consists of all the pertinent IT hardware and software.
2. Blueprinting—Create a database of how the discovered components are put together.
3. Cloud provisioning—Duplicate and create VMs on the target cloud (translating VMs and virtualizing physical applications if necessary).
4. Synchronization—Synchronize VMs between the two clouds.
5. Service initiation—Let the duplicated VMs take over and disable the original VMs.

CloudVelocity’s comprehensive One Hybrid Cloud Platform.

This sounds easy. How do they do this? That will be covered in Part 2.

Fujitsu hosted the conference, and attendance was free and included breakfast, lunch, and cocktails. Over the years, the number of attendees has grown, and ICT analysts, such as Gartner and IDC, were in the crowd. On top of that, they got very prominent speakers, like Dr. John Hennessy, president of Stanford University, and Nicholas Negroponte, founder of MIT’s Media Lab. It is a good deal, to say the least

The following is my take on what was presented.

Fujitsu develops products over a wide range of areas, including hardware and software, as well as services.

Fujitsu covers many areas, as shown in the picture above. Many Japanese companies are considered good at hardware but not software. But Fujitsu actually does pretty well in the areas of software and services as well as hardware. Because they put their foot in many areas and their base is ICT, it is very interesting to see how they view the current state of ICT. ICT used to stand by itself without much regard to other areas, like energy. In the past, ICT technologies alone could generate revenues. But things have changed a lot recently, and ICT needs to find other application areas. O.K., the following is how Fujitsu sees the world in conjunction with ICT.

This picture shows that ICT could be applied to areas like food/water, economy, energy, population/aging, health, natural disasters, and transportation. Cloud computing would tie them all together. If they are right about this, there are still a lot of application opportunities for ICT to generate revenues, which is good news to many people in the ICT field, including myself.

Following the first keynote on Fujitsu’s business, Stanford’s Hennessy gave a talk and there were three presentations by Fujitsu people. I covered Hennessy’s presentation in a previous blog. The Fujitsu presentations were categorized as future solutions for smart energy deployments, which is very relevant to what I look at these days. Along with these three technologies, a total of 23 technologies were demoed. First, let me touch on the three presentations

Energy management system (EMS)

The first was about Fujitsu’s energy management system (EMS). In 2011, electricity saving by visualization was implemented to cope with the power shortage after the big quake and the shutdown of the 50 nuclear plants in Japan. From 2012 to 2013, Fujitsu developed a cloud-based building energy management system (BEMS). From 2013 to 2015, it plans to move its focus to smart city. An example of that is to cut power consumption by observing peak times and by controlling battery charging and discharging of laptops at offices. Their experiment showed that they could reduce total office power consumption by 2–3% by doing this. In most building energy management systems, attention is usually given to high-power consumers like HVACs. It is very Japanese to even pay attention to laptop battery charging. But who knows? Small savings may add up to a big saving.

OpenADR

The second was Fujitsu’s implementation of OpenADR.

Overview of OpenADR

Fujitsu was the first Japanese company to participate in the OpenADR 2.0a interoperability test. Demand and response (DR) is one of the easiest ways—by shaving off power at peak time—to generate logical power. Usually, when demand increases, supply must be increased to cope with the higher demand. Instead, demand is curtailed to fit the supply at a given time. In a way, logical power was generated to solve the demand-and-supply imbalance. OpenADR is a protocol specified by the OpenADR Alliance to dictate in what form the DR signal is transmitted. The member companies are listed here. I chatted with a person who was manning the booth. Their product is a demand response automation server (DRAS) paired with a client. Because OpenADR is a protocol specification, each vendor could build their products based on the standard communications protocol for competition. Fujitsu’s involvement is basically in the US; Japanese utilities are not ready to consider DR.

Efficient power supply

The third Fujitsu presentation was about the power supply, which has a conversion rate of 94.8%. An organization called 80 Plus promotes a high conversion rate for the power supply. Even with 80 Plus Platinum, however, the conversion rate is only 90%. Fujitsu developed a few technologies to increase efficiency. Fujitsu plans to release a product with this technology in 2014.

I had to be elsewhere so missed the subsequent sessions. I think ICT has a lot of potential in many areas. Energy is one, and Fujitsu seems to understand it very well.

Long ago, I read one of his papers but this was my first time to see him on the stage. Fujitsu has cultivated working relationships with many prominent research labs and universities throughout the world. Stanford is one of them.

Everyone knows that both Stanford and UC Berkeley incubated many excellent technology companies in Silicon Valley. Many came from Stanford, like SGI, Netscape, Cisco, HP, Yahoo, Google, and Sun, and then there was TCP/IP per Vint Cerf. So Stanford must have done something right.

Dr. John Hennessy

Hennessy’s talk was about transference between universities and the real world. But this could be applied to the enterprise world as well, as in spin-outs and spin-ins. In any event, let me summarize his points, some of which I have paraphrased, and ponder on how they might be applied to the real world.

First, he said new technologies were building blocks for new industries and therefore economic growth. Those technologies came from company and university research labs. He gave examples:

· Semiconductors—initiated by Bell Labs.

· Workstations—remember Xerox Parc’s Alto Computer?

· Internet—no explanation required.

· Web—made possible by the Internet, then made the Internet even bigger.

· Biotechnology—fundamental research was done at universities.

He continued by saying that universities are a source of:

· Discontinuous innovations

· Talent

Two points he wanted to make in his talk were:

1. How to promote innovation in a university or company.

2. How to transfer innovations to real products.

He made the first point clear by saying that it is important to pick the right set of people and let them drive the direction of research. Those people should include visionaries (who have compelling ideas), explorers (who give some direction to those ideas), and uninhibited executors (who carry out the more concrete tasks and often are students.) His example of a visionary was Jim Clark, who founded both Silicon Graphics and Netscape. I had a chance to meet with Jim Clark when he founded Netscape with Marc Andreessen many years ago. Because of some interesting circumstance I will not discuss here, he gave a chalk talk just for me about how he saw the Internet and why a web browser business would grow along with the Internet’s growth by analyzing other players, the telecom and communications market at that time. It was very nicely delivered, and I felt he was a real visionary.

Also, regarding his first point, Hennessy said three things are important:

A) Live on the edge of technology.

B) Find discontinuities.

C) Find the best people.

Although there are subtle differences, I think points A) and B) are very similar in that it is important to consider what could be done even better without getting bogged down by current constraints or the way things have been designed. For A), Hennessy gave as examples both Xerox Alto, which led to the creation of workstations and PCs, and Cisco, which laid the basis for Internet infrastructures. Other examples included the Internet and Yahoo. For the second example, he listed MIPS, which he founded.

Finding good people is also an important factor. At Stanford, more than half the engineering students are from outside the US. Companies like Silicon Graphics, Yahoo, Google, Sun, and VMware were cofounded by people who came from outside this country. Those good people should be given incentives for innovation and freedom to choose their direction.

In the second point of transferring innovation, the biggest point is to transfer people but not technology. This is because:

· Inventors know the technology best.

· New technologies need advocates.

We may have known this intuitively, but he stated it clearly. Come to think of it, it makes good sense. Hennessy thinks students are good ingredients for the transfer. Get good students, grow the talent pool, and teach them how to succeed in entrepreneurship.

He then touched on entrepreneurship. Entrepreneurship alone does not work. It is also important to prepare fertile soil for startups. For this you need:

· Tolerance to smart failure

· Access to capital

· Access to engineering talent

· Access to management talent

· Access to advice

· Manufacturing capability

These requirements have been discussed in many places and in many different ways, but it was good to hear them discussed in this context. He pointed out they even apply to internal transfer.

He concluded his talk by saying that:

He did not mention cleantech, but his idea could be applied to that segment.

Cloud and virtualization building blocks transformed into Valueware

Note that I’m referring to IT hardware and not what you would usually find at a TrueValue hardware store (disclosure, I like to shop there for things to innovate with and address the non IT to do project list).

Instead of value add software or what might otherwise be called an operating system (OS), or middleware, glue, hypervisor, shims or agents, I wonder who will be first to use valueware? Or who will be the first to say they were the first to articulate the value of their industry unique and revolutionary solution using valueware?

For those not familiar, converged solution stack bundles combine server, storage and networking hardware along with management software and other tools in a prepackaged solution from the same or multiple vendors. Examples include Dell VIS (not to be confused with their reference architectures or fish in Dutch), VCE or EMC vBlocks, IBM Puresystems, NetApp FlexPods and Oracle Exaboxes among others.

Why is it that the IT or ICT (for my European friends) industries are not using valueware?

Is Valueware not being used because it has not been brought to their attention yet or part of anybody’s buzzword bingo list or read about in an industry trade rag (publication) or blog (other than here) or on twitter?

Is it because the term value in some marketers opinion or view their research focus groups associate with being cheap or low-cost? If that is the case, I wonder how many of those marketing focus groups actually include active IT or ICT professionals. If those research marketing focus groups contact practicing IT or ICT pros, then there would be a lower degree of separation to the information, vs. professional focus group or survey participants who may have a larger degree of separation from practioneers.

Depending on who uses valueware first and how used, if it becomes popular or trendy, rest assured there would be bandwagon racing to the train station to jump on board the marketing innovation train.

On the other hand, using valueware could be an innovative way to help articulate soft product value (read more about hard and soft product here). For those not familiar, hard product does not simply mean hardware, it includes many technologies (including hardware, software, networks, services) that combined with best practices and other things to create a soft product (solution experience).

Whatever the reason, I am assuming that valueware is not going to be used by creative marketers so let us have some fun with it instead.

Let me rephrase that, let us leave valueware alone, instead look at the esteemed company it is in or with (some are for fun, some are for real).

• APIware (having some fun with those who see the world via APIs)
• Cloudware (not to be confused with cloud washing)
• Firmware (software tied to hardware, is it hardware or software? )
• Hardware (something software, virtualization and clouds run on)
• Innovationware (not to be confused with a data protection company called Innovation)
• Larryware (anything Uncle Larry wants it to be)

• Marketware (related to marketecture)
• Middleware (software to add value or glue other software together)
• Netware (RIP Ray Noorda)
• Peopleware (those who use or support IT and cloud services)
• Santaware (come on, tis the season right)
• Sleepware (disks and servers spin down to sleep using IPM techniques)
• Slideware (software defined marketing presentations)
• Software (something that runs on hardware)
• Solutionware (could be a variation of implementation of soft product)
• Stackware (something that can also be done with Tupperware)
• Tupperware (something that can be used for food storage)
• Valueware (valueware.us points to this page, unless somebody wants to buy or rent it )
• Vaporware (does vaporware actually exist?)

More variations can be added to the above list, for example substituting ware for wear. However, I will leave that up to your own creativity and innovation skills.

Let’s see if anybody starts to use Valueware as part of their marketware or value proposition slideware pitches, and if you do use it, let me know, be happy to give you a shout out.

Ok, nuff said.

Cheers gs

When eBay released the information on their new data center (after their Mercury project in Phoenix) in Utah in June, media jumped on it and reported intensively. In addition to the US data center market, I have covered the data center market in Japan, which is seldom reported in the US media. (I set up a session and acted as MC to discuss Japanese data centers in the recent Silicon Valley Leadership Group 5th Data Center Energy Summit. But that is another story.) This is partly because of the Japanese media and data center players in Japan only report their news in Japanese. Unfortunately, the Japanese language is not spoken outside of Japan and the foreign media is hungry for information but has no use with the news reported in Japanese. So I have been encouraging Japan Data Center Council (JDCC), a consortium of data center operators, vendors and users, to make their information available in the US.

Most of major Japanese data centers were not damaged by the earthquake in 2011 but after that, Japan’s power supply climate got cloudy as it does not have a solid plan as to what to do with the halted (except 2 of 50) nuclear reactors and hunting for new energy sources. As such, Japanese data center operators are searching for new power sources. I brought fuel cells to their attention as a potential energy source for data centers. Fuel cells that were dismissed as experimental a few years ago are now gaining some good tractions among data center operators, thanks to eBay, Google and Apple for their use at data centers. JDCC wants to find more about the appropriateness of the fuel cells for data centers. I made an arrangement for them to visit eBay to find out and to find out how my friend Jeremy Rodriguez was doing with his new role.

The following is a summary of our conversations with Jeremy and his associate Serena DeVito, and the information that is publicly available.

From left: Jun Sato (Mitsubishi), Dai Tojima (NEC), Serena DeVito, Jeremy Rodriguez and Hideki Okita (Hitachi)

eBay’s data center in Utah is the latest one after the one in Phoenix (Mercury project). There are two phases of the construction. The first phase is called Topaz and it has conventional configurations, such as power supplied by local utilities with a 30 MW substation on their premise, UPS boxes and diesel generators. Quicksilver, the second phase, which is attached to Topaz, was to be constructed with the same conventional way. But they decided to try something new. Instead of laying out rows of UPS boxes inside and generators outside, eBay decided to install Bloom Energy Servers. The next two figures indicate two configurations, conventional (UPS boxes and generators) and new (fuel cells) ones

Conventional configuration with UPS boxes (inside) and generators (outside) (courtesy of eBay)

New configuration with fuel cells (courtesy of eBay)

eBay plans to install 30 fuel cells from Bloom energy. A fuel cell unit produces electricity through a chemical reaction fueled by either natural gas or biogas. For the Quicksilver project eBay will be purchasing biogas, however because biogas isn’t available to the site they will install pipe infrastructure and consume natural gas from the utility grid.

The Bloom Energy Servers (fuel cells) are not the only greener energy option eBay is pursuing in Utah. When they originally looked at sourcing third party, off-site renewables for the Topaz data center, they found that the law in the State of Utah would not allow it. They worked with a Utah state senator to pass a bill in 2012 that changed this law, and are now in the process of accepting proposals for as much as 20 MW of additional renewable energy. Also, with the fuel cell installation, UPS boxes or generators were no longer necessary and space was released for Bloom Energy Servers that took much smaller space. Smaller footprints and less or no CO2 emissions sound pretty good.

As for the power requirements at the Utah data center, 30 200kW (total of 6MW) Bloom Energy Servers will be installed with the capability to install up to 30MW total in the future. While the power load to Quicksilver ramps up, any excess from the 6MW will be used to power the existing Topaz facility. As eBay plans to expand the data center, it probably requires more than 6MW. Because each Bloom Energy Server is 200kW in power capacity, they can add as many boxes as they need according to varying needs.

So far so good. Advantages seem to be very convincing:

• Cleaner power
• Local generation with less delivery losses
• Smaller footprints

However, I had a six million dollar question. Data center operators are very conservative and do not want to use any unproven technologies unless they have been proven to work by many practitioners for many years. The idea to source power from Bloom Energy Servers with the grid as a backup is a total reverse of the traditional design. On a casual look, this may look reckless but I think they took a calculated risk. I understand the final decision of going with this design was made by CEO. If everyone is risk averse, nothing gets improved. I have met and talked to Dean Nelson who is in charge of data center design/construction/operations at eBay and who can make a bold decision with a solid team of people under him like Jeremy and Serena. eBay, along with the likes of Apple and Google, is doing a great service to the entire data center industry to open up a new frontier. Do you recommend this solution to JDCC member companies? Come back in 18 months and ask the question. That was their answer.

After the meeting at a coffee shop, the members of JDCC and I were sharing the excitement from the meeting. Someone said that the solution is only viable where a lot of open space is available. But even in the urban setting, UPS boxes and a diesel generator occupy some space in the building. If they can be replaced with fuel cell boxes that are smaller in size, this could be a viable solution. Well, I cannot wait 18 months for eBay’s answer!

Energy mix for power: Power can be generated from multiple sources, such as coal, oil, gas, and renewable energies (wind, solar, geothermal, and hydro). In the 1970s the SVP began to diversify its energy sources to stabilize its power cost, because the cost of each source is independent and varies. This policy was established when the SVP experienced the high price of oil during the embargo in the 1970′s. So Santa Clara’s municipal utility began to have long-term, fixed-price contracts with different energy providers to achieve stable costs for power generation. The next figure denotes its current energy sources.

Energy mix for generation of power for SVP, including hydro, geothermal, coal, solar, natural gas, and wind.

Renewable energies and RPS: The diversity mentioned above contributed to the current requirement for renewable energy use for power generation. In California, by 2020, each power producer should generate 33% of its power from renewable sources. Now 20% of power is generated from renewables and that will rise to 25% in a few years. They are ahead of the pack, and they are providing power generated from renewable sources to others with a renewable energy certificate.

Data center efficiency: In SVP territory, competition drives energy efficiency. To win in the colo market, price is the most important factor. To that end, operators tend to adopt best practices in their data centers to reduce power consumption. The SVP provides rebates for power reduction and provides environmental impact guidelines, such as the LEED program for green buildings.

Impact of cap and trade: The federal version of cap and trade (CT) died in 2009 in the US. In Japan, the Tokyo Metropolitan government began in 2010 to impose its own version of cap and trade, similar to the UK’s carbon reduction commitment (CRC). At first, the Tokyo government’s power curtailment requirements did not distinguish between types of business. The Tokyo version is more strict than Japan’s national version. While not many other industries are growing, the data center industry is, and it requires more power every year. If the Tokyo cap-and-trade laws were strictly applied, a typical large data center would be required to pay $1M a year in fines. The JDCC felt threatened by this and started a dialogue with the government.

There are many servers and other equipment scattered around in corners of every building in the Tokyo area. Those are managed with yesteryear’s technologies and operational methods, wasting huge amounts of energy. If they were consolidated into data centers with proper operations, more energy could be saved. The JDCC took time (more than six months) to convince the government to apply a different rule to data centers. Even better, now the Tokyo government is promoting the use of data centers rather than a small server room in each company.

Even though the federal version of CT died, the California version of it will be enacted on January 1, 2013. The SVP needs to start preparing for it. So do data center operators in SVP territory and elsewhere in California.

Cost for infrastructure: As more data centers come to Santa Clara and demand more power, new infrastructure must be put in place or existing infrastructure expanded. Who bears the cost for such expansions? In principle, data center owners pay for the substations and other infrastructure. One reason for that is that operators tend to overestimate their needs. If the expansion is done on the basis of their inflated estimates and not fully utilized and the burden is spread among all the ratepayers, it is not fair to other ratepayers. JDCC said that the situation is similar in Japan. In Japan, data center operators must pay for a necessary substation and sometimes for any cables required for connection.

Rate: A data center consumes a lot of power, and the JDCC has a hard time negotiating a favorable purchase cost. The SVP has several levels of rate structure linked to the amount of power consumed: the more you use, the more favorable your rate. Because each situation is unique, the SVP may draw up a special service agreement that is renewed every three years (shortened from 5 years) because of rapidly changing California laws.

Power supply path regulation: In Japan, each data center is given only one power path (feed) from utilities. When a data center is constructed in phase and/or in modular fashion, that is not convenient for them. As they grow, it is favorable to have multiple feeds, but that is not allowed in Japan. If they insist, they can get two separate feeds from two different substations, but it would cost them a bundle. In SVP territory, it is usually one feed for one parcel. So if a data center set aside space (a parcel) for their data center site, they get only one feed. The entry point might be a substation placed at a data center. If the operator likes, he can have multiple feeds from the substation. If a data center operator wants two feeds coming from two distinct substations, that can be honored easily because SVP territory is small and substations are not far from each other.

Power sourcing via transmission line: In Japan (as in the US), some generation facilities are far away from the urban areas where most power is consumed. The Tokyo Electric Power Company (TEPCO), which serves Tokyo and its surrounding areas, has two nuclear power plants far from Tokyo. By the way, those two sites are completely shut down at this time. I remember a power crisis in California back in 2001. My house in PG&E territory experienced blackouts, while my office in Santa Clara did not. The SVP sources power via transmission line. Now-defunct Enron stopped many of the generators under its control and issued a lot of fake transmission-use requests to saturate the transmission line. The SVP was in the same boat but caused only one blackout. This is strictly because it sat down with its large consumers (90% of ratepayers are business/industry) to reduce their power consumption in return for an assurance that they would not be turned off. Because of this, the SVP avoided the next seven or eight blackouts that took place in other parts of California.

Blackouts: For a data center operator, blackouts are a scary thought. Data centers can operate without power supplied by the grid by using backup generators for 24 to 72 hours. But if fuel runs out, what happens? Atsushi Yamanaka of IDC Frontier shared some horror stories from right after March 11, 2011. TEPCO exercised rolling blackouts right after the disaster for a few weeks. Fortunately, there was no blackout in the Tokyo region, but surrounding areas were not so lucky. Data centers where the rolling blackouts were exercised had to run their backup generators, which are mostly gas, rather than diesel-based, turbines and last 24 to 48 hours. Most of the operators had a premium contract with fuel suppliers, but when there was big demand from other many premium account holders, it was not easy to secure enough fuel. The confusion and gridlock in traffic prevented trucks from reaching data centers quickly. On top of that, earlier rolling blackouts did not specify which areas would be affected until the day of their exercise, so it was very hard to plan.

Power provisioning time: In Japan, when a data center operator asks for power to build a new data center, utilities answer is about 24 months. Eventually, that period became 10 months, and sometimes 8 months. It has been said that data center construction time in the US is about 12 to 18 months from beginning to operation. The SVP can provision power in 6 to 9 months, quicker than other utilities.

The JDCC wanted to visit longer, but unfortunately we ran out of time. I sat with them in their meetings during their stay, and this meeting with the SVP was one of the highlights of their trip. I hope the information obtained will be useful to them when they talk with their utilities about securing enough stable power to secure their 24×7 operations. Finally, I would like to thank SVP’s people for their time and information.

In order to propose an alternative pricing structure and better working relationship with utilities, the JDCC wants to find out what other countries are doing about utilities support for data centers. I arranged a meeting with Silicon Valley Power (SVP) to find out. The SVP is not an IOU but a department of the City of Santa Clara. Municipal utilities do not exist in Japan. When I explained what the SVP is and why they would be of interest to the JDCC, I pointed out the following:

• It is a municipal utility.
• Many data centers are within the city limits.
• They accommodate data centers’ unique requirements.

The first point was interesting enough, but the last two really attracted the JDCC’s attention. There should be a reason why so many data centers (around 30) call Santa Clara home. The city is not huge, only 19 square miles. Data center density is pretty high.

Front row, from left: Wendy Stone, Kathleen Hughes, and John Roukema. Back row, from left: Hideki Okita (Hitachi), Atsushi Yamanaka (IDC Frontier), and Jun Sato (Mitsubishi).

Overview: When Silicon Valley had semiconductor factories, those produced a 24×7, flat, stable power demand. Pricing was relatively easy because demand was constant. The load factor was around 74%. Then manufacturing left the Valley, but soon the dot-com era arrived. To support that, in the 1990s data centers began to pop up. Even after the dot-com bust, the trend continued. While demand from other industries goes down, demand from data centers has been rising 2% annually. Demand was at its peak in 2006 but has declined since, thanks to the energy efficiency exercised at data centers.

Attractiveness: There are a few reasons why data centers are coming to Santa Clara. Several criteria determine data center siting, but two must-haves are power and communications networks (fiber). The market may come next, along with other things, like access to a sophisticated workforce and tax considerations. The SVP provides the lowest cost for power in California and has its own dark fiber network, and there are other local fiber providers. So without any visible recruiting efforts, data centers are coming to Santa Clara.

Fiber network laid and maintained by SVP within the city limits of Santa Clara.

Continues to part 2.

One day several years ago I had the urge to go back to Unix/Linux. By then, Red Hat no longer had a cheap solution. I had lost expertise in Linux and confidence in my systems administration skill. I needed an easy Linux solution, which I knew was an oxymoron. I researched a lot about Linux, and tried a few of the many versions of it, and found that confusing. On the basis of reputation, testimonials from others, and my trials, I picked Ubuntu. Hard-to-understand and difficult-to-deal-with were important when I was a techie. But spending several years as a manager changed my attitude towards computing a lot. Computing should support me, but I should not support it. I selected Ubuntu, and my current version is 12.04 LTS (long-term support) version.

When I signed up as press for the recent ARM TechCon, I got a lot of emails from PR people of various companies for interview opportunities. When you have limited time, you review each company’s news closely and decide which companies to talk to. It is hard to choose whom to interview with the sketchy information given. Sometimes the selection is easy, when you see a major company wants to talk to you.Among several offers, there was one from Canonical, which is the firm supporting the Ubuntu operating system for desktop, server, and commercial uses. I took the opportunity without hesitation.

At ARM TechCon, Canonical issued a press release, Canonical joins Linaro Enterprise Group (LEG) and commits Ubuntu Hyperscale Availability for ARM V8 in 2013. I sat down with Michael Kress, VP of Sales at Canonical, and talked with him about it.

Michael Kress

Michael flew in the night before, after waiting at Logan airport for four hours. He was flying from Boston, which was impacted by our friend Sandy the superstorm. He has been with Canonical for close to five years and has worked in several areas, including the ecosystem of ARM for Canonical. I did not know much about Linaro. According to Michael, Linaro was started about two years ago with four to five companies. I was led to believe that Linaro is for embedded Linux, but Michael corrected me. The embedded Linux world is quite different from that of non-embedded one, and it is not easy to enter it without the right background.

Linaro‘s activity is summarized from their website:

Linaro is the place where engineers from the world’s leading technology companies define the future of Linux on ARM. The companyis a not-for-profit engineering organization with over 120 engineers working on consolidating and optimizing open source software for the ARM architecture, including the GCC toolchain, the Linux kernel, ARM power management, graphics and multimedia interfaces.

To ensure commercial quality software, Linaro’s work includes comprehensive test and validation on member hardware platforms. The full scope of Linaro’s engineering work is open to all online. Open engineering has been practiced from the start at Linaro with plans, specifications and progress available for inspection on the developer Wiki. Linaro is distribution neutral: it wants to provide the best software foundations to everyone, and to reduce non-differentiating and costly low level fragmentation.

Linaro Enterprise Group (LEG) is a new working group at Linaro that includes companies like AMD, AppliedMicro, Calxeda, Canonical, Cavium, Facebook, HP, Marvell, and Red Hat, in additon to the original Linaro members, like ARM, HiSilicon, Samsung, and ST-Ericsson. Linaro released information here about it.

Canonical/Ubuntu is embracing ARM. Because my areas of coverage have grown so wide, I was blind-sided about Ubuntu’s new territory. But when you see the growing market into SNS, it is no wonder that Ubuntu is entering the ARM world. In the SNS world, what is required is scale-out but not scale-up. Computing tends to be distributed, and not every task requires heavy computing. For that, a server based on ARM is a good fit. Canonical/Ubuntu was hinting at this in one of the blogs by Victor Palau back in August. In the blog, there was a link to his presentation to summarize why. I thought it very useful. In the presentation, Victor showed some interesting numbers, such as:

• 98% of 1 billion mobile phones sold each year use at least one ARM processor.
• A rack designed for 40 traditional servers could house 3,000 ARM servers.
• HP estimates ARM servers will require 94% less space.

There was more stuff in the presentation, but let me defer it to a future blog.

Canonical started with ARM in 2008. In the actual working with Linaro, Canonical assigned a few engineers dedicated to Linaro to work with other engineers from other companies to solve tough engineering problems, such as the interoperability of various technologies and boot-process differences among system-on-a-chip (SOC) vendors. There are several packages of Ubuntu tailored to each platform, and each version is natively compiled. For an outsider like me, it would be very interesting to compare benchmarks between their X86 version and the ARM version, but for an obvious reason they keep such benchmarks internal. The next question is whether an ARM-based server is ready for prime time. Michael thinks the 32-bit ARM solution is ready for specific application areas like Web and Big Data, which require scale-out features. Canonical can expand into many areas, such as cloud computing, but it does not work in the embedded market. In the embedded market, an OS is sometimes not a visible component.

From the green IT perspective, this is interesting. It is welcome news to know that both Ubuntu and Red Hat are embracing low-power servers based on ARM chips. If a low-power server running ARM replaces one with X86, power consumption goes down tremendously. But if you pack more servers into the same or less space, what happens to power consumption and heat emission? Take a rack of servers. With ARM servers, the density would be 75 times (according to Victor above) greater than the traditional way. Compacting the servers would minimize space, and that would reduce energy consumption for sure. That is welcome news. On the other hand, if you increase density and pack more into a given space, power consumption and heat emission may increase. For that, alternative cooling technologies and operational methods may be required. I have not seen any research on the tradeoffs anywhere yet. At this time, examples of ARM servers in many data centers are hard to find, and I defer my comment on this to a later time.

I sat down with some IAR folks to find out more about their power debugging. When I interview a company, it is usually one or two people who come to see me. This time it was a bargain. I got four of them who cover CEO, marketing, technology to international market functions as a group. Because of this, I got a pretty good insight into the company and its products.

From left: Kiyofumi Kamimura, Thomas Sporrong (standing), Fredrik Medin, and Stefan Skarin.

Company

IAR is headquartered in Uppsala, Sweden. This city sounds familiar because MySQL was headquartered there before its move to the US. Kiyofumi is a country manager for Japan. We could have used Swedish, English, or Japanese, but because my Swedish is rusty, they were nice enough to agree to conduct an interview in English.

IAR has been around for 30 years, so we cannot call it a startup anymore, for sure. The total number of employees is around 160 and 70 of them are developers. Turnover is extremely low. Over the years, only three people have left the engineering development team. Most of the developers are gray haired after many years of experience with the company. Some have been with the company for thirty, twenty, or fifteen years. They are still doing basically the same job. It is quite a contrast to Silicon Valley. Large Japanese companies are known to have very low turnover, although that is rapidly changing. Even though people may not leave their company, they move around within the company in Japan. If you are a programmer and with your company for decades, you tend to be promoted to manager and no longer touch programming.

This is one of the strong points of IAR. Their clients are happy because the same guy works on their project for many years and it is easy to communicate with the programmers. Also, internally useful know-how and knowledge of how to produce efficient and high-quality code accumulate over the years. That is a great asset for them. They focus on delivering products but not services. Thus, this vast amount of software development knowledge is kept inside the company.

Power Debugging

From the green IT point of view, measuring hardware energy consumption and comparing its energy efficiency with that of other hardware are fairly straightforward. We could measure power consumption and compare multiple hardware platforms based on the measurement. What we do is to put a probe into a circuit board and measure signals and power. But when it comes to software, it gets more complex and difficult. Given a specification, there are many more ways to implement a solution with software than with hardware platforms. Even using the same algorithm, we could still fine-tune it and adjust data structures. For software performance, we have used something like profiling. I was a software programmer once and used it myself. By now my programming skill is so rusty that I do not want to mention that I earned my living by writing programs in the past.

The difficulty of software is code itself. Code is a static entity, and it is very hard to predict software behavior in action. That is why profiling is very effective. We can gain dynamic behavioral information, such as how many times a particular section is exercised in a run. With that information, we could modify and improve software to run more efficiently. Although that is very useful information, it is still logical information. Profiling is mainly used to speed up software but not necessarily to reduce power consumption. If we are on a platform that has plenty of computing power, memory, and storage, then speed is very important. But in a resource-constrained, embedded world, sometimes power consumption reduction may be more important than speed.

What if we can get more precise information about what each section or statement of software consumes in terms of electrical power? That would be very helpful for programmers in fine-tuning their software, and it is what power debugging is all about. As shown in the picture below, as in a typical debugger you can see the program execution at the source code level along with the assembly code equivalent and power consumption information at the statement level. By observing how power consumption changes as the execution proceeds and how much power each statement consumes, the programmer can modify the code to reduce power consumption. Of course, that information alone would not show how to change the code. As you know, a software modification tends not to be localized except in very simple cases. One change may have multiple impacts within the same function but sometimes also in other functions. That is up to the programmer.

The overall system power consumption is shown as a graph in the Timeline Window. Double-clicking on any part of that graph will take you to the corresponding location in C source and disassembly views above.

The setup seems to be fairly straightforward and easy. What you need is a circuit board, power debugger probe (I-jet), and GUI software on a PC, as in the picture below. I-jet has an interface to a circuit board and provides power to the board via a host computer, the PC. I-jet is connected to the PC via USB. By the way, IAR’s product works with C and C++ code, which is dominant in the embedded world.

GUI on a PC connected to a circuit board via I-jet (yellow box).

In addition to tuning software performance, a power debugger like this can be used to fine-tune a circuit board. If we find higher power consumption than expected, we may want to lower clock speed or reduce the RAM size, sacrificing speed. On the other hand, if we find that the program does not require as much memory as installed, we could replace it with less memory.

Future

This is very interesting. What will they do next? They told me that the current version allows putting a probe into the entire circuit board. The future version should allow measuring only a particular micro-controller rather than the whole board.

Speaking of the future, I asked them about the applicability of their solution to the server environment in a data center. Most attention has been given to the facilities and hardware side of IT for energy efficiency. Even power usage effectiveness (PUE), the most used data center metric for energy efficiency, only considers the total power consumption of the data center as a whole and IT as a whole. People are starting to shift their focus to software for energy efficiency. It is far more difficult to deal with software because it is more complex than hardware.

They are currently focusing on embedded systems and pointed out a couple of things to me. One is that in the embedded world, each software is pretty unique and developers probably need to write 90% of the code, with the rest coming from libraries and such. So power debugging makes sense. In contrast, in the enterprise environment, programming is minimal and the rest is done by integrating existing code. Because of that, its relevance in the enterprise environment may be minimal. That may be true, but we can use power debugging to pick the most energy efficient libraries and utilities/middleware when we have the freedom to choose. The other point is that ARM is entering the server world, in addition to the embedded world. For example, AMD, HP, and others are planning ARM-based data centers. AMD acquired SeaMicro, an ARM-based server vendor, earlier this year. HP and Calxeda are working on an ARM-based server named MoonShot.

If ARM-based chips become prevalent in the data center environment, many software packages will have to be rewritten to run on the new ARM platform. If that happens, IAR’s power debugging idea can be used.