Biologically-inspired technologies have been a research topic for years, autonomic computing and epidemic protocols being a couple of examples. These techniques often have very attractive properties to go with their fun names: scaling, self-healing, resilience, blah, blah, blah. I think about infrastructure and have taken some different things from biology.
The unfortunately named Universal Genetic Code (UGC) and the other, extremely similar variants found in mitochondrial DNA and other small organisms, evolved. We're used to DNA being the stuff of evolution (RNA fans save your flame mails), so the code itself evolving is a bit of a brain bender. Think of it as meta-evolution.
The end of evolution for the UGC happened billions of years ago. Experts call this "early fixation.". The code itself is a marvel of efficiency. It resists exactly the sort of errors to which the transcription machinery is prone. When a transcription error gets through, chances are the erroneous amino acid will have properties similar enough to the correct one that there is little functional difference in the geometry of the final protein. We can appreciate just how spectacular it is because we can almost completely quantify its environment, something simply out of the question with complete organisms. Physics, chemistry, geometry.
The high school biology textbook version of how genes evolve goes something like this: mutation and crossover. Mostly crossover. Read chapters 5 through 7 for Monday.
Reality, as expected, is far richer. Enter Systems Biology and Evolutionary Developmental Biology (evodevo). I can't do justice to the topics in a blog post, but the important idea is this: genes change very slowly, while the gene regulation networks that control their expression are incredibly complex and evolve rapidly.
The bottom of the stack is ridiculously efficient, defined almost entirely by physical constraints, and completely static. Up a level we see simple, modular structures that can be assembled in a variety of ways, and that change very slowly. Finally, at the top, we see the incredible complexity and the roiling expression of evolutionary change.
UGC -> genes -> regulation networks
hardware infrastructure -> software infrastructure -> applications
Enter the 36 chambers of infrastructure wu-tang
Saturday, June 23, 2007
Sunday, June 03, 2007
A bit more about demand locality
In my last post I focused on geography and culture/language as critical factors for demand locality. However, there are many other ways that demand locality manifests. One of the more subtle is organizational demand locality.
Organizational demand locality is the relative efficiency of carrying traffic entirely within the infrastructure of a single organization versus having to hand-off traffic to other organizations. Wireless carriers offering unlimited "on-net" airtime are exploiting organizational demand locality. Internet service providers spend a surprising amount of resources worrying about peering with each other (or refusing to).
Once again, the geographic/cultural demand locality plays a key role. In places with very high demand locality (Korea, Japan, etc.), the need for numerous, large links between organizations is minimized or avoided entirely. In places with low demand locality (again, I mean the US), peering becomes a constant source of friction with tier-1 ISPs requiring peering at multiple points across the country or not at all. Merging ISPs to raise organizational demand locality only gets you so far.
The applications have to change, not the infrastructure.
Organizational demand locality is the relative efficiency of carrying traffic entirely within the infrastructure of a single organization versus having to hand-off traffic to other organizations. Wireless carriers offering unlimited "on-net" airtime are exploiting organizational demand locality. Internet service providers spend a surprising amount of resources worrying about peering with each other (or refusing to).
Once again, the geographic/cultural demand locality plays a key role. In places with very high demand locality (Korea, Japan, etc.), the need for numerous, large links between organizations is minimized or avoided entirely. In places with low demand locality (again, I mean the US), peering becomes a constant source of friction with tier-1 ISPs requiring peering at multiple points across the country or not at all. Merging ISPs to raise organizational demand locality only gets you so far.
The applications have to change, not the infrastructure.
Subscribe to:
Posts (Atom)