Docker and Juicing the Google
June 10, 2014
The revolution is here…almost. Navigate to “Google Embraces Docker, the Next Big Thing in Cloud Computing” or “Docker Launches A 1.0 Product And Gains An Opportunity To Monetize.” Forbes cheerleads for the automation crowd. Wired pumps up Google’s enthusiasm for the open source technology.
Automation is a magical way to reduce costs as long as the pesky humans do not have to code widgets, connectors, and shims. If these software gadgets are not ready for prime time, some of the automation benefits will be more Silicon Valley mumbo jumbo.
For the GOOG, a bit of a computational crisis exists. Google surfed on innovations that other companies were slow to adopt in the 1996 to 2000 time frame. Despite spending bundles on optimization, the GOOG, like other computationally constrained outfits, needs to find shortcuts.
Enter Docker. The technology is one of those “if only” innovations. Here’s what I mean. “If only everyone adopted Docker and if only developers would create the software gadgets to make snap in operation a reality.” Also, “If only the Amazon approach were not so darned popular.”
You get the idea.
Docker is characterized by Wired as something Google has been doing for a long time. Er, okay. Forbes sees Docker as another open source commercialization play with services being the donkey delivering the gold and silver to the stakeholders.
My view is that like many open source plays, the technology is pretty good. Making the technology deliver on the promises “real” journalists report is a different kettle of fish (actually, software gizmos to hook A to B without more coding and tweaking.
The real problem is that existing computer systems are pretty snappy and much easier to use in a timesharing environment than IBM and other mainframe iron from the 1970s. But—and this is a significant concern to me—we are really getting hyperbole for optimization.
What’s needed is a computational platform that makes more sophisticated operations practical. Instead of known methods running faster or deploying with less craziness, we are making the 1985 Corvette perform via add ons.
Short cuts are not breakthroughs that leapfrog the decades old methods. Going faster and cheaper is fun. Better is not part of the calculus of optimization.
Stephen E Arnold, June 10, 2014