Category: 1K

For the last few weeks I’ve been trying to figure out how to write up an idea that’s been bugging me. I think it’s an interesting idea, but until I can actually write it up I won’t be sure. So today I just decided to blurt it out into the blog, relatively unformed, certainly unfinished, definitely half-baked.
There seems to be an expectation today that distributed computing means web services – or that it will do, just as soon as the various standard bodies and corsortia get their acts together. I’m unconvinced. I see three ways – three axes, if you like – in which there are strong arguments for widely differing and incompatible positions; when you combine these, you get a 3D design space which is much bigger than what web services aficionados would claim. (And just to be even-handed, it’s also way beyond what we can do naturally with things like Jini and RMI.)
I’m just going to describe these three axes, without attempting much justification. Zealots can argue all they want….

• The first axis is interface typing. At one extreme, a service can only accept a message of a single type, encoded in one way; if the request doesn’t match exactly, no interaction is possible. (Think CORBA or RMI.) At the other extreme, a service will accept any type of message, although of course it may have to reply “Sorry, I don’t understand”.
• The second axis is control. At one extreme, the behaviour of the client and the service is rigidly specified, and the binding between the two is explicitly controlled and predictable. (Choreography languages, workflows, message exchange patterns, protocol FSMs come to mind.) At the other extreme, components are substantially autonomous; a client can search for a service at run time, a service can choose to delegate a request to a third party, and parties can renegotiate their interaction patterns on the fly.
• The third axis is synchronicity. At one extreme is the traditional synchronous request-response style, which is directly derived from the procedure call paradigm. The service is essentially passive; indeed we usually draw this interaction with a single thread of control running from client to server. There are other synchronous interaction patterns, typically described by state machines. At the other end of the spectrum, messages may be sent between the parties without temporal constraints. Partners may repeat messages, “interrupt” each other, or even “change the subject”. (I don’t want to get into the definition of [a]synchronous right now – that’s a whole blog piece on its own. Let me just say that it’s about the pattern, not the implementation technique; I’m not interested in dependency on a transport connection or blocking i/o.)

To summarise, we have:
Interface typing, from strongly typed to untyped
Control, from choreographed to autonomous
Synchronicity, from synchronous to asynchronous
Now strongly typed, choreographed, synchronous is very familiar: it’s the classic RPC style. Untyped, choreographed, synchronous is what we find in the WWW today. At the other extreme, untyped, autonomous, asynchronous corresponds to the Holy Grail of the agents and semantic web community; it’s also a pretty good description of human beings, which should come as no surprise.
What I find interesting is that I can think of really compelling use cases for both ends (and some middles) of each of these axes. One size will certainly not fit all. And in some cases we want to have our cake and eat it too:

• On control: I want the elements in my distributed system to be substantially autonomous and self-organizing, to improve scalability and avoid single points of failure. On the other hand, I want to be able to define policies that will influence the self-organization, and to have ways of observing and measuring what’s going on.
• On typing: I want the safety and efficiencies that arise from working with predefined types with efficient encodings. On the other hand, I’d like to be able to refactor my distributed system by introducing generic facades for brokering without having to teach my broker about every service type that it might have to support.

Anyway, that’s what I’ve been thinking about. Now to see if it makes any sense in the cold clear light of blog….

GeoffArnold.com has been successfully rehosted on Grommit.com – thanks, Steve. I’ll be tweaking a few things over the next few days, but we should be back to normal – or whatever passes for normal around here.

A couple of days ago I posted a piece entitled “No, but God, we’d love to!” which I said captured what I want Sun to be, and asked Jonathan if he was listening. He was, and he asked what I meant. So here goes.
Over the years, I’ve talked to many of Sun’s customers (as well as companies that ought to be our customers!). Now maybe it’s just because customers get bemused by my job title, but I find that most of these conversations follow a pattern. Quite simply, the customer expects to talk to Sun about how the hard problems in computing are going to be solved. Of course there may be contemporary issues to be discussed – a product release, a support problem, a pricing gap – but underlying it all is the expectation that Sun’s the company to talk to about the future technology of computing. Not just the future of business models, or the future of supply chain management, or even the future of intellectual property. Moreover the conversation is usually about the big picture, about a “we” that embraces Sun, our customers, and our partners and competitors. It’s not simply about Sun’s perspective, or Sun’s products. I get the impression (and sometimes the explicit assurance) that it’s a very different conversation from that which they have with IBM, Microsoft, HP, Dell, EMC, Cisco, or Oracle.
This shouldn’t be a surprise, of course. Ever since I’ve been with Sun, we’ve had noisy, energetic, contrarian technologists on the front lines – folks like Bill Joy, Tom Lyons, Rob Gingell, James Gosling, Greg Papadopoulous, John Gage, Andy Bechtolsheim, Jim Waldo, Whit Diffie, Michael Powell, Graham Hamilton, Hal Stern, Randy Rettberg, Bert Sutherland and many others. And they’re not just emeritus uber-geeks: they are building stuff. Cool stuff. Today. They’re changing the way people think about problems. And customers recognize that. The upshot is that when I visit [name deleted] we’re not just talking about the features of the next point release of a product; we’re discussing the big picture, the hard problems that we are all wrestling with, customers and suppliers alike.
Now of course the great challenge is how to monetize this. It’s no good if the customer takes the fruits of our conversation and buys a bunch of Dell 1Us, slaps Red Hat on them, hacks some JSPs on Tomcat and rolls out yet another DIYIT (“do it yourself IT”) solution. And (pace Slash-Dot) the answer isn’t for us to simply open-source everything and trust in the beneficence of Eric’s Bazaar. But neither is it to focus on proving that JES on Solaris on Athlon or Niagara can be as cheap as Red Hat (with the help of a creative pricing model). We need the pricing model, but if we lead with pricing instead of technology, customers will be confused.
Fundamental customer perceptions of a company don’t change rapidly, if at all. IBM is still “Big Blue” (“Father knows best”). Microsoft is still a PC software company; we got so used to rebooting regularly that we expect it. HP is still about printers and (deep down) scientific calculators. And Sun? We’re a company of creative, contrarian, imaginative, curious geeks. We’re the guys that zig when everybody else zags. We’re “The Network is the Computer”. We have to figure out how to leverage that, use it as part of our business model, while being careful not to behave in ways that blatantly conflict with that image. Because being seen as a the company whose response to a thorny problem is, “No, but God, we’d love to!” is priceless.

Last month I wrote about why I blogged, and what I hoped that readers would get out of it. Today my colleague Richard Giles posted a reference to John Hiler’s piece from March, 2002 [and doesn’t that seem a long time ago?] on The Tipping Blog: How Weblogs Can Turn an Idea into an Epidemic. As the title implies, Hiler applies the ideas of Malcolm Gladwell’s book The Tipping Point to blogging, pointing out how different kinds of bloggers play the key roles of what Gladwell calls Connectors and Mavens. (Tim Bray seems to be the quintessential Connector – eh, Tim?)
And of course this blog entry simply contributes to what Douglas Hofstadter called a “tangled hierarchy” of self-reference! In fact, I wonder how many blog entries are actually ABOUT blogging – all the way from the simple Getting started, to comments about PG-13 content, to angst-filled discussions about blogs in politics. The title that my colleague Josh Simons chose for his blog seems particularly apt…..

[Revised 5/30/04]
My colleague Simon Phipps has just posted a lengthy piece entitled On Java and Openness. I agree with him pretty much 100%.
A lot depends on whether you approach compatibility and interoperability from a “standards” position or not. The “standards” viewpoint is that there are going to be multiple implementations, that this is a good thing, and that you need to make sure that these implementations can interoperate. This was always the IETF approach: a proposed standard with only one implementation was viewed as problematic, because you couldn’t distinguish between the intention of the standard and the accidents of implementation.
I started at Sun in 1985, and my first job was to do an implementation of NFS for MS-DOS from spec. All of the previous implementations (for various types of Unix as well as VMS) had been based on the source code, so I guess that I made Rusty Sandberg and the other spec-writers pretty nervous. But it worked. Later I worked with folks from FTP, Microsoft, and JSB to develop the Windows Sockets specification, and we recognized from the start that the conformance verification model was going to be key to acceptance.
I’ve always taken an object-oriented approach to standards: I believe that a standard is an object with one method, bool Conform(implementation i). If an implementation, i, conforms to the standard, I can use it. Of course this presupposes that the standard is adequately specified and the Conform() method is trustworthy, but that’s why doing standards is hard work. It also explains why the Reference Implementation (RI) is such an important concept – that if (or rather when) the language of the standard proves inadequate or ambiguous, there is an authoritative answer: the standard is what the RI does. Critically, the RI is not supposed to be the only implementation; it should be optimized for clarity and conformance rather than performance, size, efficiency, etc.
Everything that I’ve seen about the open source movement suggests that it is designed to encourage group participation on a single code base, rather than the creation of multiple independent implementations. Where’s the 100% compatible clone of Perl, or Apache or Sendmail? In that respect (paradoxically?), open source leads to a monoculture, just as much as Windows does. When you actually have multiple implementations, you have to face the question of whether compatibility is important or not. For platform technologies – systems that other people rely on to make their software work – the answer seems to be yes. And despite the absolutists that Simon cites, there is no evidence whatsoever that a free market approach can sustain compatibility, except by preferring one choice and allowing the others to wither. To me, monoculture – even a free monoculture – seems dangerous. Diversity is good.

Like a lot of people in the computer business, I am intrigued by the impact of RFID tags and other sensor technology on IT. But my interest is fairly narrow: I’m curious about what kind of workloads these technologies will impose on corporate data centres. To understand this, I want to get a handle on the numbers: the sensor event rates (both the flow rate and the burstiness), what kind of intermediate aggregation and filtering will be performed, and what the resulting datacenter workload will look like.
Sounds straightforward, doesn’t it? Not that it’s a simple problem, but we can construct some scenarios, assign some numbers, plug them into a queueing model, see how it looks. (Capacity Planning for Web Services: Metrics, Models and Methods includes some simple models.) The problem that I’ve found (repeatedly) is keeping people on topic whenever I try to discuss it.
“But we can’t ignore privacy issues.” “Centralized data centers are passe – let’s project the data centre to the edge.” (I love that – what on earth does it mean?) “Data centres – not data centre! Federation!!” Or we replace inventory control tags with hospital patient tags, in which case discussions of domain-specific issues rapidly crowd out everything else.
The general problem, which I’ve observed in various contexts, is that it’s increasingly difficult to keep people focussed on simple problems. Of course all of the issues that people raise are real, but in most cases they are either irrelevant or simply complicate the problem in incalculable ways. We need to focus on the simplified versions of the problems in order to use them as tools to analyze alternative architectures.
My dream is that one day someone will listen to my scenario and immediately propose a simplification, in order to make it more computationally tractable. Most of the systems that we’ve dreamed up over the last twenty years are far too complicated, and the analysis of the whole becomes even more problematic if we load even more complex application patterns on top of them.

On April 4 I posted a piece in which I discussed my reactions to the Sun-Microsoft deal. This week I was in California for meetings at the Sun Menlo Park campus when the news broke about the big reorg. As the dust begins to settle, I thought I’d blog my initial reactions to this. After all, I’ve been at Sun nearly 19 years, and it’s a big part of my life.
First, let me summarize the announcement (since some journalists still couldn’t get it right even after the press flash, the analysts’ call, and widespread discussions). Before this change, Sun was organized into a number of business units. ESP built mid- to high-range SPARC servers; VSP built low- to mid-range servers based on SPARC, Xeon, and Athlon processors, as well as SPARC workstations; PNP designed SPARC chips (fabbed outside); NWS did storage systems; SW did software: Solaris, Java, middleware, desktop, N1, identity, embedded.
After the change, NWS and SW are essentially unchanged (so far). Throughput Systems absorbs ESP, PNP, and the SPARC-based products from VSP. Network Systems gets the Xeon and Athlon lines from VSP, plus the Kealia acquisition. My guess is that Nauticus will also go into NS, though I haven’t seen anything definitive.
My thoughts on all this. First, I think it’s a step in the right direction. In the past, there have been charter issues about exactly where ESP and VSP should draw the line: now we’ll have a single division responsible for a (hopefully simplified) range of SPARC based products. The big debate about the roles of MPs versus blades in systems remains – after all, it’s not just a Sun thing – but it should be easier to get the balance right when it’s not seen as a turf issue any more.
Second, I want to understand exactly what the NS value proposition is. The announcement talked about low-cost horizontally scaled systems with off-the-shelf components that leverage industry economics. Does that mean a low-margin model, or a high-value one? If the latter, there needs to be a substantial investment in software to complement the off-the-shelf components. Does all that get done in SW, or should we split SW and move certain pieces into NS?
We’ve tried various ways of organizing SMI over the years. I regard the new structure as SMI 4.0. Here’s the taxonomy:
SMI 0.x: The original Sun with Scott, Vinod, Andy, Bill and the small gang of obsessive crazies who wouldn’t take “no” for an answer and got Sun off the ground. Led to…
SMI 1.0: when Bernie Lacroute came on board in 1984. Strong, relatively centralized engineeering and operations, with Bernie as effective COO. In this period we laid the foundation for real growth: SPARC, the AT&T deal to unify Unix, strong engineering processes under Rob Gingell. This was also the era of the 386i workstation (with which I was involved), and the infamous “Larry Garlick Memorial Decision” not to get into the router business. I think the last of these may have been one of the things that precipitated…
SMI 2.0: The era of “The Planets”: a core computer business (SMCC) surrounded by a number of independent business units: SunSoft, SunConnect, SunPics, SunSelect, and so forth. I remember Fortune magazine hailing this as the breakthrough model for the 1990s. It allowed us to enter and exit certain markets fairly painlessly – who remembers SunPics, the Sun printer business? – but it confused customers, because each BU had its own sales force and we couldn’t coordinate the customer-facing activities. Plus each BU was really very independent, and there were armies of people doing nothing but negotiating intra-Sun transfer pricing. (There’s a lesson here for bureaucracies that try to achieve efficiency though “internal markets”: they don’t work.) So during the 1990s there was a gradual shift to…
SMI 3.0: The defining characteristic of this version of SMI was the move to a single sales force. Because this changed the nature of the BUs, and led to a degree of functional rationalisation, it was tempting to see functionalism as the driving force, but it wasn’t. Behind the single sales force, the various BUs remained (?fiercely) independent. And the functional organization was never as total as it might appear. Scott might tell me that he’d “put all of software under Jonathan”, but these days engineering is software, except for a bit of physics, and there was (and is) software development going on all over Sun – appropriately so. The fact that Zander was COO for a while, and a few high-profile people came and went, and we went through the bubble, didn’t really change this model. But the decision to put Jonathan Schwartz in as COO, and his “activist” managerial style, definitely signals a shift, to…
SMI 4.0: Maybe this should be SMI 3.1 instead, but never mind. This model has a strong Back To The Future feel: Jonathan Schwartz gets to play the part of Bernie Lacroute. One sales force, internal units organized for operational efficiency and execution rather than along business lines.
It’s never boring.

Just got back to my hotel [in Seattle] after the Easter service at St. Mark’s Cathedral. No, I haven’t gone and got religion; I was there with my son, Chris, who was being confirmed. A long service (started 8:30pm, finished about 11:15pm, we left the post-service socializing around 11:30pm), and a beautiful one. For the first 2 hours the church was lit only by the hundreds of candles the congregation and celebrants were holding. Now maybe I’m just an old fogey, but they don’t make candles like they did when I was an altar boy! These skinny little things burned down in around 45 minutes for most people, around 30 minutes for me. (No idea why mine burned quicker than usual.)
Chris’s sponsor was a really nice ex-teacher called Steve. During dinner before the service he and I got into a nice discussion about the relative importance of tradition and integrity (as in, why do Christians not cut out all of that blatantly un-Christian stuff from the Bible? Cue Thomas Jefferson…). Ironically, most of the readings during the first part of the service (before the baptisms, confirmations, and reaffirmations) were Old Testament passages of really questionable relevance to Christian values and beliefs. Steve had the good grace to acknowledge the fact….
Ah, well. I must head to bed, so that I can get up and meet Chris and Celeste for breakfast before tomorrow’s service when Chris will be an acolyte (complete with white robes and coloured streamers).
[By the way, religious proselytizers need not waste their time posting comments about religion. I’ve heard them all before, and I’m not interested.]

If you visit Amazon.com and look up “1984”, you’ll see a review which begins with the following words:
Airstrip One is part of the vast political entity Oceania, which is eternally at war with one of two other vast entities, Eurasia and Eastasia. At any moment, depending upon current alignments, all existing records show either that Oceania has always been at war with Eurasia and allied with Eastasia, or that it has always been at war with Eastasia and allied with Eurasia. Winston Smith knows this, because his work at the Ministry of Truth involves the constant “correction” of such records. “‘Who controls the past,’ ran the Party slogan, ‘controls the future: who controls the present controls the past.'”
I was reminded of this when I saw the photographs of Scott McNealy and Steve Ballmer, laughing and shaking hands last Friday. I’ve worked at Sun for nearly 19 years, and during that time Microsoft has always been the “Eastasia” with which our “Oceania” was at war. It was particularly awkward for me in the early years, because I worked on PC-NFS®, a software product that enabled DOS and Windows PCs to use Sun’s NFS [network file system] to share files. This obviously involved down’n’dirty systems programming hackery of Microsoft’s operating systems. I can still remember my first visit to meet the SunOS (Unix) group in California back in November, 1985, and their reaction when I told them that the NFS and UDP/IP software in PC-NFS was written as a 64KB device driver in x86 assembly language. And in the spirit of “using what you write”, I was always a PC user, attacting odd looks from colleagues with their Sun workstations. (I’m still an odd-ball, with my Mac PowerBook rather than a SunRay.)
Initially I think the competition with Microsoft was healthy for Sun – it certainly helped us punch above our weight in the marketing game. However, over the years the rivalry intensified and by the late 1990s it got w-a-a-y too heated for anyone’s good. It all culminated in various nasty lawsuits over Microsoft’s forking of Java and other monopolistic practices. My view was that the suits were thoroughly justified from a legal standpoint, but that it wasn’t clear that they were helping us in our primary rôle as a commercial enterprise. It probably distracted our customers, and I know that it distracted us. I’m sure that psychologists have a term (and a DSM IV category) for people who define themselves by what they are against rather than what they are for, by who they are not rather than who they are. Anyway, it became an institutionalized thing, much like the Red Sox and the Yankees, or Glasgow Celtics and Glasgow Rangers.
But now the Ministry of Truth has spoken. We have always been at war with Eurasia, and Eastasia is our ally. It’s going to take some getting used to…..

For the last few years I used the services of NetIdentity to manage my web presence at geoff.arnold.net. However they didn’t support blogs (or anything requiring server-side stuff) and only gave you 8MB of web space – not even room enough to swing a cat. So I’ve started this site using MovableType, hosted by LogJamming. Let’s see how it goes. Welcome.