Advertisement

Highly Available Services

Frank Sommers: As people increasingly depend on the network-provided services, we will have less tolerance when these services are unavailable. Considering our experience with the reliability of existing computer software, do you think we are ready to place increasing trust in our networks?

Jim Waldo: I sometimes talk these days about the environment we have led computer users to expect. We have conditioned them to expect unreliable computers that are fragile and break easily. They have grown used to their computers crashing.

As we start moving computation into a more embedded system, people won't see the thing that contains a computer as a computer. They will see it as a telephone, a refrigerator, or a television set. We don't expect those things to be fragile or to crash, or that they are complicated pieces of equipment that we can't rely on. As software people, we will have the same level of expectation placed on our product that is placed on many other products. Consumers will require reliable products. To make them reliable, we must make them smaller, simpler, and able to interact with other small and simple components. Then we have to make sure the whole thing works together, which will require the kind of network service architecture that Jini is about.

Jini is about little components offering simple services that can be knit together as needed to provide complex services. These little components, and their interaction, can be reliable. And if one crashes, you can easily find an equivalent service on the network to replace it. That's the key to reliability.

Frank Sommers: Do you mean redundancy and replication for services?

Jim Waldo: Absolutely. Redundancy and replication are the only ways to make reliable systems out of unreliable parts. At least, they're the only way we know. We have to apply those techniques in software, as well. We apply them in hardware sometimes, but not very well in software. In software, we've made larger and larger things so that any small errors somewhere in your big program can crash the whole thing. We should, and will soon, consider that unacceptable.

Frank Sommers: Currently, when you talk about redundancy, typically, a high expense is associated with that. If you want to get your database management system up in a redundant fashion, you typically need additional licenses, which quickly becomes expensive.

Jim Waldo: The expense of these redundant systems is often dictated by the scale of the thing that is made redundant. If you have a large and complicated database, running on expensive hardware, and you want to make that redundant, it's very expensive, because you have to buy a second, very large piece of software, running on a second, very large piece of hardware.

But you can get a cheaper level of redundancy and replication by making small components redundant. That doesn't add a lot of expense, because the thing that is redundant and replicated is small and simple. There are already a lot of small, redundant components in airplanes, automobiles, and other mechanical devices. We could do the same thing in software components.

Frank Sommers: That will be bad news for a lot of software vendors, because they tend to have high revenues typically coming from enterprises willing to pay large amounts in return for high availability. Are you talking about the commoditization of high availability?

Jim Waldo: Making things small and simple doesn't necessarily make them commodities. There are small and simple things that do one thing very well. I hope, in fact, this will open up the software market so that you don't have to compete by doing everything better than anybody else. You can compete by doing one small thing.