- Will .Net amount to anything?
- Exclusion from the Web Services Interoperability Organization
- Linux on Intel, what it means for Sun
- Make Solaris open source?
- Distributed computing fallacies
- Jini update
- What is N1 all about?
- The next big thing
Where do the worlds of Java and .Net either collide or intersect?
I'm going to be relatively precise about the term Web services because I've noticed Web services is becoming a Kleenex-like term, referring to anything having to do with the 'Net. When I think about Web services I'm thinking about a network architecture with transports based on HTTP and sessions and presentations based on things like [Simple Object Access Protocol] and XML, respectively.
So to the extent you think of Web services as a series of protocols, as with all series of protocols somebody has to make a realization on both ends in order for the protocols to be useful.
.Net is a system that's been built up to talk to those series of protocols. And at Sun we have the SunONE environment, [the difference being that SunONE is] based primarily on Java. That's not excluding other programming environments, because the way Java has taken people to the Web has been to wrap legacy environments.
I don't think people appreciate that Java [Platform] Enterprise Edition represents about 95% of Web application architectures, but most of the code that implements those systems is not written in Java. [Enterprise Edition] is really a set of glue technologies that take existing assets and bring them to the 'Net.
So let's take an analogy. If you have a Unix system and a Windows system and there's an IP-based network called TCP/IP, Windows and Unix constitute two different styles of systems you could build that interoperate via those protocol environments. .Net and SunONE are likewise analogous, except rather than TCP/IP we're talking about transports based on HTTP and sessions and presentations based on SOAP and XML.
Does the development community either develop to Java or develop to .Net?
They're being forced to do that by the introduction of .Net. Whether that's going to be a successful thing or not, I can't say. I think most Web services are going to be derived from these existing Web applications, most of which are based in Java. And my guess is most things that are Web services will in fact be Java things. Indeed, if it were anyone other than Microsoft, nobody would be taking .Net seriously. It's only because of Microsoft's market presence that you can believe that anyone can, from a cold start, actually launch something that is otherwise the same only different than the stuff that otherwise was there.
I actually don't think they're going to be that successful at it. The network effect that exists around Java is going to mean that it's the dominant way people do this sort of programming.
And it's certainly true by vendor accounts. I mean, even Microsoft's erstwhile partner in terms of defining these protocols, IBM, is strongly committed to building these environments out of a Java base.
Interestingly, IBM hasn't actually declared what its peer to SunONE and .Net is. IBM's been curiously absent from taking that step, even though they've been supportive of the fundamental technologies in both camps. You have to wonder if maybe they're planning to play the role of Solomon in the marketplace.
It looks like Sun will be invited to join the Web Services Interoperability Organization founded by Microsoft and others. What does that mean for you folks?
What it's going to mean is going to depend on what it actually is. An interoperability organization founded on the premise of excluding credible players is a laugher. It's one of those, 'a house divided against itself can't stand' kind of situations.
The fact that this would happen is a tragedy for the customers, because there are real issues of interoperability around Web services. There is potential for doing something useful and that would be an important thing we would be glad to participate in, but our view is it's prima facie not what somebody's trying to do if they build the organization with grotesque looking biases in it from the get-go.
The current discussions around trying to get this organization out of the morass it's built itself into by starting this way, well, maybe they'll result in something successful that meets the test of genuine interoperability.
But it would be better if it weren't like this. You detect in me a certain amount of frustration at what's been a really artless exercise. I mean, we would have a lot more respect for this if we hadn't felt the knife going in. This was just so ham-handed.
Let's turn to the Linux question. As we understand it, you're going to announce the Big Bear server in August. Where will this Intel-based box running Linux fit into Sun's product line?
Earlier I was talking about Web services and this issue of thinking about systems architectures in terms of the ISO networking model, well at Sun we're beginning to think about systems structures as being defined in terms of these protocol stacks and not in terms of instruction sets and operating systems, which, although they're still essential components, are much more commoditized than they were in the prenetworked world.
One of the things that's interesting about the emergence of a technology like Web services is we're beginning, as an industry, to talk about systems that transcend specific computers and that live on top of the network in the form of protocol architectures.
We used to say our one binary architecture was SPARC and Solaris. What we tend to say now is our binary architecture is JVM and IP-based networking. And when we say that, we're thinking about the ability to use commodity parts in the building of our products.
So yes, we're building things out of Linux, we'll build things out of other microprocessors, but those things won't define the products. The things that will define what those products do will be the functions they provide in a networking context, like content switchers or load balancers or application servers, or things like that.
Indeed, we have been making Intel architecture-based products for a while now. The Cobalt acquisition was some time ago. And in part that was done to advance this appliance model of things which, although it starts on the low end, actually becomes pervasive throughout the product lines.
So the value you add is in the services?
Right. We have a great asset in our Unix group in the form of what's been accomplished with Solaris. But Solaris is a little isolated from the rest of the modern Unix community, and that's really a piece of residue from the Unix wars of a decade ago where everyone got balkanized. What everyone forgets is that before the Unix wars everybody traded stuff all the time.
You'll see us reintegrating Solaris technologies with the community development environment where that's valuable. And where it's not, we'll surf on the energy of the community. I mean, everyone forgets that for years we mostly absorbed the BSD releases. It was only when we were getting more prolific than BSD that we ended up living on our own space. And that was more a tactic than a strategy.
You once said one of your personal agendas is to make Solaris open source. Are you getting anywhere?
Well, I'm certainly not done. I want to open source it primarily because if you look at where Linux is today, it's hampered in terms of scalability. And we spent millions of dollars and thousands of lives back at the beginning of the '90s doing all that stuff. Other people don't have to throw themselves against that wall. We should just go, 'Look, this is how you do it, take the code, if you don't like exactly the way we did it, screw with it and make it the way you like it.' But the point is it's not actually differentiating to hold onto those differences.
The real differentiation for Sun was the capacity for creating those differences. And in that sense, particularly relative to the OS technology, we have a somewhat different view than other institutions. Having made it first is useful, having it uniquely turns out to not be all that useful.
So why don't we make sure it's widely disseminated and then go off and create the next big thing.
While I'm quoting things you've said, can you comment on this quote from a Sun JavaOne article: "Network technologies of the past were designed to hide the problems of the network, shield the programmer from network performance issues. We've got to stop doing that."
For most of the last 30 to 40 years we've been trying to make the network look transparent to programmers. So the purpose of things like remote procedure calls was to make a remote resource look like a local resource. And in fact, that's very effective for anywhere up to a couple of thousand systems on a LAN.
The notion doesn't quite work on a WAN and, indeed, you discover that distributed computing is built on assumptions that are pretty false. We had a guy working at Sun by the name of Peter Deutsch who made a list of these things he called The Eight Fallacies of Distributed Computing.
This set includes things like, the topology doesn't change, bandwidth is infinite, latency is zero, it's secure, there's an administrator, etc. And when you look at them coldly you go, 'Well that's a goofy set of assumptions to make.'
This notion of transparency works relatively well on modest scales, but when you start thinking about systems built of tens of thousands, if not millions, of parts - which is something that isn't that far-fetched in the near future - all the things we put in to make the network look transparent to programmers are going to stop being our friends.
The trouble with these transparencies is that they make whatever failures that do occur very hard to find. So systems that confront the fallacies of networking are going to prove to be interesting. And one of our entrances in that is the Jini project, which is a system that's basically organized entirely around confronting each of those fallacies. It doesn't assume the network's going to stay there. It doesn't assume that latency is zero or that bandwidth is infinite. And instead, it makes you deal with it front and center as a first-class property of the environment.
Where does the Jini effort stand?
Well, this is a project that's been running at something of an experimental level. It's a novel approach to building a system, and as such it has confronted a lot of our design intuitions. So given we've got 40 years of habit around, we're essentially having to restart. And so that's being done with the Jini group inside, and it's being done with our professional services organization who are working with customers that have network problems that exhibit the fallacies of computing pretty readily.
At the risk of giving a tragic example, the military complex is interested in Jini because in battlefields of the future soldiers are basically sensors that are part of a network. They're radiating and absorbing information. And sadly, that's an environment where elements of the network appear and disappear as casualties occur and forces get merged and so forth.
Battlefield command and control is really this dynamic networking problem that has elements appear and disappear and segment and partition and then unpartition later, such that you have to reintegrate a bunch of things. Some businesses have these same problems, it's just the military's been more public about it.
So we're busy exploring that space, and the Jini project is sort of several things rolled into one. It's this technological experience, it's a sociological experiment in terms of how you put together a development that involves other parties, particularly people who might not be like yourself in some way.
And it's actually having quite a bit of success. The unfortunate thing is when we introduced it, we hoped for and talked about Jini being successful in one particular domain - dealing with the administrator fallacy, and in particular dealing with the idea that there's any administrator at all - and this idea that devices would somehow discover each other and form systems and so forth.
As it's played out, that's not really what's happened. Instead of Jini being the exoskeleton of a system in which elements of a system found each other, Jini is actually getting used as the endoskeleton of an application. People are creating systems that don't externally reveal their Jini-ness, but internally use that as a way of creating themselves. Where we're now applying Jini in the form of management systems for future networking-based computer architectures.
It's unfortunate that we told everybody to look west, and it turns out the hoard of successes is coming over the eastern horizon instead. But that's sort of the way it works. I mean, look at Lewis and Clark. If you knew what was out there, why would you send them? So we sent them in order to learn what we would find.
Speaking of projects, how about an update on N1? What should enterprise users know about this?
N1 is our future computer architecture. In some ways, I'm a little dismayed that we've talked about it so much, because it's mostly the list of instructions we're giving ourselves about how we're going to build our products of the future. I mean, we've always had a series of internal architecture manuals that describe how we built our workstations, how we built our servers, what their architectural premises and so forth were. And really N1 is at some level a replacement for those things for the network era.
Sun started out as a company integrating [very large-scale integration] and operating systems and so forth. And while we still do those things autonomically, our conscious efforts really relate to creating integrated systems out of things that tend to have IP addresses, whether they are storage elements or processing elements or whatever.
A lot of this has to do with retargeting a lot of our system capabilities. I mean, Sun can make microprocessors and ASICs and operating systems and network technologies, and can - given the premise that IP networking is pervasive - apply all those things in ways that hardly any other computer company can to create different systems.
Most computer companies are busy approaching this level of integration by growing big services staffs. We also have services, but we view them more as a kind of scouting party for the systems products that we think we will build. Then tend to produce an out-of-the-box experience for the future that's comparable to what people have in a prenetworking way.
So N1 shouldn't really be that visible to our customers. What's visible to customers is N1 exploits the fact that programs are becoming graph-structured things in the sense that they are a bunch of elements that are connected with different network connections, even if they live in a single box.
So for instance, if you think about this from a networking standpoint, 15 years ago we were doing client server computing with Sun RPC and XDR. In the early '90s we got to three-tier environments with CORBA and the introduction of object technologies. And Java [Platform] Enterprise Edition is really a codification of a basically five-layer model that has databases and application servers and Web servers and gateway functions and client access devices. And Web services involves taking sets of those architectures and allowing them to conspire to produce a particular client result.
There's been this progression of application decomposition from a monolith to a pair that was split with client/server to now a set that's split with Web applications and a larger set with Web services. And what that effectively means is that programs are getting this structure whereby they have components that are visible to the underlying system. And that proves to be really interesting because now you can imagine systems beginning to understand applications in a way that they couldn't understand when all they saw was an executable.
Now we can see the structure of an application and we can monitor its behavior dynamically, and we can begin to think about, well, how would we manage real quality-of-service mechanisms in the system once we can predict what the application - let's say something in the accounting department - is doing? Well, an administrator could say to the enterprise at the end of a quarter: Give finance priority so it can close the books and we can announce our results. And the distributed network resources could be driven to accomplish that, giving the administrator the same sort of control over the network that they used to have over a single box.
And in the end that's what customers really value, the ability to hide a complex networked world behind a series of abstractions that are more simple than what they are able to do today. Today we have people that know a bunch of internal systems variables and they know if they tweak these things this way that tends to produce this result, and in the end it's actually kind of a voodoo thing. The trouble is, voodoo doesn't scale. You have to have real science to make something that's relatively sophisticated work. So that's really what that project is about.
Any final thoughts? The next big thing?
Personally, I'm most interested in seeing the network grow by having things which neither are computers nor embed computers getting attached to the network - the whole sensor revolution.
That's relevant to enterprise customers because to the extent that enterprises use people and data entry as a form of sensor, this is going to transform the enterprise computing environment, although the life-changing benefits are going to come out of things like medical sensors and things like that.
We know of a heart monitor vest that unites the ability to monitor the state of your health with GPS and wireless communications so it can tell you to sit down, we've called the paramedics, you're about to have a cardiac event. But the underlying promises of that will benefit classical businesses as well, by reforming the sort of sensory things that they administer with people now.
I guess the other thing more near term to enterprises is Web services, as we've discussed. There is something really important there, but there's also a lot of science fiction about it.
When Web services were first introduced, there was this notion of millions of computers discovering each other and figuring out how to do business so we could all be on the golf course by 11, and that's just not going to happen.
First of all, most business environments are relatively simple systems. Look at even complex businesses and their underlying fundamental business processes turn out to be relatively simple.
Where they get exciting is that they do so many of them per unit time, and it's the volume that does it to you, which, of course, makes it a perfect application for something like a computer. But it isn't actually that architecturally complex, and these systems are not going to do the all-singing, all-dancing stuff. But they will do some interesting stuff, so people ought to believe that there's something happening there that's important, but you should just have modest ambitions.
Sun breaking news
Stay on top of the latest product, development, business and financial news.
Customers advise Sun
Users say lower prices, a quick exit from the storage market and more R&D are steps in the right direction.
Network World, 07/08/02.