Why Internet & Infrastructure Need to be Fields of Study
The Internet is infrastructure. This should be plain, but it's not. The reason is that neither the Net nor infrastructure are well-understood, even though both could hardly be more widely used.
Ask any ten people what the Internet is, and you'll get ten different answers. Or heck, ask Google. Here are the nouns or noun phrases that come up in the first two pages of a Google search for "The Internet is" (on 18 December 2008):
- "for porn" (Evilhoof and Flayed - www.worldofwarcraft.ru/, via Google Video)
- "a global system of interconnected computer networks" (Wikipedia)
- "a series of tubes" (Sen. Ted Stevens, via Wikipedia)
- "shit" (internetisshit.org)
- "fairly simple" (CenterSpan Internet Tutorial)
- "an agreement" (Doc Searls and David Weinberger, in World of Ends)*
- "almost full" (Seth Godin)
- "good" (Joseph Reagle, in Why the Internet is Good)*
- "better than sex" (Stacey Higginbotham in Gigaom)
- "closing to innovation" (Jonathan Zittrain in Newsweek)*
- "making us stupid?" (Guy Billout in The Atlantic)
- "dead and boring" (Mark Cuban)
- "terrible" (Raisins)
- "no 21st-century boob tube" (Eleanor Mills)
- "the greatest generation gap since rock and roll" (Paul Boutin in Valleywag)
- "magic" (CollegeHumor)
- "missing" (Bob Frankston)
- "changing the scientific method" (Alexis Madrigal in Wired)
- "no substitute for a library" (American Libraries Online)
- "for everyone" (Vint Cerf, then of the Internet Society)
- "the first amendment" (Jeff Jarvis)
Ask ten people (or Google) what infrastructure is, and you'll get a more coherent response, all in the form of examples: "roads and bridges", "the electric grid", "reservoirs and water treatment", "hvac" "backbone pipes and routers", "stuff we depend on". You won't get a definition. That's because infrastructure one of those things lots of us talk about but few of us study as a subject of its own. It is a subject of many fields rather than a field of its own.
Evidence of this depthless diffusion can be fond in our best libraries. Harvard's vast HOLLIS Catalog, which spans most of the university's 15.8 million volumes, contains thousands of journal articles with titles that include the word "infrastructure", but just twenty books, none published before 1976. "Infrastructure" appears in no titles among the seven hundred thousand volumes in the Boston Athenaeum — a library packed with books on architecture, public works and other subjects we would characterize as infrastructural.
You'll do better with Amazon, which brings up twelve results in a search for infrastructure among titles.
And here's a revealing irony: Wikipedia's entry on infrastructure runs past 900 words, yet Encyclopedia Britannica has no entry for the topic at all.
Dictionaries do better. The Oxford English Dictionary dates "infrastructure" from 1875, and notes scattered usage from 1925 onward. Merriam-Webster Online dates "infrastructure" from 1927, and offers these definitions:
1: the underlying foundation or basic framework (as of a system or organization)
2: the permanent installations required for military purposes
3: the system of public works of a country, state, or region ; also : the resources (as personnel, buildings, or equipment) required for an activity
The American Heritage Dictionary adds this usage note: "The term infrastructure has been used since 1927 to refer collectively to the roads, bridges, rail lines, and similar public works that are required for an industrial economy, or a portion of it, to function. The term also has had specific application to the permanent military installations necessary for the defense of a country. Perhaps because of the word's technical sound, people now use infrastructure to refer to any substructure or underlying system. Big corporations are said to have their own financial infrastructure of smaller businesses, for example, and political organizations to have their infrastructure of groups, committees, and admirers."
Stephen Lewis follows this trail in The Etymology of Infrastructure and the Infrastructure of the Internet: "Infrastructure entered the English language as a loan word from French, in which it had been a railroad engineering term... After World War II, 'infrastructure' reemerged as in-house jargon within NATO, this time referring to fixed installations necessary for the operations of armed forces and to capital investments considered necessary to secure the security of Europe." From there, the word "spilled into the contexts of urban management and regional and national development, and into the private sector — but with some boundaries." For example, in the early 1970s, infrastructure "was used to refer to those massive capital investments (water, subways, roads, bridges, tunnels, schools, hospitals, etc.) necessary to city's economy and the lives of its inhabitants and businesses enterprises but too massive and too critical to be conceived, implemented, and run at a profit or to be trusted to the private sector."
From Lewis' own work in Europe and Asia in in the 1970s and early 1980s, he recalls that "in the world of oil refining, petrochemicals, and 'process' plants, 'infrastructure' referred to those social or governmental capital investments — roads, sewerage, water sources, electrical power, and other 'utilities' — that were necessary for manufacturing but the provision of which did not fall within the scope of a single project, the 'battery limits' of an industrial facility, or the commercial 'feedstocks' that were are the raw materials for industrial processes." In other words, infrastructure in that decade still referred primarily to the public foundations on which private enterprise could build.
Then usage exploded. In the "Infrastructure and Development" chapter of Annual World Bank Conference on Development Economics 2005: Lessons of Experience, Remy Prud'homme notes "the formidable success of the word in the 1980s and 1990s, when it invaded United Nations institutions, World Bank organizational charts, academic journals, and daily newspapers. The process has clearly been inflationary. The meaning of the word has been extended so much that it no longer means much."
To restore meaning, Prud'homme isolates a set of specific attributes, chief among which is the role of infrastructure as "capital goods" that support services. Here is a table he provides to illustrate the point:
|Roads, bridges, tunnels, rail tracks, harbors, etc.||Transportation|
|Dams, reservoirs, pipes, treatment plants, etc.||Water supply|
|Dumps, incinerators, compost units||Garbage disposal|
|District heating||Plant, network|
|Telephone exchanges, telephone lines, etc.||Telecommunicaiton|
|Power plants, transmission and distribution lines||Power|
Let's go back to the Internet. Does the Internet fit in there? It may use telephone lines, but it doesn't need to. In fact, neither does old-fashioned telephony. Thanks to digital technology, voice and video today are just forms of data. And, thanks to the Internet's protocols, that data can be carried over anything: wires, wireless, fiber optic cabling, whatever. The Internet may be a "network of networks," but that description has a physical connotation. In fact the Internet is defined mostly by its suite of protocols, which are agreements about how data moves from point to point. The Net's protocols transcend the physical networks on which data is routed, because the core purpose of those protocols is to find the best available path between end points — not, say, to create scarcities in the form of minutes, bandwidth, packet volume or any other measure that might be used if the Net were strictly a commercial service.
As with free software, Linux and most open source development projects, there are no commercial purposes embodied in any of the Net's protocols, even though the Net supports an incalculable sum of commercial activity. Telephony and television are just two two among countless other uses to which the Net can be put.
Yet the companies that own much of the "last mile" and "backbone" cabling sell "Internet" as a "service" alongside telephony and television. Many (even in Europe, where the baseball reference is lost) call this "triple play." Here is how that would look in a table modeled on Prud'homme's:
|Internet||Web access and services, email, instant messaging, and an unlimited variety of current and future uses, including voice and video.||Telephony, television, Internet ("triple play")|
The irony here is that something called a "service" by its carriers is also a kind of infrastructure — not just for providing traditional services such as telephony and television, but for approximately everything digital that needs to be done across distances.
In last May's Linux Journal, Bob Frankston (co-inventor of spreadsheet software) put this in perspective:
The importance of the Internet lies in the dynamic process by which a very simple design decision made in the 1970s has become the defining infrastructure for the world. It's what happens when you give billions of people the opportunity to create their own solutions and share them. The infrastructure of telecom is not the infrastructure of networking. We must not confuse the two. The infrastructure of telecom is about billing for scarcity. The infrastructure of networking is DIY and connecting anything to anything.
Connectivity, Bob says,
... is about relationships, while communications is what we do with those relationships. The power of today's Internet comes from letting us focus on the relations and our ability to communicate rather than the twisting passages through telecom's maze of copper, fiber and radios.
The networks in our homes are a good example. You "just" print without worry about negotiating for the printing provider.
... but we need to be careful since the network emerges out of our networking. Copper and radios are just a means we use. It's like the difference between driving and buying a ride from a railroad. We should have infrastructure rather than a choice of whose services we must purchase. DIY must be an option!
Connectivity-as-infrastructure is soft in several senses. One is that you don't need a big utility company to provide it. Another is that data and its protocols are soft. They have no physical substance, yet they have supportive qualities that are substantive in the extreme. That's because the Net is a way of connecting. It is not the wires and waves that do the connecting.
It's this uncoupling of ways (of connecting) from means (of "carrying") that makes the Net so suitable to DIY. We saw this on the personal scale with the first Internet Service Providers (ISPs), which were not phone and cable companies, but rather independent operators that found ways of finding paths around and phone companies' technical and billing systems.
DIY for the Net happens at every scale, from mobile phones, PCs and laptops to enterprise IT systems and "cloud" services. Those range from personal clouds using eyeOS (a new open source project out of Barcelona) up to massive pure-utility compute and storage services such as Amazon's EC2 and S3.
Yet the DIY nature of the Net gets limited respect from those provisioning it as a "service" alongside telephony and television.
Such is the case with Internet service. Today most of us are provisioned Internet service by carriers — telephone and cable television companies whose businesses were host to what Lewis calls the "ad hoc" deployment of the Net's protocols, which used carriers' private infrastructure as if it were far more public than it was. Thus the Internet spread both in spite as well as because of those businesses. The Net is unique as infrastructure because it is inherently self-provisioned, taking advantage of any available physical or wireless path, without regard for the sunk or future purpose-built capital expenses laid out by its carriers.
David Isenberg calls the Net "stupid" because its only job is connecting human and machine intelligence at its end points. Isenberg's thesis rests on the end-to-end principle embodied in the Net's Transmission Control Protocol (TCP).
Craig Burton combines "stupid" with end-to-end through the metaphor of a hollow sphere built entirely of ends, all facing each other across a the three-dimensional zero between them: "The distance between any two points is functionally zero, and not just because they can see each other, but because nothing interferes with operation between any two points." The result, Kevin Barron says, is a "giant brain" comprised of the collected intelligence of every connected individual, document and back-end service. In The Big Switch, Nicholas Carr says Amazon's and Google's back-end Web services are themselves utilities: "Cheap, utility-supplied computing will ultimately change society as profoundly as cheap electricity did."
This won't change all societies at once, and not everywhere in the world. Deployment of the infrastructure required before the Net becomes a true "giant zero", or makes Big Switch benefits available to everybody, is bound to be what Prud'homme calls "lumpy". It doesn't happen evenly. Or at all, unless the investment is justified. Even if we subtract out the antique business models and billing practices of carriers kept alive by persistent telephony and television demand, and make carriage of the Net's packets as "stupid" as possible, the capital outlays required are enormous, especially as demand to connect and share data grows at an exponential pace. Whether the Net is provisioned as a grace of private enterprise or public largesse, the capital outlays must be justified and rationalized. This is hard to do when the Net itself remains ad hoc at its core, and when innovation is highly permitted at the ends while it remains highly regulated inside the "zero." All due respect to the need for keeping the Net "stupid," but should carriers be forced to move their own innovation imperatives off the table? That's what they hear in demands for "net neutrality" legislation. Can we reconcile the Net's end-to-end values with the need for its carriers to innovate, and to maximize their capacity to pay off capital investments on behalf of the Net?
The Internet is physically a machine, a technology, and a device. Like all such things, we can expect it to change over time, to be improved, to evolve, and to change. So there’s very little value in romanticizing this machine as it was - or is thought to have been - in some early incarnation.
Technology drives social change, and social needs drive technology. Our framing of the Internet should never become so romantic that we lose the ability to assess good and bad practices, or that we try to draw lines between them too dogmatically.
Everybody has an interest in allowing the Internet to develop, and it’s simply the height of folly to assume it’s somehow reached the endpoint of perfection in any one of its modules at any particular time.
It's still early. The Net we know has only been available to most of us since 1995 or so. In a 1999 interview Craig Burton said something that still rings true:
There's a word I like for what's going on here: terraform. It's the verb for creating a world. That's what we're making here: a new world. Now the question is, what are we going to do to cause planetary existence? How can we terraform this new world in a way that works for the world and not just ourselves?
Nine years later we are still under-equipped to meet this challenge, simply because both the Net and infrastructure remain poorly understood and defined even as both are widely discussed and relied upon.
The need for this understanding could not be higher. Data accumulation at the Net's ends is rising exponentially while the ability to share it across the Net's many paths inches up incrementally, and unevenly. The world economy meanwhile is in the crapper, meaning that capital for expanding the Net's supportive capacity — its physical infrastructure — may decrease or go away for awhile. (I made a bold suggestion a couple months back, but it went nowhere.)
Billions or trillions of dollars in productivity, plus the expansion of other civilized graces, are staked on better understanding of infrastructure, and how its meaning is changed by the Net — which we also don't understand well enough. Increasing understanding requires fresh and determined scholarship inside the academy and outside the immediate interests of any one interest group. Ten years from now there should be dozens, or hundreds, of books in the HOLLIS catalog, each providing guidance to both the public and private sectors, as they make policy, write (or rescind) laws, and develop businesses that support and expand the good done by the Net for the world.
* Nice to see so many results among the top ten tracing to Harvard's Berkman Center for Internet & Society. Jonathan Zittrain is a founder of the center. David Weinberger and I are both fellows there. And Joseph Reagle wrote his piece (#8, above) while at Berkman as well.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide