“When we started releasing data publicly, we measured it in petabytes of traffic,” said Doug Webster, a Cisco Systems market executive who is responsible for an annual report by the firm that charts changes in the Internet. “Then a couple of years ago we had to start measuring them in zettabytes, and now we’re measuring them in what we call yottabytes.” One petabyte is equivalent to one million gigabytes. A zettabyte is a million petabytes. And a yottabyte is a thousand zettabytes. The company estimates that video will account for 90 percent of all Internet traffic by 2013. (cite)

(via Trevor Loy)

If anything, Wind River’s inability to breakout, despite a once Microsoft-like position of dominance, is a by-product of their failure to meaningfully go “up the stack” and away from their historical focus on the silicon layer as a primary differentiation point.

In other words, if Wind River had enabled the next generation of Cisco and Apple killers by providing more differentiated OEM-in-a-Box offerings, ala what Google is now trying to do with Android, they would not be staring at a $900M market cap and relatively flat revenues, margins and stock price.

Well, that’s an argument. Embedded is a tough beat, but Wind did not exactly set the world on fire developing new concepts and software. Intel’s history in software is not glorious either – so it’s going to be an interesting challenge for the new entity.

Although the payoff of a small niche may be less than that of a large, growing market, the competion may often also be less intense. The majority-fallacy concept states that appraisals of fast growing  segments overlook of minimize the likelihood that many competitors will be attracted. This explains why growth areas often stimulate destructive overcapacity and why a more modest product-market scope may be a preferable choice.

From Aaker, Strategic Market Management.

It is becoming more common for fire ants to build nests in pad mounted equipment. Their nesting materials can cause short circuits, the ants can eat away at conductor insulation, and they make equipment maintenance a challenge.

from Power System Reliability, by Richard Brown, in the Electric Power Engineering Handbook

The subdued poetry of engineering documents “and they make equipment maintenance a challenge“.

“What appears to be a defense contractor in Bethesda, Md., had a file-sharing program on one of their systems that also contained highly sensitive blueprints for Marine One,” Boback said.

Tiversa also found sensitive financial information about the cost of the helicopter on that same computer, WPXI-TV reported.

[0018]For incoming network packets, the following is done during the logging mode. When a packet is received, an event-request is posted for the VMM, at Block 210. When the VMM processes the event, it stops the VM, synchronizes the guest VCPU state, and then calls into the device emulator (i.e., device emulation software event handler), at Block 220. The device emulator logs an event at Block 230. Then, the device emulator receives the packets, and logs their contents, at Block 240. The last packet logged is marked so that during replay the device emulator can know when the last packet for this event occurs in the log.

[0019]During replay the following occurs: When an I/O event is encountered in the log, the device emulator (i.e., device emulation software event handler) is called by the VMM. The device emulator reads all packets that were logged, and copies them into the memory of the VM. In this way, the receive queue of packets is updated at the exact same point in the instruction execution sequence during logging and replay.

VMWARE application.

Birnbaum believes that one of the key foundational elements of a stateless computing environment is a networked storage system that enables ubiquitous availability of software. The file paths of the individual applications should be based on clearly defined nomenclature, much like the domain of a web site. All application dependencies should be accessible through the network filesystem, and version numbers should be expressed with the path nomenclature.

Big distributed file system – sure. Why should version numbers be expressed with the path nomenclature (a Plan9 idea, btw)?  Now we go on to the ancient problem of caching distributed data.

The obvious challenge posed by rolling out worldwide network storage infrastructure is scalability. If everyone in a global organization is depending on a network storage solution, then it needs to be fast and consistently reliable. The solution that Birnbaum proposes is regional mirroring and caching. The storage system would be universally synchronized between mirrors that have all the data. Caching can also be used at individual facilities to further improve performance. To achieve this kind of global scalability, he says, the best approach is similar to that of Akamai.

So even with a non-globally distributed file system, the problem of shared access is non-trivial. A global file system makes things quite challenging. Suppose we have a file recording trades and the Singapore, London, NY, and Espanola main offices all are reading and writing at the same time. Caching and cache coherency is an utter nightmare.  Akamai, like Google, solves the problem of massive amounts of distributed data by focusing on “delivery” – otherwise known as “read only content” or “many readers one writer” and with no requirement for true synchronization.  But the ML problem is more difficult even if we ignore multiple writers because, presumably, you want Singapore to actually see every trade made in Espanola even though for Akamai, it’s ok if the cache is not fresh. How to solve multiple readers and writers is something else as well.

These concepts don’t cover a whole lot of new ground yet. Much of this was already possible with conventional thin-client systems. The point at which it becomes immensely valuable, according to Birnbaum, is when all of these technologies are used together with virtualization to abstract the processes away from the hardware. Once this is done, individual operations can seamlessly float around data centers and balance out in a manner that offers a more optimal level of resource utilization.

And this seems to me to gloss over the even harder problem. Imagine a serious Oracle application “seamlessly floating” from some set of machines in one data-center to another set.  I can’t imagine how that works. Imagining little jobs floating is easier, but is that really an interesting problem? And this brings us to the most interesting claim:

He claims that 61 percent of a company’s enterprise server capacity goes completely unused and proposes an automated load balancing solution—

SIXTY ONE PERCENT!  Think of the power use.

Discussing Sun’s efforts to build super dense systems, Gilder writes:

And with 1-terabyte drives, available next year, Bechtolsheim will be able to pack the Net into three cabinets, consuming 200 kilowatts and occupying perhaps a tenth of a row at Ask.com. Replicating Google’s 200 petabytes of hard drive capacity would take less than one data center row and consume less than 10 megawatts, about the typical annual usage of a US household.

(To me, the 10 megawatt/hours as the average consumption of a US household is an incredible number, but it turns out to be true. Also there is the, only an supply side economist would do this silly comparison to annual household use – really it’s more like 9000 times the annual use of a household.) The obvious flaw in the logic is the assumption that the size of the contents of the online network will remain about the same as storage costs drop – and Google is working hard to put more and more “stuff” online.

Nonetheless, one key question is the balance between centralized storage/compute centers and the edge and relative power efficiencies will make a big difference. If the dominant paradigm of computing becomes one of connecting your lightweight mobile device to a network and invoking operations somewhere in the cloud, the industry landscape will look very different from what it looks like today and computing will much more look like todays electrical system. Perhaps we will even see an ironic situation where computing becomes a centralized utility just when electrical power decentralizes or perhaps the decentralization of electric power generation will force decentralization of computing.

Locality has always been key to performance. But there are all kinds of locality. The data center cloud makes sense if high speed local networks are so much faster than the internet that it makes sense to centralize data centers, but the internet is fast enough that it makes sense to use remote data centers. That may be a durable balance or it may not.