For most of us, the autonomic functions of the human body save us a lot of grief and, ideally, allow us time to pursue higher activities. Our hearts beat by themselves without constant management and weekly meetings; we needn't remind ourselves to sweat when it's hot; our heart rates catch up when we hurry; our eyes eventually adjust themselves to morning (although at times it may seem we will them to do so); our antibodies antibody all day long without our giving a thought to them; and, except for those of us who look at computer screens the entire day, we don't have to constantly remind ourselves to moisten our eyes by blinking. And when something goes wrong -- I cut myself slightly, for example -- I can't justify a sick day on the grounds that I had to attend to the coagulating of my blood.
If you pause for a moment and imagine they didn't do all this themselves, you'd pretty much have the current state of computing: Sys admins spend more time making sure the system is "up" than on improving it. The traditional roles have been reversed and the human being ends up providing life support to the machine, which is always threatening to go into a coma if not painstakingly (and expensively) monitored.
Work currently underway at IBM suggests it doesn't have to be this way. Under the leadership of Robert Morris, vice president of personal systems and storage and director of IBM's Almaden Research Lab, IBM is putting forth the concept of autonomic computing.
As IBM puts it, "Increasing processor might, storage capacity, and network connectivity must report to some kind of systemic authority if we expect to take advantage of its potential. The human body's self-regulating nervous system presents an excellent model for creating the next generation of computing."
Morris argues for a collaborative, open source, effort. If we don't work together to allow autonomous (private, not proprietary) systems to work in conjunction, then we will waste our most creative energies by focusing on the details of problems that, with a little cooperation, would have been automated and rendered nonexistent some time ago. This waste of energy will prevent us from realizing truly complex systems, as complex as the human body, which in IBM's vision, are the future of computing.
To learn more about autonomic computing, O'Reilly editor Jim Sumser talked to Dr. Morris. Morris will also be speaking at O'Reilly's Emerging Technology Conference in Santa Clara, Calif., on May 14.
Jim Sumser: What is autonomic computing?
Robert Morris: Autonomic computing is a comprehensive and holistic approach that should result in a huge improvement in the cost, availability and experience in terms of how people relate to information technology. It's motivated by an analogy to the human body, that most of the things in our own bodies are taken care of automatically for us. We don't have to worry about the management of internal functions within our body. They regulate themselves. And we would like our systems to regulate themselves in the same way.
Sumser:There are already examples of some of this now, like load balancing and error checking and intrusion detection.
Morris: The one thing to observe is that, in fact, this is not a new idea. This kind of technology actually has been used in component form for quite a number of years. A good example would be RAID, which allows a storage system to have a disk drive fail and it just keeps running nicely; it basically works around and heals the failure of that disk drive.
Dr. Robert Morris is Vice President of Personal Systems and Storage and Director of the Almaden Research Center for IBM. He discussed Autonomic Computing: A Foundation for Progress, a Catalyst for Change at the 2002 O'Reilly Emerging Technology Conference in Santa Clara, Calif.
But it's more than the instances we've seen so far. Autonomic computing is about the collective behavior of systems and having systems work together to give an overall autonomic-computing functionality. We're saying, we've made great strides on a component level, like an individual storage system or an individual server.
These systems are beginning to behave quite nicely together. And now we're trying to move to the next level, where the overall systems begin to work together effectively. As a result of that, they end up working to fulfill the overall goals of the system as opposed to the more local goals of the individual components of a system.
It's a holistic, system-wide perspective. And very importantly, it's a goals- and policy-oriented approach. So rather than having to tell systems what to do explicitly in the face of a certain situation, like a failure or an increase in load, we just tell these systems what we're trying to accomplish. For example, let's say we want to achieve a maximum of a quarter of a second response time. You, system, go and figure out how to do it. Systems need to work together with their neighbors and with their subsystems in order to achieve the results.
Sumser: And with their neighbors you mean, for example, other companies and ...
Morris: Other systems and the subsystem. It could be actually a system that's spread across the network. In this emerging world of Web services some of the subservices may even be provided by different companies, but an autonomic computing version of that Web service would make sure they all work together to get the job done.
Sumser: How has the industry responded to IBM's proposal?
Morris: It's been very positive. By the way, our appeal is to industry, to government and government research labs, and also to academia. The response from all three has been very positive. Some companies and universities are seeing a lot of overlap between what we're saying and what they've been working on and they're saying, "We'd like to recast our ideas and our approaches within the concept of autonomic computing." And they're doing that.
So we're seeing other companies now saying, yes, you're right, we agree wholeheartedly and we want to work together with you to do that. In the case of government labs we found very interesting overlap in terms of some of the things they're doing. And in academia we've found overlap and also a commonness of purpose, as well.
Sumser: I could see academia and the government being interested in collaborative computing, but then there are other companies I think that may not be so interested in it.
Morris: Well, I tell you I haven't met anyone from another company who is not interested. They all recognize it and they also recognize that they can't do it alone. They recognize that in the customers that they work with, they may supply some part of a system, but there are always other vendors in there as well supplying systems. And they realize that unless we work together, all of our customers are going to fail. We certainly recognize this in IBM.
We have a lab services organization called IBM Global Services, which manages many information technology operations, and of course they manage a lot of non-IBM equipment. So they would like people from the companies providing that equipment to participate and for everyone to get together. And this isn't just everybody singing the same tune, this is people actually working together to define protocols and interfaces and management technology in order to make the systems work together to get the job done. And we're beginning to see people come together to do it.
Sumser: So that's why you encourage an open source approach to it?
Morris: Particularly we're encouraging a very open interface. We're going to be publishing all of our interfaces and we're going to be publishing protocols between the interfaces. But we'll also put out interfaces to our systems and we'll suggest that other people are free to use similar interfaces.
Sumser: "Are free to ..." There's no cost attached?
Morris: Absolutely not, no. An example is Storage Tank, which is again focused on one part of the industry. We have a new approach to soft-managing storage, because in the end the amount that's spent on the raw storage, namely the disk drive, is a very small proportion of total storage costs, because of the complexity of management of storage. So our approach to doing that from a technological perspective is to create a structure called Storage Tank, which has a piece of client code on each of the servers, if you'd like, that participate in their storage, and also a metadata controller.
Well, we're going to be open-sourcing the clients and defining the protocols. So anyone who wants to use that client and port our client can do that. Anyone who wants to build systems around those protocols can also do that.
Sumser: When you spoke at Stanford (in November 2001) on this topic some people in the audience had some moral questions about doing this, creating something that we couldn't control, and so forth, like a Frankenstein. It does seem to me when I was reading the information on the IBM Web site that there was an effort made to distinguish autonomic computing from artificial intelligence, though at times it seemed to me that it was very close to artificial intelligence.
Morris: You know, there's really no chance of us getting a Frankenstein out of this. What we're trying to do is, to a certain extent, quite well understood within systems theory and systems technology. I explained how well we've been able to do it at the component level. What we're trying to do now is extend that to the system level and to the declarative level.
Our stuff is very real, it's very down-to-earth, and we're doing very basic, in some sense, well-understood things. We're not doing things that have really never been done before, but we're doing them within the breadth of a systems approach, and we're also doing it in a heterogeneous manner. So it's a linkage between heterogeneous systems, each of the same type.
You could have a variety of servers from different vendors. We going to try to work to ensure that those different servers work together, so that's kind of horizontal heterogeneity. There's also vertical heterogeneity, where you have systems at different levels of the IT layer cake. And so the storage systems are going to work much better with the database systems. The database systems are going to work much better with the middleware systems. The middleware systems are going to work much better with the application. And finally the application is going to serve its owner, which is the institution, or the people that own the system, in a better way.
And if you look at the kinds of things we're doing there's really no way that we could get a Frankenstein out of it. All we can get is better performance, better availability, and a better user experience out of this.
Sumser: It's a question I know that people always talk about when they ...
Morris: Well, if we had a different set of goals, if were going to use these systems to just basically learn and self-replicate and reproduce and give them walking capability and weapons and have them go off and solve unstated problems in the world, maybe we would. But we're not trying to do that. We're trying to meet some fairly traditional goals in information technology: to lower cost, to increase value, to improve availability, and to improve user experience via automation. So we're not trying to do any science fiction things.
Sumser: Well, but the systems are adaptive though?
Morris: They are adaptive. Yes, they are adaptive. Remember I was talking before about goals and policies. So think of goals as the goals in an organization that you're trying to accomplish, and then the policy is constraints. This is where you begin to get control and begin to avoid any of the problems that you might be thinking about. So they are adaptive, but they must, for example, obey certain types of security constraints.
You have a better shot at security if the constraints are explicitly stated and any algorithm is required to obey those security constraints, than if you are writing a procedure and are trying to think about the security constraints as you write. We're going to test all our schemes against the constraints before we take any action. So for example, if an adaptive system was to decide to do something which would border on insecurity, because of a bug, for example, our constraints or our policies would not allow it to do that.
Sumser: In [IBM Research Director] Paul Horn's talk he said that the system would be able to handle unpredictable events. So I was just wondering how you would constrain a system from ... I mean, if it could handle an event that we can't predict or we didn't predict, then it is making decisions on its own.
Morris: In general in the concept of system management you have a current state and you have a final state. And you want to adapt your system to get from the current state to the final desirable state via a path, setting a set of actions which drives you through to get from the initial to the final state. OK, if you state your constraints, it doesn't matter what the initial state is. If you state your constraints, and as far as you're concerned safety corresponds to the adherence of those constraints, then you can deal ... for example there may exist no path which gets you there, OK?
In which case you'll report that there is no feasible path to solve the problem. However, you won't go outside those constraints. So the particular state that you start with, whether it's been predicted or not predicted, shouldn't be a problem.
Sumser: OK, that makes sense.
Morris: But you're absolutely correct. It is important to make a set of constraints. Of course these constraints are usually very down-to-earth things. If a peer system asks for help, either in processing or storage, then other systems should try to help. However, they shouldn't give up so many of their own resources that they can't do their own job. This is very analogous to the kinds of things that we ask people to do in society. We ask people to help their neighbors, but not share so much that it threatens their own personal security. So we're also using some of those societal analogies in order to construct some of our systems.
Sumser: And where would selfishness come in?
Morris: In fact, there's a traditional method of thinking within economics and in game theory, which is you should try to construct systems in a way that when an individual, when a system optimizes an individual goal, in other words to make the goals that it's trying to accomplish, that should move toward a societal goal. So if you construct the goals correctly for an individual in an organization -- this is the brilliance of organizations -- when organizations put goals in place for their individuals, if those individuals work toward those goals, then the overall organization moves toward a collective goal that's desirable.
Jim Sumser is an editor in O'Reilly's networking group.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.