NetApp - The Missing Shade of Blue

I'm Sending Chuck a Bluey

My youngest daughter is going out with a professional soldier. That's tough for her; soldiers in the UK Armed Forces are often on active duty, and he's served several long tours of duty in Afghanistan already, something that she finds difficult to handle emotionally when he's way.

During his last tour, she wanted to send him a bluey. It's the Services equivalent of a telegram; you write your bluey online, it gets sent and printed locally, and most if not all blueys are delivered in 24 hours, even to servicemen right on the front line. It's good for morale, and the service is excellent.

Her first look at the website resulted in tears. When she looked at the information to get the letter to him, she discovered that all she knew was his name, his rank, and that he was in Afghanistan. No other information, and although she thought she knew his regiment, she wasn't sure.

Dad to the rescue. The boyfriend's name is unusual. Very unusual indeed, with a first name from Greek antiquity, and a surname that appears four times in the local telephone directory -- and they're all family members. This guy has a name you'd never forget; a name, like Roman Rock (not his real name, because he's still on active service). If there's another person in the UK with the same name, far less in the Army, I'll eat my shorts. So I calmed her down, and helped here address her bluey, to Roman Rock. That was all the information we could fill in.

It got to him in less than 12 hours. We didn't know where he was located, but the Army did, because he had a unique name.

Chuck Hollis had an interesting blog on filling out blueys. Well, sort of; on what he sees as the death of the filesystem. The topic struck me as interesting; The Future Doesn't Have A File System.  As usual, but with good reason, I disagree.

Object-based information stores are different than filesystems in several important ways. 

First, you use a token or other uniform identifier to get your information.  File systems imply location, tokens don't -- no such thing as a broken link or a moved file system.  Not to mention, tokens can uniquely identify gazillions of information objects.

Disagree; filenames don't imply location. They're just names; metadata that allows you to uniquely identify the data you wish to access. This is a problem that the internet created, and that the internet solved; see later.  

Second, they have the ability to associate all sorts of metadata with the object itself.  As the information object goes, its metadata travels with it.  A very useful property indeed.

And that differs how? You can associate metadata with a filename -- if you can do it for an "object", you can do it with a file. (Even old-fashioned filesystems keep things like last access time, size, and the name itself is often used to give further, human readable clarification, such as .html or .doc; although it may lie and we may care not to use it for such, that doesn't change to point of associating metadata with the name-as-a-handle.)

Third, the ability to hang metadata off the object gives us the ability to create all sorts of useful policies and services around the information without having to put everything in some sort of database or repository.

Double eh? If this (it's a GUID, or globally unique identifier);

c2f41010-65b3-11d1-a29f-00aa00c14882

doesn't require a repository or a database for its metadata, I'll eat my shorts. Again.

The internet solved this problem a good while ago. See RFC1737, RFC2141 and RFC3986. The essence of the RFCs; part is a name (like Roman Rock) and part is a location (like Afghanistan). The part that is the name doesn't tell you where the file is located; but the part that describes the location can be completely absent.

An example is in order. To demonstrate how far things have changed since Chuck banged away with Unix pipes and vi in the1900s, this returns a file;

http://blogs.netapp.com/shadeofblue/2009/08/poetry-corner.html

Interestingly, the file doesn't exist until you ask for it, because it's dynamically generated from parts. There's no directory shadeofblue, 2009, or 08, and no file poetry-corner.html either. And (here's a clue how far this goes) it doesn't live on a server at netapp.com either. It's all name and no location, and it works across the entire internet, not just inside a single object store.

Filesystems aren't the problem here; it's an attempt to make Atmos relevant. I think I'll send a bluey to Chuck and let him know; The Future Doesn't Have an Atmos.

 

---

I'm off to VMworld next week in San Fransisico. It's my first time at a VMworld conference, and I'm not quite sure what to expect.  But I do hope to meet lots of interesting people I've never met before while I'm out there. If you recognize me (yes, I look like the photograph), please introduce yourself. And no, I don't bite!

30 Years Ago; Cloud Deja VU

There is, as they like to say in Yorkshire, nowt new under the sun.

Here's an announcement from IBM that covers not only advanced cloud virtualization (much more advanced than we have today!) but also CDP (Continuous Data Protection) of VMs too. IBM's Virtual Universe Operating System.

The announcement date for OS/VU? Three decades ago, in 1979.

I remember this spoof rather well. In 1982, some helpful soul at IBM's Yorktown Heights sent me this to cheer me up. I was spending long evenings and nights on the phone with IBM, struggling to install APL and a planning application running under VM/CMS on a mainframe.

I got there eventually. I was probably one of the first of a handful of people at that time that managed to deliver a virtualized, containerised and cloud-like environment for end users.

I even provided the equivalent of vMotion. On tape. Ah, how little times change.

This month also marks my 30th year in the IT industry. I started out with no specific plans except to do what I enjoyed most; getting to play with -- ahem, work with computers, and getting paid for it. It's been a great three decades.

No cards or flowers, please.

---

NEW IBM OPERATING SYSTEM

Because so many users have asked for an operating system of even greater capability than VM, IBM announces the Virtual Universe Operating System -- OS/VU.

Running under OS/VU, the individual users appears to have not merely a machine of his own, but an entire universe of his own, in which he can set up and take down his own programs, data sets, systems networks, personnel, and planetary systems. He need only specify the universe he desires, and the OS/VU system generation program (IEHGOD) does the rest. This program will reside in SYS1.GODLIB. The minimum time for this function is 6 days of activity and 1 day of review. In conjunction with OS/VU, all system utilities have been replaced by one program (IEHPROPHET) which will reside in SYS1.MESSIAH. This program has no parms or control cards as it knows what you want to do when it is executed.

Naturally, the user must have attained a certain degree of sophistication in the data processing field if an efficient utilization of OS/VU is to be achieved. Frequent calls to non-resident galaxies, for instance, can lead to unexpected delays in the execution of a job. Although IBM, through its wholly owned subsidiary, The United States, is working on a program to upgrade the speed of light and thus reduce the overhead of extraterrestrial and metadimensional paging, users must be careful for the present to stay within the laws of physics. IBM must charge an additional fee for violations.

OS/VU will run on any x0xx equipped with Extended WARP Feature. Rental is twenty million dollars per cpu/nanosecond.

Users should be aware that IBM plans to migrate all existing systems and hardware to OS/VU as soon as our engineers effect one output that is (conceptually) error-free. This will give us a base to develop an even more powerful operating system, target date 2001, designated "Virtual Reality". OS/VR is planned to enable the user to migrate to totally unreal universes. To aid the user in identifying the difference between "Virtual Reality" and "Real Reality", a file containing a linear arrangement of multisensory total records of successive moments of now will be established. Its name will be SYS1.EST.

For more information, contact your IBM data processing representative.

Mainframe humour! Honestly, it is funny, but perhaps you had to be there to get the jokes.

[I'm on holiday this coming week. Normal service will be resumed shortly.]

.

A History of Emergent Properties

Steve Duplessie's latest blog points at his ESG paper, Commercial Computing Market Dynamics, a continuation of a cloud discussion that started on Marc Farley’s blog, and it’s well worth a read.

Note the subhead to the paper; Predicting the Future by Observing the Past. That got me thinking, so here’s my response; not a criticism of Steve position specifically, more an attempt to point out that, just perhaps, prediction of the future might be pointless. 

What qualifies me to comment? We're all pioneers here. Some are more aware of the past than others, but no-one has yet sat their Cloud 101 exams, We're all rookies, stumbling our way forwards, and this is me (partly qualified based on my 30 years of past experience), adding to the discussion.

I'll assume you've read Steve's paper, because this blog is a (very) short review of a few of the ideas Steve presents, and some personal observations on them.

Steve identifies three eras; Transactional, Distributed and Internet/Cloud. I’d like to extend out in a separate dimension and identify three different eras;

• emulating and eliminating the manual
• the conceivable, but only achievable by IT
• the inconceivable.

Not as succinct or as snappy, I know.

Much of the business activity that drove the great computing revolution of the 1960s and 70s Steve identifies as; how do we get better at the things we have always done manually? Payroll and numeric clerical tasks were first; the great Lyon's systems of the 1950s paved the way. Growth continued in the 60s, but it was still focused on emulating and eliminating the manual.

An example. Cheque (or check) clearing was a major activity carried out by the banks manually prior to the introduction of machine-readable and clearable cheques. It was said (only half jokingly) that the entire population of Southern California would be required by the 1990s to manually process payments, and the replacement of this most labour-intensive of banking tasks with automation drove costs down and increased profitability.

Steve then identifies the next step; leveraging the technology to do tasks that would have been conceivable, but only achievable by IT.

More to the banks' liking, IT allowed growth beyond what was physically possible. They introduced ATMs (cash machines), electronic funds transfer, credit and debit cards, in a very short space of time. They exploited an emergent property of the systems they first employed to do payroll and to clear cheques; its ability to crunch numbers far beyond what was possible manually.

Storing and processing large quantities of data became the norm, as did generating new and different data. Data created beyond the simple analysis and management reports of the manual IT phase was possible, and became the dominant type in terms of its size and importance to the business.

And now we’re in the era of the inconceivable. Using IT for functions that were undreamt of; virtual reality, CT scans and tomography, modeling stochiastic business and scientific processes...

And so on. You get the drift, I'm sure. The inconceivable is now as much part of our daily lives  as breathing, eating, sleeping; and dreaming of yet more applications of the second industrial revolution that started, quietly doing your payroll, in the 1950s.

But who would have dreamt back then that this is where we would end up?

To cut what could be a long thesis short, Commercial Computing Market Dynamics is an educational, persuasive and thoughtful paper that explains the history well, and points to why the IT model of the last 50 years is getting turned on its head. But I believe that there’s more than the three periods identified (Transactional, Distributed and Internet/Cloud).

They are (to me at least) just convenient labels to mark the passage of time.

There’s another history that isn’t described; and it’s non-linear, near-random, opportunistic and messy. A history of emergent properties. A property that can’t be predicted by looking at the parts alone, that’s greater than the sum. It’s what’s driving this phase of IT development, the inconceivable.

Here’s an example. In Steve’s comment on Marc’s blog, he says; ”So, who cares if Google's service goes down? How much are you paying to use it?”

We’re in an era of free [software/storage/compute/network]. Or free for some and nearly free for the remainder. For the first time in IT, there’s almost no way of describing value in terms of cost, because the denominator is tiny; often zero.

“So who cares if you’re not paying for it?” has only one answer; anyone who uses it, that’s who cares. This stuff has become a right in the individual consumer market, not a contract based on an exchange of consideration. That’s an emergent property that I, for one, would have been hard pressed to identify from the process of "Predicting the Future by Observing the Past". For me it falls, fairly and squarely, into the inconceivable category.

Back on Marc Farley's blog, Steve noted; “We can't even agree on what the cloud means.” Sadly, I’m forced to agree.

.