/
presentationPrint.html
65 lines (64 loc) · 3.17 KB
/
presentationPrint.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Infrastucture Manifesto -- as authored by James White</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="cache-control" content="no-cache" />
<meta name="keywords" content="James White Manifesto" />
<meta name="description" content="James White Manifesto" />
<link rel="stylesheet" type="text/css" href="styles.css" />
</head>
<body class="printFriendly">
<h1>Infrastructure Manifesto as authored by James White</h1>
<br />
<h2> On Infrastructure</h2>
<hr>
<ul>
<li> There is one system, not a collection of systems. </li>
<li> The desired state of the system should be a known quantity. </li>
<li> The "known quantity" must be machine parsable. </li>
<li> The actual state of the system must self-correct to the desired state. </li>
<li> The only authoritative source for the actual state of the system is the system. </li>
<li> The entire system must be deployable using source media and text files. </li>
</ul>
<br />
<h2> On Buying Software</h2>
<hr>
<ul>
<li> Keep the components in the infrastructure simple so it will be better understood.</li>
<li> All products must authenticate and authorize from external, configurable sources.</li>
<li> Use small tools that interoperate well, not one "do everything poorly" product.</li>
<li> Do not implement any product that no one in your organization has administered.</li>
<li> "Administered" does not mean saw it in a rigged demo, online or otherwise.</li>
<li> If you must deploy the product, hire someone who has implemented it before to do so.</li>
</ul>
<br />
<h2> On Automation</h2>
<hr>
<ul>
<li> Do not author any code you would not buy.</li>
<li> Do not implement any product that does not provide an API.</li>
<li> The provided API must have all functionality that the application provides.</li>
<li> The provided API must be tailored to more than one language and platform.</li>
<li> Source code counts as an API, and may be restricted to one language or platform.</li>
<li> The API must include functional examples and not require someone to be an expert on the product to use.</li>
<li> Do not use any product with configurations that are not machine parsable and machine writeable.</li>
<li> All data stored in the product must be machine readable and writeable by applications other than the product itself.</li>
<li> Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.</li>
</ul>
<br />
<h2> In General</h2>
<hr>
<ul>
<li> Keep the disparity in your architecture to an absolute minimum.</li>
<li> Use <a href="http://en.wikipedia.org/wiki/Set_theory Set Theory">Set Theory</a> to accomplish this.</li>
<li> Do not improve manual processes if you can automate them instead.</li>
<li> Do not buy software that requires bare-metal.</li>
<li> Manual data transfers and data stores maintained manually are to be avoided.</li>
<br />
<div id="footer">
© 2010 Websages.com
</div>
</body>
</html>