Infrastructure Design Philosophy

Establishing and maintaining a successful academic computing research lab requires a different infrastructure design than those used for industrial computing research labs or academic computing teaching labs. The approach that has worked for us is an agile approach best described as managed chaos. Our infrastructure design prioritizes:

• interests of lab personnel
• flexible use of lab resources sufficient to support a dizzying array of projects
• interests of university IT
• a sense-making process about the computing infrastructure, status of various projects, and project methodologies
• efficient management of a core architecture
• interests of other university stakeholders

(Note that other aspects of how a lab is managed may have other priorities - these are just the priorities for infrastructure design.)

I think the best way to explain how these priorities affect the design is to point out where they come into play in the particulars. Once I've done that, I'll collect those notes and come back here and write up a summary of each.

Laziness, Impatience, Hubris, Diligence, Patience and Humility

One of the most difficult balancing acts for an academic researcher running a research lab is striking the right balance between (1) getting things done, (2) professional development, and (3) materials development. In Diligence, Patience, and Humility, Larry Wall expands his well-known discussion of the three virtues of a programmer to three virtues of an agile (my word, not his) community. The key is, as Larry says, to recognize that these seemly opposing needs can actually be met at the same time.

Tools like this wiki are a crucial part of the process. Using them in an agile manner is another crucial part of the process. Letting go of the need to be perfect is yet another - you have to develop the willingness to put interim versions of your work out there for others to see. And be ready for some people to not understand and be fairly nasty about it.

Once you develop the willingness, then everything else follows. Instead of just doing things the way you already know how to do them, always take some time to explore alternatives. Track however far you get on those alternatives in the wiki. When you get a chance, you can keep going. In the meantime, someone else may pick up where you left off. No matter what, folks who are newer in the lab (or in another lab somewhere else) will learn from your notes and thought process. Everybody wins. You loose the vast majority of the benefit of exploring alternatives, though, if you don't put your explorations out somewhere public, because computing systems move too fast for the individual 30 minutes to 3 hour chunks of time you get to add up without community. -- HilaryHolz - 10 May 2008

back to top

Work and play well with others

Our labs live in a larger university environment. What's more, we tend to comprise a very small portion of that university computing environment. Nonetheless, so-called 'pocket labs' have historically been responsible for many of the worst university computing catastrophes.

Our relationship with university IT is truly collaborative (Hilary sits on the UIT committee.) I (Hilary) believe that we've been able to evolve that relationship based on mutual respect and an excellent lab security record.

In general, the lab follows the Center for Internet Security Standards. Details in various places. -- HilaryHolz - 10 May 2008

back to top

Less is more

It's tempting to think that a lab machine is just a research machine, so it isn't really critical to worry about issues of security, optimizing performance, etc. However, lab machines are favorite targets of hackers precisely because that mindset is so common. Leave aside concerns about loss of your precious work for a moment. You would be astonished what portion of a machine's resources are wasted simply by fending off attacks using the default profile of a distribution - that is what a denial of service attack is, after all. Also, you'll also be (pleasantly) astonished at the speedup resulting from disabling (or even better, removing) all the bloatware that even linux now seems to think we all just cannot do without. (Do I really need 4 or 5 competing solutions for wireless connectivity on my server, which has no wireless card? Fellas, I'll download it if/when I need it...) -- HilaryHolz - 10 May 2008

Hanging on to all that extra stuff that you aren't using wastes your resources in every sense of the word

• it slows down the machine, especially daemons, which enlarge process tables, virtual memory, etc
• it makes it harder to maintain the systems you do value (dependency chains, more packages to track, ...)
• they provide avenues for attack to hackers
• they are additional points of failure on the system
• when you upgrade, you have to re-evaluate the systems, because you tend to forget them
• and it literally takes up disk space, of course

back to top

[see also ServerAdminGuidelines