On Being Open : January 2008

Previous Next
0

BarCampESM

Posted by Steve Carl Jan 24, 2008

The first ever BarCampESM has come and gone, and I have waited till now to post anything about it.

 

Part of that is that this was my first BarCamp ever of any kind. I have been thinking and mentally digesting what happened at the BarCampESM even, and trying to classify it.

 

Part of what I have been thinking about was “What part of what happened was 'BarCamp' and what part of it was ESM vendors / providers at any given technical conference”.

 

After some more thought I have decided one BarCamp does not give me enough context to actually know the answer to that one. I'll have to go to a few more BarCamps to know the answer to that one.

 

Why I was puzzling on that was to ask “Why would someone come to a BarCamp instead of a regular conference?”. Is there an advantage of some sort to the “Un-Conference”. I think the answer to that is easy, and is “Yes”. Here is why.

 

I have been to tons of technical conferences. SHARE, CMG, LinuxWorld, IT/360, BMC UserWorld, etc. The formal presentations are almost always useful, and the ability to mix up the tracks to create a customized education experience is valuable. But more valuable that that has always been th 'downtime' or 'whitespace' or whatever you want to call it around the sessions. The Q&A at the end. The talks in the halls. The talks over lunch or dinner with like-minded people. The opening up and sharing at a level one can not attain during a formal session.

 

BarCamp is that “down” time, except it is almost ALL that time. What takes some getting used to is that one has to be good on their feet. Impromptu presentations are the norm it would seem. By the end of the day, Heath Newburn got up to talk, and said that he had thrown away what he meant to talk about and instead wanted to talk about something else... and he had a brand new set of slides he had typed up while listening to others to go

with it.

 

This talk in turn developed into everyone sitting in a circle, and really “letting their hair down”. Part gripe session, part experience sharing, even Cote, who said at the beginning that he was there to observe ended up doing a fair amount of talking about what he had seen. For once, I was the quietest person in the room. No mean feat.

 

You can see the projects that this BarCamp kicked off elsewhere here on the OMC wiki. In his blog John Willis (http://www.johnmwillis.com/wp/barcamp/barcampesm-photos/) said that attendence was lower than he expected, but that it was a “can't miss event”

 

BarCampESM II should be very interesting indeed.

 

 

0 Comments 0 References Permalink
1

The VW Beetle Principle

Posted by Steve Carl Jan 16, 2008

 

First off… I admit it. I totally made that principal up. I needed a sort of reverse (if dated) example as a counterpoint for Whurleys “Bugatti Principle” post over at TalkBMC from last year:

 

 

 

http://talk.bmc.com/blogs/blog-whurley/whurley/the-bugatti-principal

 

 

 

The VW beetle would seem to be the antithesis in most ways, at least in principle and concept, from the Bugatti Veyron. Not exclusive. Not fast. In fact designed to have the absolute minimum required and still be a workable car for the road of its day. I had a 1965 Beetle convertible with a 1200cc, 40 horsepower engine (which I admit I hacked. I “dropped in” actually shoved up a 1600cc, 67 horsepower engine to replace the original mill. It felt like a race car in first gear)

 

 

 

The car was not fast. It got fairly good mileage for the day (about 27 MPG: Ludicrous by todays standards). At about 65 miles per hour the shape of the car made it tend to want to lift off the road, and depending on wind direction 65 to 70 was all she would do. After that the wind resistance overcame the engine. The Beetle looked round but was about as aerodynamic as a brick. With its flat pan shaped bottom (the reason it actually would float for bit. I watched mine float till it sank during a hurricane once), and its arched body shape, it more strongly resembled a poorly shaped wing than a brick, but the principlel was the same. Its aerodynamic drag coefficient was .48, where a wall is 1.0, and a Hummer is .7.

 

 

 

Everything about the car was the minimum in late 1930’s-1940’s design. The heat for winters came from the finned exhaust pipes to the front two cylders of the flat four. Air was take from the cooling fan and diverted over these fins, and then into uber-hot but tiny floor vents. Once it was warmed up in the cabin, It was a pretty pleasant place to be in the winter, but it took forever to get warm. Plastic laid near the tiny vent would melt. I know.

 

 

 

There were two moderately comfortable seats, a speedo, an AM radio, a glove box, a 10 or so gallon fuel tank, a full size spare, four 15 inch, skinny tires, and windows that rolled up and down with hand cranks. As basic as the beetle was I suppose you could go even more basic and delete the radio and the heater and the roll up windows and still have a useable car, but it was pretty basic. Very close to the smallest and fewest parts a car could be and still be a car and not something else… like a tricycle or a motorcycle. And yes, some Beetles have been made into both of those.

 

 

 

The Beetle was the low cost leader in the US in the 1950’s and early 1960’s: they predated Datsun and Toyota and all that. British Leyland cars were anything but inexpensive, especially once you factored in the Lucas Electrics (Prince of Darkness) repair bill. I remember seeing ads in the paper when I was kid for 1900.00 USD for the sedan. 1960’s money. Adjusting for inflation that is about 12,000 USD now. That looks about right too: A 12k car in the US is at the most basic end of the market, even if it is technically a much better car: more fuel efficient, less pollution, more crashworthy, AM/FM radio….

 

 

Related to Systems Management?

 

 

 

The Beetle was as basic a car as it could pretty much be and still be a car. Factored into that were all the things that it took to be a car, and all the costs that went into developing and manufacturing and updating the car. In fact the 1965 car looks positively modern when you compare it to the 1940’s prototypes. Those had mechanical flags rather than electric turn signals!

 

 

 

To support that car was a set of designers, engineers, QA testers, Sales and marketing folks, and all sorts of hidden costs like the cost of building and maintaining the steel stamping gear, the aluminum engine casting plant, and on and on. There was a minimum cost below which the Beetle could not cross and make any money. It had to make money. VW was and is a commercial car vendor.

 

 

 

Systems management is hard. On the high end (The Bugatti end), it takes a great deal of work to successfully manage large, complex, heterogenous systems and to do it well. Do it invisibly. Do it as if it were data tone.

 

 

 

At the same time, there is a lower limit below which a commercial vendor cannot easily cross. To maintain that manufacturing line and all the staff, the building, computers, and benefits. The travel budgets and comm gear. On and on. To go below a critical size is to move into the realm of unprofitability. No public company can be unprofitable for long before they board fires the executives and find some others that will make it profitable.

 

 

 

Size Works at Least Two Ways

 

 

 

One kind of “lower limit” in systems management would be number of managed nodes. A management system that is designed to “boil the ocean”, I.E. manage huge environments makes no sense below a certain level. How far a management system can scale down when it is designed to work for say 100,000 or 500,000 managed nodes. That puppy is Bugatti’ed to death. It is tested, built, designed, engineered, scaled, and everything is oriented around making sure that it can “go as fast” as is advertised. It would almost be silly to use it to manage, say, 10 systems. First off, 10 systems don’t even need that kind of management. If they are all in one place, you can sit and see all their screens at once!

 

 

 

Another kind of scale issue is the type of managed node itself. There are a zillion devices in this world, and IPv6 is going to make it so that everything on the planet sooner or later has an IP address. My fridge, my toaster, my stereo… everything. If an electron can run though it, the possibility is there that it might need an IP address someday.

 

 

 

All that diversity usually leads to a “Tower of Babel” though. As the wit once said, “The good thing about standards is that everyone has them”. Unless Open Standards are used, this is going to be a real problem for the widget in question.

 

 

 

On the one hand, out here at this edge is where a great deal of the innovation is going to be. The latest widget that sets the world on fire will come from here. Or Apple. ☺ Maybe I should have used the "MacBook Air Principal" here... But I digress.

 

 

 

While the widget is tiny, unless they are playing in a space where an Open Standard already exists (and if they are creating a category, it probably does not) then it may not be worth everyone supporting it I am not even talking about competition here, but time/effort to add support to an existing solution. This alleged world turning widget may come from a big vendor, a small vendor, or a child with the OLPC XO and a good idea. Whatever it is, while it is small… while it does not command enough market share to hit the lower limit of a management vendor to create a management tool for it, then its management is either created at the same time as the widget by the same creator, or by the first person who needed to manage it so badly that they gave up waiting for the vendors and wrote it themselves.

 

 

 

If it Were Easy, Anyone Could Do It

 

 

 

All of the above listed conundrums and complexities are just to underline the point that systems management is not easy. Even at the lowest end of things, there are things that any solution has to have, and has to deal with. They are not always technical. But that takes me to….

 

 

 

The Honda Fit (Jazz) Principle

 

 

 

Because my new car is a Honda Fit of course. I sit in the car and I marvel at it sometimes. How this tiny econobox (SuperMini actually) has benefited from all that came before it.

 

 

 

I have owned many Hondas over the years. A 1984 Prelude, and 1986 Accord, a 1992 Integra, and now this 2008 Fit. This is the best car of the bunch. It is low emissions (number three best in 2007), gets fairly decent fuel economy (38 MPG best tank so far), and is relatively quiet and comfortable for such a small car. It is a littler faster than I was going for, but in the US they don’t give us the option of the smaller, even better fuel economy engines.

 

 

 

I see the lineage of all the other Hondas I have owned here. The design, the way it sounds, the way it handles, the materials choices, the control layouts. On and On. This car has benefitted from all the 100+ years of car design before it. The best shape for the wheels being round. Low drag wheels and tires being better. The rubber material in the tires being both “sticky” and long lived. The way the tread is now designed with a computer to siphon off the water on the road. Radial belts to lower rolling resistance. Light unsprung weight of the wheels helping handling. Disk brakes being better than drum. A radio that has more computer bits in it than my first TRS-80. The new little chips that are better than the old bigger chips which are better than the older transistors which are better than the old tubes. The current generation of plastics having a longer life, nicer touch, and being more recycle-able. This could be an infinite regression.. The car stands on the shoulders of all the cars that have come before it, and not just from Honda… and for that matter, not just of cars.

 

 

 

All computer programs, including systems management software are the same way. Innovations in version 1 of Patrol (for example, since I know that one) and the way it allowed system programming knowledge to be captured and automated were picked up and improved by others (and therefore made Patrol have to improve too). Having to hand build and hand install management toolsets giving way to automated discovery and automated install and provisioning servers. SNMP standards started out too loose, were tightened up and further defined, and later releases were far more useful that the first, and then most of the system management tools started being able to use them.

 

 

 

Layer upon layer, one thing building on another. Capability growing, along with complexity. Open Source / Open Standards / Open Frameworks, etc. makes all this layering and building and improving far easier, and far faster.

 

 

 

Scale and Moore’s Law

 

 

 

In my VW Beetle principal, the 1.9k 1965 Beetle and the 12k economy car of today show what happens as technology improves and time goes by. The least expensive car for sale today in the USA is a bit under 10k, inflation adjusted less expensive than the Beetle was in its day. That car is in every possible way ( no matter which car it actually is, but a quick google makes it look to be the Chevy Aveo at 9955.00 USD ) the technical superior of the 1965 car. In fact, Tata just introduced a 2,500 USD, 2 cylinder, 33 HP, 50 MPG car called the Nano:

 

 

 

http://www.boston.com/business/technology/articles/2008/01/11/indian_automaker_u nveils_worlds_least_expensive_car/

 

 

 

All the feature / function of the original Beetle at a quarter of its inflation adjusted price, and double its fuel economy.

 

 

 

Computers are even “worse”. While Moore’s law is not infinite, nor even really a “Law”, The over the counter cheapie computer I can buy for 200 USD right now is technically better than the 1000 dollar computer of five years ago more or less. Point being, an inexpensive computer can now manage quite a number of other computers. Where one used to have to install a steamship full of computers in the data center just to centralize all the data from the managed nodes, now it can be a raft.

 

 

 

At the same time, not all the complexity is dropping out of the equation. Sure, the number of computers needed for management dropped, but unless there is a hugely aggressive turnover in the data center to match it, the number of managed nodes probably grows over time, and the complexity of the managed nodes is probably is growing too. Can you say ‘Virtualization”? How about “Vista has 20 million lines of code in it”?

 

 

 

Don’t even get me started on analogies about re-inventing wheels.

 

 

 

While there are incredible things one has to do to build a Bugatti, and certain other scale problems like high end systems management, especially when integrated into overall ITIL solutions, there are also a certain number of minimum things one has to do. That is where being O/open really helps.

 

 

 

The steam train becomes the first car becomes the Model T becomes the Beetle becomes the Fit. I might have skipped a few steps along the way there…

 

 

 

I think I have tortured this analogy enough for one day. See you at BarCampESM this weekend!

 

 

1 Comments 0 References Permalink
0

O/open S/source

Posted by Steve Carl Jan 11, 2008

I am always interested is watching and reading discussions around what Open Source or Open Standards exactly are. Some folks are very passionate that if a particular thing: Object, projects, whatever, does not meet their exact definition of open, then it is therefore not. Not good. Not Open. Not open. It is bad.

 

I was presenting at the Z Series conference 3 or 4 years ago, and during my talk about VM I mentioned the the OS was "open source". In the Q&A afterwords I was challenged on that characterization. Vm was not GPL. It was not Apache. It was not any "Open Source" license at all. It was and is a copyrighted work of IBM. It was also the first real Virtualization OS, but I digress.

 

In the early days IBM had no real use for VM other than as a migration tool. As such, they had an option where you could order the source code. It would show up on the tape, and one could load it to disk. In fact, to put on a patch required have the source code because the patch updated the source, and then rebuilt the module or nucleus or whatever.

 

The source code was open in the sense that it was there for all the world to see. And having access to it sparked all sorts of innovation. One example was the V/ line of products from then VMSI. VM had a problem. Several of them in fact. One of them was that IBM did not love it. It was always a step child to MVS. MVS sold hardware: it took 10 times as many resources to log in to TSO (Time Sharing Option) as a user than to VM as a CMS user. CMS was the end user interface bit to VM. The part that defined the editor and the file systems and so forth.

 

Since VM did not get a lot of development cycles from IBM, it did some fairly stupid things sometimes. One was that when it came across an internal error, it would abend. Even stupid little things would cause a complete system reboot. VMSI created a product that intercepted the abend, backed it up a step, then made an attempt to do something to fix the problem rather than just break. In most cases, VM could stay up, or at least limp along with only a partial disability until an outage could be scheduled.

 

Even better, they had another product that would take a dump of the OS before it started fixing things so that the problem could be looked at and shot while the system stayed up. There was even the option of a snap dump so that the whole memory core did not need to be dumped, just the relevant bits.

 

IBM added features like these to later versions of VM once they saw the wisdom of them. And of VM for that matter.

 

I would love to have features like this in Linux or BSD today. They came about because VMSI had access to the source code, even though VM was not GPL or whatever.

 

Amdahl was another company that benefited greatly by access to the source code to VM. VM was a virtualizer... and it virtualized the mainframe. Amdahl wanted to build Plug Compatible Mainframes, but the book the IBM had published, the 370 Principals of Operations or the "POO" was not actually 100% accurate. VM gave Amdahl all sorts of ideas. They created the predecessor to PMA called VMPE (VM Performance Enhancement) so that some virtual machines could get a little extra boost. PMA (Preferred Machine Assist) was IBM's late to market answer to Amdahl's innovation. Amdahl then created its tour de force product: MDF, or Multiple Domain Facility. Again IBM had to respond and created PR/SM. PR/SM (pronounced "Prism" usually) was... VM in the microcode of the mainframe. No. Really. IBM has always denied this, but I watched some CE's at the CE console once, and saw the error messages: that was VM in there. It was years before PR/SM could do what MDF did. I knew several folks at IBM back then that were deeply worried that folks would figure out just how good MDF was before IBM had something to compete with it.

 

Note: Updated 1/21/2008 to correct a technical point: Originally I wrote the IBM's answer to MDF was LPAR. It was in fact called PR/SM, and the "Domains" of MDF were called "LPARS" or "Logical PARtions". Thanks to Richard Meyer for catching that faux paux

 

One last point here: The best professional training I ever went to was Amdahl's VM diagnostics class. That class was written because they could look at the source and develop material about how to read dumps, and had the ultimate reference: they could show how the thing actually really worked!

 

Having open source... access to the source code, lead to these things, and they ultimately benefitted the customer.

 

It was not Open. It was just open.

 

Hey Steve.. is there a point in there? Only that openness comes in many flavors, and honest attempts to be open should not be greeted with derision and scorn if they are not 100% in line with a particular definition of open.

 

OOXML and the like can be as derided as one likes though. While I am for folks (I include companies in that) trying to be more open, It really gets up my nose when they start trying to use openness as a trap. I think there are several conversations about patent traps elsewhere on the forum recently: I am so not talking about that kind of "open".

 

 

0 Comments 0 References Permalink