Return to dssp-001.ms CVS log

Up to [Coherent Logic Development] / dssp

Datashed Systems Standards and Procedures

.TL
DSSP-001: Essential Philosophy Document
.br
\fIRevision 1.3 (05/09/19)\fP
.AU
Serena Willis
.AI
Datashed Proprietor
.AB
The Essential Philosophy Document, or "EPD", summarizes the overall philosophy
of information technology guiding technology decisions in data center design,
equipment deployment, and software deployment employed in the Datashed and its
environs.

The primary goal of the Datashed is to provide a 1990s-style data center environment,
eschewing the modern, homogeneous approaches to equipment and operating system
selection. To that end, the Datashed will host the majority of its services on
non-commodity hardware, using a wide variety of operating systems.

The Datashed does, however, make concessions to modern practices in select areas.
Its physical cabling plant is structured, the core of its network secure and
performant, and some commodity x86/Linux equipment is used for monitoring,
backup storage, and occasional hardware emulation.
.AE
.NH
Heterogeneous Environment
.LP
The Datashed offers a heterogeneous hardware and software environment. This means
that services will be provided by and available to non-commodity hardware. Racks
will not match each other, servers will be more than commodity x86-64 hardware running
Linux, networks will be varied beyond the standard UTP-based Ethernet. 

This derives from a belief that choice and variety in IT deployments is a good 
thing, and though we value consistency, our adherence to it is not slavish.
.NH
Relaxed Approach
.LP
We feel that the IT industry takes itself too seriously. We want to provide an
alternative. Just by looking at the decor (such as wall scrolls), one can tell that
the Datashed is not a somber place. It seeks to be as inviting to humans as it is
to servers, switches, and routers.

Though we attempt to maintain a well-managed structured cabling plant, the Datashed
is not unfriendly to the occasional experimental or \fIad hoc\fP deployment.
.NH
Traditional Administration
.LP
We don't believe that building up a server interactively is a bad thing. Not everything
needs to be scripted and repeatable, except where it's important. One will not
encounter complex DevOps orchestration tools in wide use here, although tenants
are free to use them in their own colocated environments.
.NH
Open Community
.LP
We strive to make technical details of our projects known to members of our community,
and the Internet community at large. We believe this will foster an environment that
is both fun and educational.
.NH
DIY Ethic
.LP
We follow a DIY ethic. With limited resources, a small, non-commercial data center 
such as ours must be both pragmatic and resourceful. If a standard practice that is
accepted in large, commercial data centers is impractical or financially unfeasible,
we will develop a robust alternative, rather than giving up and saying it cannot be
done.

We don't typically have support contracts with hardware or software vendors, even if
it means that we do not receive the latest and greatest updates. Often, our equipment
is old enough that the vendor either no longer exists, or would not provide support 
anyway. We mitigate threats ourselves, use secondhand and/or EOL equipment whenever 
we can, and don't shy away from exposing old operating systems to the Internet.
.NH
Reasoning for DSSP Standards
.LP
The DSSP standards are in place to help us stay on-track with our overall philosophy,
and give us reminders for tasks that we want to do consistently each time. There are,
however, no committees or bureaucracies dedicated to enforcing them. The DSSP standards
exist to serve \fBus\fP; they do not exist for us to serve \fBthem\fP.
.LP
@(#)dssp-001.ms	1.3