[240] in DCNS Development
[Jeffrey I. Schiller: Requirements for a New Athena Architecture]
daemon@ATHENA.MIT.EDU (jon@MIT.EDU)
Wed Sep 2 13:31:55 1992
From: jon@MIT.EDU
To: developers@MIT.EDU
Date: Wed, 02 Sep 92 13:29:15 BST
------- Forwarded Message
Date: Mon, 24 Aug 92 23:50:38 -0400
Message-Id: <9208250350.AA28846@big-screw>
From: Jeffrey I. Schiller <jis@MIT.EDU>
Sender: jis@MIT.EDU
To: dcns@MIT.EDU, acs@MIT.EDU, css@MIT.EDU, isdir@MIT.EDU,
cluster-managers@MIT.EDU, trb@MIT.EDU
Subject: Requirements for a New Athena Architecture
One of the action items on the agenda of the DCNS Technical Review
Board (TRB) for the last several months has been a review of the
overall Athena technical architecture in light of changing technology
and customer requirements. Since the release has been finished, the
TRB has begun work on this item.
We believe that the technical architecture should not be driven solely
by technology, but should respond to the needs of our customers, the
faculty and staff of the Institute. To this end, the first goal the
team set for itself was to produce a "requirements document" that sets
out requirements for a new (or modified) Athena architecture. When
complete such a document, incorporating both technology and customer
requirements, will serve as our guide in the development of the new
technical architecture.
As the first step in the development of the requirements document the
team members collaborated over a period of several weeks to produce a
strawhorse document. (Special thanks to Mark Rosenstein for putting
our rough thoughts into elegant prose.) At this stage the document
reflects only the collective views of the members of the TRB. To be
useful however the requirements document must ultimately reflect the
common and agreed upon views and vision of the entire Academic
Computing community of Information Systems as well as our customers.
Therefore, over the next several weeks we want to use this strawhorse
document to stimulate some discussion, both inside and outside IS. We
would like to hear your comments, ideas, and feedback on the document.
What did you like? What's missing or needs to be changed? Are we off
track? We request that input and discussion of this document occur on
the "naa@mit.edu" mailing list. [Note: Mailing list may not exist
until Wednesday August 26th] "naa" is public, feel free to add yourself
to it.
Once we've collected your feedback we will produce a new version of
the document which will be brought to the Athena Requirements Team for
review and action.
-Jeff
Begin Enclosure:
What are the requirements for
a new Athena Architecture?
The Technical Review Board is embarking on an effort to re-evaluate the
basic Athena workstation architecture. Given ten years worth of
knowledge gained and changes in the technology, we may want to change a
few things. Two questions are paramount to this process: what is meant
by Athena architecture, and what do we hope to accomplish.
A vision for our current effort is that ``Athena should be the de-facto
computing and information infrastructure at MIT.'' Core elements of
that vision are ubiquity, availability of Athena to all users (i.e.,
measured in several dimensions, from financial resources to computer
expertise), and service infrastructure. If we are to possibly modify
the basic architecture of Athena, we must first define the requirements
of this architecture.
1. MIT Customer Focus
It is unlikely that many people in the MIT community wake up in the
morning, and say ``Gee, today what I'd really like is a better
distributed computing environment at MIT because that would make doing
this problem set/preparing this lecture/doing my job/doing research a
whole lot easier.''
Instead what we have is literally thousands of students, faculty
members, administrators, researchers and lots of other folks who want to
use computing in support of their daily activities. These (and some of
them in various combinations of these roles) are the customers for
Athena.
It's worth noting that many of these customers have been engaged in
doing lots of things in a particular way for a long time, sometimes
measured in decades, not just years. Some classes have been taught the
same way for many years. Some administrative systems have their roots
in the 1970s (some would argue before). We must be careful to not
succumb to the inertia created by the mere existence of an older, albeit
proven, way of doing something. Some of these will rightly fall within
the domain of our work, but we should be careful not to assume that a
computer-based solution will always make it better, cheaper, faster or
more effective.
1.1 Market-Driven
Before we do anything, we need to know what this diverse set of
customers like, what they use today, very importantly what they hate
about what they have now. In short, what we do must be market-driven.
In order for this to be successful in the ``MIT market,'' the new Athena
must be perceived by the customers as adding significant value relative
to the cost of participation. To do anything less would invite disaster
in a business sense, even though technically, the result might be very
interesting and unique.
1.2 The Hidden Challenge
One of the significant challenges in defining the new Athena for the
1990's will be the identification of an expanded set of customers, and
the information resources that they need to work each and every day. In
addition to the traditional customers of Athena, we must encompass
previously disenfranchised individuals, work groups, administrative
departments, research laboratories, MIT alumni, MIT guests and visitors,
and probably more.
It is becoming increasingly clear that the 1990s will witness an
explosion in information that will make many of us yearn for the good
old days of the 1980's. These gigabytes and terabytes of information
will be the progeny of countless new information providers, who
themselves will come in many different guises, from the plugged-in
researcher putting out the latest lab results on the net through perhaps
some form of community repository specifically designed to maximum
information sharing, to the more formal collection-oriented efforts of
groups like the MIT Libraries and a host of commercial third-party
information providers.
Our goal is to define an all encompassing computing architecture for MIT
such that every day, just about anyone on campus who is using computing
services of any kind will come in contact with Athena. The new
architecture of course will permit individuals, work groups, departments
or whatever to opt out of participation in Athena, but our goal to
define such a value-added architecture that no one in their right mind
would want to be a non-participant. However, the new Athena will not be
a monolithic system that does not permit a significant level of choice
for each and every customer. Customers should be able to pick and
choose their level of service at any given time, and change it as freely
as they would like, within the normal constraints of their business and
ours.
1.3 Customer Steers
One option that must always exist is for the customer to cede control
completely to one or more centrally managed computing organizations who
will, under contract, provide them with all of the computing services
that they desire. If the customer chooses, their computing can be
tightly coupled with centrally provided services.
But just as importantly as it is to allow the customer to yield
responsibility, it is equally important that Athena permit the
sophisticated, knowledgeable and adventurous customer to retain control
and responsibility for their systems, and to tailor one or more of them
in highly idiosyncratic ways, selecting from a menu of options, if you
will, of various services for which Athena chooses to provide
architectural support. From afar, this might end up making MIT looking
like a federation of fairly independent domains, loosely coupled with a
central hub, all running what looks like pretty different kinds of
systems, but all based on a core number of architectural foundations.
Some customers will be interested in using one or more Athena services
on centrally owned, publicly provided resources. For these customers,
the system should above all be helpful, friendly and fun to use.
Many work groups will be interested in running their own collections of
machines, tailored in a manner that suits the group's mission. For
these customers, making the system look and behave the way they would
like should be helpful, friendly and above all, FUN!.
2. Hardware/Software Trends
The MIT community is a diverse community with diverse needs. The Athena
system needs to recognize this diversity and support the hardware and
software needs of a wide range of users.
2.1 Software
System architecture should not preclude end-user customizations of their
workstations. End users should be able to select which software and
hardware products they personally wish to use. End users should also be
able to decide when they wish to upgrade to the latest Athena release
and/or be able to pick and chooses pieces of a newer release. It may not
always be practical to expect the system, as a whole, to work if end
users select only pieces ``at random.'' However we probably should be
flexible by making our releases more like industry releases.
Specifically we should announce a date at which a new release is
available. End users should be able to decide when they wish to upgrade.
Instead of supporting only one release, we should support the current
release and the previous release for some period of time.
As new software is available to the industry, that software should be
made available to the Athena community if at all possible. End users
should be able to purchase software (or perhaps the right to use
software that is maintained centrally, but not generally available) and
be able to use it in the Athena environment.
The Athena architecture should shield the end users as much as possible
from the inner workings of the system (that they don't need to worry
about). For example today the end users do not need to concern
themselves with the nuances of Kerberos in order to login, they just
enter their name and password.
Services should interact as much as feasible with existing,
``non-Athena'' services. Software developed to industry standards
should operate in the Athena environment. Similarly software developed
in the Athena environment should be able to be exportable to other
sites, some of which may not operate the Athena environment.
The Athena environment should not require a particular hardware
platform. Although it may not be possible to use all services of the
Athena environment on low end systems, basic (BEST) services should be
available on as broad a range of systems as possible, including the low
end. The Athena environment should be compatible with high end research
systems. It should not only run on these systems, but should not
interfere with the high end application that the user originally
purchased the high end system for (i.e. it shouldn't cause the high end
system to perform at a lower then normal performance level).
2.2 Hardware
Hardware vendors are not standing still. As new hardware becomes
available, the Athena system should be able to run on it. This implies
either a continuing development effort to keep Athena up to date, or
that the Athena architecture be general enough to accommodate change.
Perhaps a little of both will ultimately be necessary.
A particularly important trend we should watch for is how the various
computing components compare against each other on a cost basis. For
example years ago disks were very expensive. This encouraged vendors to
design software to reduce the number of disks that customers needed to
buy (example: Sun's NFS). However today disks are cheap enough that it
is much more expensive to spend programmer time to write an application
to minimize disk space usage rather then simply buying more disk.
As mentioned immediately above, we need to pay careful attention to the
economies of the components of computing. The existing Athena
architecture was designed back in the days when disk drives were
expensive and diskless workstations were the rage. The new Athena
architecture should address the realities of today's hardware with an
eye toward tomorrow.
The Athena environment should accommodate access to alternative
computing resources including those which are not necessary tightly
coupled with the environment or otherwise not completely integrated.
The Athena environment should embrace the hardware/software that is
affordable and desirable to the community. Students are buying
computers now for their dorm rooms, and these are platforms we must
support if we want the support of the students.
3. Well Engineered
An important part of satisfying MIT's needs is to build a well
engineered system. Athena must be a robust, secure, scalable system
that follows the right industry standards in an evolving world.
3.1 Leadership
The development of the Athena environment has placed us in the
leadership role within industry. Several other institutions have
adopted the Athena environment and DEC is selling it commercially as
DECAthena.
Having established a leadership position, we should endeavor to continue
our leadership by evolving our services to meet the challenges of the
future. By solving problems which plague the outside world as well as
our local environment, we should be able to maintain this leadership
position, as befits an organization that is part of MIT.
Not only should we be viewed as leaders to the outside world, we should
be leaders within MIT when it comes to the use of computing. By
providing a competent computing environment (both from a technical and
service perspective) we should be able to keep the respect of the MIT
community as we evolve the Athena system.
3.2 Reliability
The services that Athena provides to its customers should be reliable;
any significant change in functionality or user interface should be made
known to the customers in advance and be well documented. Additionally,
the Athena system should not become so complex that it becomes
unreliable or difficult to maintain.
3.3 Security
Athena has spent considerable effort in building a client-server
computing environment which is fundamentally secure, relying on
Kerberos, open design and implementation rather than trust or obscurity.
This should set the minimal standard for the future. New systems
should build on this foundation, possibly going farther by use of public
key technology and smart cards. It is important that the system be able
to support very secure administrative applications, but not be so
cumbersome and expensive that building less sensitive applications
doesn't make sense. Not all levels of security should be required of
all services and applications.
Additional areas to consider addressing (if possible) are areas where
Athena has security weaknesses. For example, security of the
end-workstation (trojan horses, AFS cache, etc.). As we tighten
security we must weigh the tradeoffs between auditing and privacy. When
we are concerned with trying to find people who abuse the system, we
institute auditing procedures. We should have an explicit statement on
electronic privacy to see that these procedures are reasonable.
3.4 Scale
The new architecture should be designed to work at the scale of the
entire MIT community. The current Athena architecture (and
implementation) is showing signs of strain for 1000 machines and 12,000
active users. If the system is going to become a viable candidate for
an MIT-wide distributed computing environment, it should be prepared to
support as a user every person in the MIT community, possibly Draper,
Lincoln, and alumni users as well. A safe assumption would be that each
user will have one computer at work and one at home, so the system
should be prepared to deal with 30,000 machines though perhaps not all
active at the same time.
3.5 Standards
We must follow some standards, but which ones? There are many standards
in the computing industry today; some stable, some evolving, some
conflicting.
Athena's past successes have helped produce some of these standards.
While we should not gratuitously change them, we should not be afraid to
turn out backs to some of these standards if our experience tells us it
is time to move on.
Due to the number of evolving and conflicting standards, it is not
possible to understand them all, much less support them. The ones worth
following are those that allow us to import third party software, those
that allow our developers and faculty to export their work, and those
that make our job easier. We should resist the temptation to follow a
standard which does not help us just because it is a standard.
4. The MIT Campus
There are also requirements based on the realities of the MIT campus:
providing public clusters and supporting remote clusters not on the main
campus.
4.1 Maintaining Public Clusters
Software and hardware maintenance for public workstations must be
accomplished with a minimum amount of staff resources.
As the price of workstations continues to decrease we have the ability
to increase the number of public clients. We must not only allocate
money for the purchase of new workstations, but we must also allocate
resources to ensure that the clients can be maintained with relative
ease and minimum expertise.
It is important that public clients are not deployed without considering
the ``over-head'' cost in maintaining the clients. We don't want to get
too carried away with deployment, forgetting that resources are needed
for hardware and software support.
Public clients will continue to be deployed in a
geographically-distributed manner. These clients will require on-site
hardware and software maintenance and monitoring by staff to ensure
proper operation.
4.2 Cost Effective
Designing and building a system of such scope and sophistication will
not come cheap. Yet it is no secret that there are precious few major
pockets of dollars left to do this sort of thing.
The cost of migrating to the new architecture must not require more than
Fiscal Year 1993 allocations in terms of monetary cost or human
resources. The migration to a new architecture should not create unduly
high costs for those customers already participating in the Athena
environment.
Athena should be cost effective for Information Systems and for its
customers. To participate in the Athena environment should not require
expensive hardware or too many human resources. The installation of
Athena software and participation in the environment should require
little effort. The system should be easy to configure and require
little effort to maintain.
Will the customer pay? There is some evidence that as time goes by,
more and more organizations are taking into consideration the real costs
of information technology during grant writing, and during annual budget
proposal writing. The cost of networks and maintenance of software like
the current Athena suite are being picked up by an increasing (albeit
slowly) number of departments across the MIT landscape. Witness the
recent agreements with the Living Groups in which a cost-sharing model
was acceptable that allowed five living groups to keep mini-clusters
available for their residents. Innovation of this kind must continue if
MIT is to be able to continue to innovate technologically in a
financially more frugal world.
4.3 Bandwidth, Location, Mobility
The MIT community is very mobile. To meet the computing needs of this
group, it is necessary that significant parts of the environment be
available from a wide variety of locations. It must be usable off
campus, and users on campus should not be tied down to one specific
location.
Being able to do this implies that the architecture must be able to
provide a basic level of service through a variety of communication
channels, from dialup to network speeds. Clients who only connect up as
necessary to the services provided over the network should also be taken
into account, as appropriate and feasible.
While the interfaces to these services may not be the same via these
different means, the same functionality should be present as much as
possible.
5 Conclusion
Whatever is decided, designed and built, the result must be simple.
Complexity will kill the system. We are left with the as yet unanswered
question of whether a system that hopes to serve as many diverse
customers, for so many diverse needs, can successfully resist complexity.
All users will want it infinitely tailorable, equally and easily
approachable by the most novice end-user, or non-technical local system
manager, to a sophisticated systems designers, systems programmer or
operations staff, whether these be in centrally provided or
departmentally provided settings.
The challenge of the task is clearly ahead of us. Our fate rests in our
hands of a wonderfully diverse set of customers who we depend on much
more than they depend on us.
- ----- END OF DOCUMENT -----
------- End of Forwarded Message
