distillery 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +4 -0
- data/Gemfile +2 -0
- data/Guardfile +5 -0
- data/LICENSE +20 -0
- data/README.md +41 -0
- data/Rakefile +40 -0
- data/TODO +5 -0
- data/bin/distill +24 -0
- data/distillery.gemspec +31 -0
- data/lib/distillery.rb +15 -0
- data/lib/distillery/document.rb +181 -0
- data/lib/distillery/version.rb +3 -0
- data/spec/acceptance_spec.rb +108 -0
- data/spec/fixtures/agave_cookies.html +467 -0
- data/spec/fixtures/baked_ziti.html +2250 -0
- data/spec/fixtures/beef_jerkey.html +457 -0
- data/spec/fixtures/clams_and_linguini.html +1009 -0
- data/spec/fixtures/clouds_shining_moment.html +2145 -0
- data/spec/fixtures/game_blog.html +158 -0
- data/spec/fixtures/ginger_cookies.html +181 -0
- data/spec/fixtures/js_this_keyword.html +1183 -0
- data/spec/fixtures/nyt_social_media.html +418 -0
- data/spec/fixtures/pina_collada_cupcakes.html +4481 -0
- data/spec/fixtures/vanilla_pound_cake.html +2190 -0
- data/spec/lib/distillery/document_spec.rb +259 -0
- data/spec/lib/distillery_spec.rb +27 -0
- data/spec/spec_helper.rb +13 -0
- metadata +180 -0
|
@@ -0,0 +1,2145 @@
|
|
|
1
|
+
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
2
|
+
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
3
|
+
<html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
|
|
4
|
+
<head>
|
|
5
|
+
<!-- chartbeat -->
|
|
6
|
+
<script type="text/javascript">var _sf_startpt=(new Date()).getTime()</script>
|
|
7
|
+
<!-- #chartbeat -->
|
|
8
|
+
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
9
|
+
<title>The AWS Outage: The Cloud's Shining Moment - O'Reilly Broadcast</title>
|
|
10
|
+
<meta name="generator" content="Movable Type Pro 4.21-en" />
|
|
11
|
+
<!-- metas7 -->
|
|
12
|
+
|
|
13
|
+
|
|
14
|
+
<meta name="keywords" content="aws, cloudcomputing, designforfailure, NoSQL" />
|
|
15
|
+
|
|
16
|
+
<meta name="description" content="So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don't get it: it was the cloud's shining moment, exposing the strength of cloud computing." />
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
<meta name="search_date" content="2011-04-23" />
|
|
20
|
+
<meta name="author" content="George Reese" />
|
|
21
|
+
|
|
22
|
+
<!-- metas7 -->
|
|
23
|
+
|
|
24
|
+
<link rel="alternate" type="application/atom+xml" title="O'Reilly News" href="http://feeds.oreilly.com/oreilly/news" />
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
<link rel="alternate" type="application/atom+xml" title="George Reese" href="http://broadcast.oreilly.com/george-reese/atom.xml" />
|
|
28
|
+
|
|
29
|
+
<script src="http://blogs.oreilly.com/broadcast/_ui/js/jquery.js" type="text/javascript" charset="utf-8"></script>
|
|
30
|
+
<script src="http://blogs.oreilly.com/broadcast/_ui/js/main.js" type="text/javascript" charset="utf-8"></script>
|
|
31
|
+
<!-- removed -->
|
|
32
|
+
|
|
33
|
+
<script language="JavaScript" type="text/javascript" src="http://broadcast.oreilly.com/mt.js"></script>
|
|
34
|
+
<script language="JavaScript" type="text/javascript" src="http://www.oreillynet.com/engine.js"></script>
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
<script type="text/javascript" src="http://blogs.oreilly.com/scripts/highslide/highslide.js"></script>
|
|
39
|
+
<script type="text/javascript" src="http://blogs.oreilly.com/scripts/highslide/highslide-html.js"></script>
|
|
40
|
+
|
|
41
|
+
<script type="text/javascript">
|
|
42
|
+
hs.graphicsDir = 'http://blogs.oreilly.com/scripts/highslide/graphics/';
|
|
43
|
+
hs.outlineType = 'rounded-white';
|
|
44
|
+
hs.outlineWhileAnimating = true;
|
|
45
|
+
</script>
|
|
46
|
+
<script language="javascript" src="http://blogs.oreilly.com/rave/rave.js"></script>
|
|
47
|
+
<script language="javascript" src="http://blogs.oreilly.com/menutest.js"></script>
|
|
48
|
+
<!-- readspeak -->
|
|
49
|
+
<script src="http://cdn.oreilly.com/scripts/readspeaker.js" type="text/javascript"></script>
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
<link rel="stylesheet" href="http://broadcast.oreilly.com/styles.css?1" type="text/css" title="web" />
|
|
53
|
+
<link rel="stylesheet" href="http://www.oreillynet.com/styles/chrome.css" type="text/css" title="web" />
|
|
54
|
+
<link rel="shortcut icon" type="image/x-icon" href="http://oreilly.com/favicon.ico" />
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
<link rel="prev" href="http://broadcast.oreilly.com/2011/04/automating-your-workflow.html" title="Automating Your Workflow" />
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
<script type="text/javascript" src="http://broadcast.oreilly.com/mt.js"></script>
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
<!-- MyBuys libraries and style sheet -->
|
|
65
|
+
<link href="http://t.p.mybuys.com/css/mbstyles.css" type="text/css" rel="stylesheet" id="mybuysstyles">
|
|
66
|
+
<script type="text/javascript" src="http://t.p.mybuys.com/js/mybuys3.js"></script>
|
|
67
|
+
<script type="text/javascript" src="http://t.p.mybuys.com/clients/OREILLY/js/setup.js"></script>
|
|
68
|
+
<!-- #MyBuys libraries and style sheet -->
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
</head>
|
|
72
|
+
|
|
73
|
+
<body onload="setMenu();" id="community" class="mt-archive-listing mt-entry-archive layout-twt">
|
|
74
|
+
<div id="container">
|
|
75
|
+
<div id="container-inner">
|
|
76
|
+
<div id="header-09">
|
|
77
|
+
<ul class="accessibility-links">
|
|
78
|
+
<li><a href="#content" title="skip navigation" accesskey="s">Skip navigation</a></li>
|
|
79
|
+
<li><a href="#q" title="Skip to search" accesskey="4">Skip to search form</a></li>
|
|
80
|
+
</ul>
|
|
81
|
+
<div id="navbar">
|
|
82
|
+
<ul id="nav">
|
|
83
|
+
<li id="home"><a href="http://oreilly.com" accesskey="h">Home</a>
|
|
84
|
+
<ul>
|
|
85
|
+
<li><a href="http://oreilly.com/community/">Community</a></li>
|
|
86
|
+
<li><a href="http://oreilly.com/events/">Events</a></li>
|
|
87
|
+
<li><a href="http://oreilly.com/webcasts/">Webcasts</a></li>
|
|
88
|
+
<li><a href="http://elists.oreilly.com/">Newsletters</a></li>
|
|
89
|
+
</ul></li>
|
|
90
|
+
<li><a href="http://oreilly.com/store/">Shop</a>
|
|
91
|
+
<ul>
|
|
92
|
+
<li><a href="http://oreilly.com/store/newreleases.html">New</a></li>
|
|
93
|
+
<li><a href="http://oreilly.com/store/upcoming.html">Upcoming</a></li>
|
|
94
|
+
<li><a href="http://oreilly.com/store/bestsellers.html">Bestselling</a></li>
|
|
95
|
+
<li><a href="http://oreilly.com/store/complete.html">Complete List</a></li>
|
|
96
|
+
<li><a href="http://oreilly.com/store/publisher.html">By Publisher</a></li>
|
|
97
|
+
<li><a href="http://oreilly.com/roughcuts/">Rough Cuts</a></li>
|
|
98
|
+
<li><a href="http://oreilly.com/ebooks">Ebooks</a></li>
|
|
99
|
+
<li><a href="http://oreilly.com/videos">Videos</a></li>
|
|
100
|
+
<li><a href="http://oreilly.com/store/order.html">Order Info</a></li>
|
|
101
|
+
</ul>
|
|
102
|
+
</li>
|
|
103
|
+
<li><a href="http://answers.oreilly.com/">Answers</a></li>
|
|
104
|
+
<li><a href="http://radar.oreilly.com">Radar: News & Commentary</a>
|
|
105
|
+
<ul>
|
|
106
|
+
<li><a href="http://radar.oreilly.com/data">Data</a></li>
|
|
107
|
+
<li><a href="http://radar.oreilly.com/edu2">Edu 2.0</a></li>
|
|
108
|
+
<li><a href="http://radar.oreilly.com/gov2">Gov 2.0</a></li>
|
|
109
|
+
<li><a href="http://radar.oreilly.com/mobile">Mobile</a></li>
|
|
110
|
+
<li><a href="http://radar.oreilly.com/programming">Programming</a></li>
|
|
111
|
+
<li><a href="http://radar.oreilly.com/publishing">Publishing</a></li>
|
|
112
|
+
<li><a href="http://radar.oreilly.com/web2">Web 2.0</a></li>
|
|
113
|
+
</ul></li>
|
|
114
|
+
|
|
115
|
+
<li><a href="http://safari.oreilly.com/?cid=orm-nav-global">Safari Books Online</a>
|
|
116
|
+
<ul>
|
|
117
|
+
<li><a href="http://my.safaribooksonline.com/home?cid=orm-nav-global&portal=oreilly">Safari Home</a></li>
|
|
118
|
+
<li><a href="http://my.safaribooksonline.com/subscribe?cid=orm-nav-global&portal=oreilly">Subscribe</a></li>
|
|
119
|
+
<li><a href="http://my.safaribooksonline.com/trial?cid=orm-nav-global&portal=oreilly">Free Trial</a></li>
|
|
120
|
+
<li><a href="http://my.safaribooksonline.com/books?cid=orm-nav-global&portal=oreilly">Books</a></li>
|
|
121
|
+
<li><a href="http://my.safaribooksonline.com/video?cid=orm-nav-global&portal=oreilly">Videos</a></li>
|
|
122
|
+
</ul>
|
|
123
|
+
</li>
|
|
124
|
+
|
|
125
|
+
<li><a href="http://conferences.oreilly.com/">Conferences</a>
|
|
126
|
+
<ul>
|
|
127
|
+
<li><a href="http://conferences.oreilly.com/archive.csp">Archive</a></li>
|
|
128
|
+
<li><a href="http://conferences.oreilly.com/contacts.csp">Team</a></li>
|
|
129
|
+
<li><a href="http://www.oreillynet.com/conferences/blog/">News</a></li>
|
|
130
|
+
</ul></li>
|
|
131
|
+
<li><a href="http://training.oreilly.com/">Training</a>
|
|
132
|
+
|
|
133
|
+
</li>
|
|
134
|
+
<li><a href="http://www.oreillyschool.com/">School of Technology</a>
|
|
135
|
+
<ul>
|
|
136
|
+
<li><a href="https://oreillyschool.com/enroll/">Enroll</a></li>
|
|
137
|
+
<li><a href="https://oreillyschool.com/career/">Your Career</a></li>
|
|
138
|
+
<li><a href="https://oreillyschool.com/why/">Why OST</a></li>
|
|
139
|
+
<li><a href="https://oreillyschool.com/courses/">Courses & Certificates</a></li>
|
|
140
|
+
<li><a href="https://oreillyschool.com/contact.php">Contact</a></li>
|
|
141
|
+
<li><a href="https://oreillyschool.com/student/">Student Sign In</a></li>
|
|
142
|
+
|
|
143
|
+
</ul></li>
|
|
144
|
+
</ul>
|
|
145
|
+
|
|
146
|
+
<ul id="account-actions">
|
|
147
|
+
<li><a href="https://members.oreilly.com/" class="acct">Your Account</a></li>
|
|
148
|
+
<li><a href="https://epoch.oreilly.com/shop/cart.orm" class="cart">View Cart</a></li>
|
|
149
|
+
</ul>
|
|
150
|
+
</div>
|
|
151
|
+
|
|
152
|
+
|
|
153
|
+
<div id="header">
|
|
154
|
+
|
|
155
|
+
<a href="http://oreilly.com/community/"><h1>O'Reilly Community</h1></a>
|
|
156
|
+
|
|
157
|
+
<div id="search-box" class="yui-skin-sam">
|
|
158
|
+
|
|
159
|
+
<form method="get" action="http://search.oreilly.com" id="search-form" name="searchform">
|
|
160
|
+
|
|
161
|
+
<fieldset>
|
|
162
|
+
<span id="search-input">
|
|
163
|
+
<span id="search-field"><input style="//height: 18px;" id="q" name="q" type="text" maxlength="64" accesskey="s" value="" /></span>
|
|
164
|
+
<span id="search-button">
|
|
165
|
+
<input class="button" type="submit" value="SEARCH" onclick="return searchverif();" />
|
|
166
|
+
</span>
|
|
167
|
+
</span>
|
|
168
|
+
<span class="clear"></span>
|
|
169
|
+
<div id="autocomplete"></div>
|
|
170
|
+
</fieldset>
|
|
171
|
+
</form>
|
|
172
|
+
</div>
|
|
173
|
+
|
|
174
|
+
</div>
|
|
175
|
+
|
|
176
|
+
<div id="subnav">
|
|
177
|
+
<ul>
|
|
178
|
+
<li><a href="http://oreilly.com/authors/">Authors</a></li>
|
|
179
|
+
<li><a href="http://oreilly.com/blogs/" class="selected">Blogs</a></li>
|
|
180
|
+
<li><a href="http://forums.oreilly.com">Forums</a></li>
|
|
181
|
+
<li><a href="http://ug.oreilly.com/">User Groups</a></li>
|
|
182
|
+
<li><a href="http://members.oreilly.com">Membership</a></li>
|
|
183
|
+
<li><a href="http://oreilly.com/community/guidelines.html">Community Guidelines</a></li>
|
|
184
|
+
</ul>
|
|
185
|
+
</div>
|
|
186
|
+
</div>
|
|
187
|
+
<div id="content-09">
|
|
188
|
+
<div id="content">
|
|
189
|
+
<div id="content-inner">
|
|
190
|
+
<div id="alpha">
|
|
191
|
+
<div id="alpha-inner">
|
|
192
|
+
|
|
193
|
+
|
|
194
|
+
|
|
195
|
+
<div id="entry-46231" class="entry-asset asset hentry">
|
|
196
|
+
|
|
197
|
+
<!-- toolbar -->
|
|
198
|
+
<div class="floater" style="float: right; display:block; text-align:left;">
|
|
199
|
+
|
|
200
|
+
<table class="navbar" width="180">
|
|
201
|
+
<!-- print -->
|
|
202
|
+
<tr height="20"><td align="right">
|
|
203
|
+
<a href="#" style="text-decoration:none" onclick="window.open('http://broadcast.oreilly.com/print/46231.html','print','width=800,height=600,menubar=no,status=no,location=yes,toolbar=yes,scrollbars=yes'); return false;"><img src="http://cachefly.oreilly.com/news/images/printtag.jpg" style="padding-left: 90px;padding-right: 5px;" border="0" />Print</a>
|
|
204
|
+
</td></tr>
|
|
205
|
+
<!--twitter button -->
|
|
206
|
+
<!--tr height="26"><td align="right">
|
|
207
|
+
<a href="http://twitter.com/share" class="twitter-share-button" data-count="horizontal" data-via="oreillymedia" data-related="radar:radar.oreilly.com">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script>
|
|
208
|
+
</td></tr-->
|
|
209
|
+
<!-- listen -->
|
|
210
|
+
<tr height="20"><td align="right">
|
|
211
|
+
<a accesskey="L" href="http://app.readspeaker.com/cgi-bin/rsent?customerid=14&lang=en_us&url=http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html" onclick="readspeaker(this.href+'&selectedhtml='+escape(selectedString), 'rs_46231'); return false;" style="text-decoration:none;" ><img border=0 src='http://cachefly.oreilly.com/news/images/listentag.jpg' style="padding-left: 90px; padding-right: 5px;" border="0" alt='Listen to the text content of this page'>Listen</a></span><div class="readspeak"><div id="rs_46231" style="padding-right: 4px; text-align: right;"></div></div>
|
|
212
|
+
</td></tr>
|
|
213
|
+
<!-- share -->
|
|
214
|
+
<tr height="20">
|
|
215
|
+
<td align="right">
|
|
216
|
+
<div id="share-options" style="padding:3px 0 3px 90px;">
|
|
217
|
+
<script type="text/javascript" src="http://w.sharethis.com/button/sharethis.js#publisher=16098316-763b-41fc-a31d-7bbadcfcf894&type=website&embeds=true&style=rotate&send_services=email%2Caim%2Csms&post_services=twitter%2Cfriendfeed%2Cfacebook%2Cdigg%2Cdelicious%2Creddit%2Cslashdot%2Cgoogle_bmarks%2Cblogger%2Ctypepad%2Cstumbleupon%2Cwordpress%2Cwindows_live%2Cnewsvine%2Clinkedin%2Cmyspace%2Ctechnorati"></script>
|
|
218
|
+
</div>
|
|
219
|
+
</td></tr>
|
|
220
|
+
</table>
|
|
221
|
+
|
|
222
|
+
</div><!-- floater#-->
|
|
223
|
+
|
|
224
|
+
|
|
225
|
+
<!-- #toolbar -->
|
|
226
|
+
<div class="asset-header" style="float: left; display:block; width: 300px;">
|
|
227
|
+
<h1 id="page-title" class="asset-name entry-title"><!-- RSPEAK_START -->The AWS Outage: The Cloud's Shining Moment<!-- RSPEAK_STOP --></h1>
|
|
228
|
+
|
|
229
|
+
<div class="asset-meta">
|
|
230
|
+
|
|
231
|
+
<img src="http://oreilly.com/images/people/weblogs/george_reese.jpg" style="padding-right: 5px; padding-top: 2px; float: left; border: none;" alt="" /><!-- RSPEAK_START -->By <a href="http://www.oreillynet.com/pub/au/429">George Reese</a><br />April 23, 2011<!-- RSPEAK_STOP --> <span class="separator">|</span> <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comments">Comments: 20</a><br />
|
|
232
|
+
|
|
233
|
+
|
|
234
|
+
|
|
235
|
+
<p class="asset-meta"><span class="social-counters">
|
|
236
|
+
<span class="retweet"><a href="http://twitter.com/share" class="twitter-share-button" data-count="horizontal" data-url="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html" data-text="The AWS Outage: The Cloud's Shining Moment" data-via="oreillymedia" data-related="radar:radar.oreilly.com">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></span>
|
|
237
|
+
<span class="like"><iframe src="http://www.facebook.com/plugins/like.php?href=http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html&layout=button_count&show_faces=false&width=200&action=like&colorscheme=light&height=20" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:110px; height:20px;" allowTransparency="true"></iframe></span>
|
|
238
|
+
</span></p>
|
|
239
|
+
</div>
|
|
240
|
+
|
|
241
|
+
</div>
|
|
242
|
+
<div class="asset-content entry-content">
|
|
243
|
+
<div class="asset-body">
|
|
244
|
+
|
|
245
|
+
|
|
246
|
+
|
|
247
|
+
|
|
248
|
+
|
|
249
|
+
|
|
250
|
+
|
|
251
|
+
|
|
252
|
+
|
|
253
|
+
|
|
254
|
+
<!-- RSPEAK_START -->
|
|
255
|
+
<p>
|
|
256
|
+
So many cloud pundits are piling on to the misfortunes of <a href="http://aws.amazon.com">Amazon Web Services</a> this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don't get it: it was the cloud's shining moment, exposing the strength of cloud computing.<span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://broadcast.oreilly.com/rescue.jpg"><img alt="" src="http://broadcast.oreilly.com/assets_c/2011/04/rescue-thumb-150x99.jpg" width="150" height="99" class="mt-image-right" style="float: right; margin: 5px 5px 20px 20px;" /></a></span>
|
|
257
|
+
</p>
|
|
258
|
+
<p>
|
|
259
|
+
In short, if your systems failed in the Amazon cloud this week, it wasn't Amazon's fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon's cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.
|
|
260
|
+
</p>
|
|
261
|
+
<p>
|
|
262
|
+
The AWS outage highlighted the fact that, in the cloud, you control your SLA in the cloud—not AWS.
|
|
263
|
+
</p>
|
|
264
|
+
<p><b>The Dueling Models of Cloud Computing</b></p>
|
|
265
|
+
<p>
|
|
266
|
+
Until this past week, there's been a mostly silent war ranging out there between two dueling architectural models of cloud computing applications: "design for failure" and traditional. This battle is about how we ultimately handle availability in the context of cloud computing.
|
|
267
|
+
</p>
|
|
268
|
+
<p>
|
|
269
|
+
The Amazon model is the <em>"design for failure"</em> model. Under the "design for failure" model, combinations of your software and management tools take responsibility for application availability. The actual infrastructure availability is entirely irrelevant to your application availability. 100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage.
|
|
270
|
+
</p>
|
|
271
|
+
<p>
|
|
272
|
+
Most cloud providers follow some variant of the "design for failure" model. A handful of providers, however, follow the traditional model in which the underlying infrastructure takes ultimate responsibility for availability. It doesn't matter how dumb your application is, the infrastructure will provide the redundancy necessary to keep it running in the face of failure. The clouds that tend to follow this model are <a href="http://www.vmware.com/products/vcloud/overview.html">vCloud</a>-based clouds that leverage the capabilities of <a href="http://www.vmware.com">VMware</a> to provide this level of infrastructural support.
|
|
273
|
+
</p>
|
|
274
|
+
<p>
|
|
275
|
+
The advantage of the traditional model is that any application can be deployed into it and assigned the level of redundancy appropriate to its function. The downside is that the traditional model is heavily constrained by geography. It would not have helped you survive this level of cloud provider (public or private) outage.
|
|
276
|
+
</p>
|
|
277
|
+
<p>
|
|
278
|
+
The advantage of the "design for failure" model is that the application developer has total control of their availability with only their data model and volume imposing geographical limitations. The downside of the "design for failure" model is that you must "design for failure" up front.
|
|
279
|
+
</p>
|
|
280
|
+
<p><b>The Five Levels of Redundancy</b></p>
|
|
281
|
+
|
|
282
|
+
<p>In a cloud computing environment, there are five possible levels of redundancy:</p>
|
|
283
|
+
|
|
284
|
+
<ul>
|
|
285
|
+
<li>Physical</li>
|
|
286
|
+
<li>Virtual resource</li>
|
|
287
|
+
<li>Availability zone</li>
|
|
288
|
+
<li>Region</li>
|
|
289
|
+
<li>Cloud</li>
|
|
290
|
+
</ul>
|
|
291
|
+
<p>
|
|
292
|
+
When I talk about redundancy, I'm talking about a level of redundancy that enables you to survive failures with zero downtime. You have the redundancy that simply lets the system keep moving when faced with failures.
|
|
293
|
+
</p>
|
|
294
|
+
<p>
|
|
295
|
+
Physical redundancy encompasses all traditional "n+1" concepts: redundant hardware, data center redundancy, the ability to do vMotion or equivalents, and the ability to replicate an entire network topology in the face of massive infrastructural failure.
|
|
296
|
+
</p>
|
|
297
|
+
<p>
|
|
298
|
+
Traditional models end at physical redundancy. "Design for failure" doesn't care about physical redundancy. Instead, it allocates redundant virtual resources like virtual machines so that the failure of the underlying infrastructure supporting one virtual machine doesn't impact the operations of the other unless they are sharing the failed infrastructural component.
|
|
299
|
+
</p>
|
|
300
|
+
<p>
|
|
301
|
+
The fault tolerance of virtual redundancy generally ends at the cluster/cabinet/data center level (depending on your virtualization topology). To achieve better redundancy, you spread your virtualization resources across multiple availability zones. At this time, I believe only Amazon gives you full control over your availability zone deployments. When you have redundant resources across multiple availability zones, you can survive the complete loss of (n-1) availability zones (where n is the number of availability zones in which you are redundant).
|
|
302
|
+
</p>
|
|
303
|
+
<p>
|
|
304
|
+
Until this week, no one has needed anything more than availability zone redundancy. If you had redundancy across availability zones, you would have survived every outage suffered to date in the Amazon cloud. As we noted this week, however, an outage can take out an entire cloud region.
|
|
305
|
+
</p>
|
|
306
|
+
<p>
|
|
307
|
+
Regional redundancy enables you to survive the loss of an entire cloud region. If you had regional redundancy in place, you would have come through the recent outage without any problems except maybe an increased workload for your surviving virtual resources. Of course, regional redundancy won't let you survive business failures of your cloud provider.
|
|
308
|
+
</p>
|
|
309
|
+
<p>
|
|
310
|
+
Cloud redundancy enables you to survive the complete loss of a cloud provider.
|
|
311
|
+
</p>
|
|
312
|
+
<p><b>Applied "Design for Failure"</b></p>
|
|
313
|
+
<p>
|
|
314
|
+
In presentations, I refer to the "design for failure" model as the AWS model. AWS doesn't have any particular monopoly on this model, but their lack of persistent virtual machines pushes this model to its extreme. Actually, best practices for building greenfield applications in most clouds fit under this model.
|
|
315
|
+
</p>
|
|
316
|
+
<p>
|
|
317
|
+
The fundamental principle of "design for failure" is that the application is responsible for its own availability, regardless of the reliability of the underlying cloud infrastructure. In other word, you should be able to deploy a "design for failure" application and achieve 99.9999% uptime (really, 100%) leveraging any cloud infrastructure. It doesn't matter if the underlying infrastructural components have only a 90% uptime rating. It doesn't matter if the cloud has a complete data center meltdown that takes it entirely off the Internet.
|
|
318
|
+
</p>
|
|
319
|
+
<p>
|
|
320
|
+
There are several requirements for "design for failure":
|
|
321
|
+
</p>
|
|
322
|
+
<ul>
|
|
323
|
+
<li>Each application component must be deployed across redundant cloud components, ideally with minimal or no common points of failure</li>
|
|
324
|
+
<li>Each application component must make no assumptions about the underlying infrastructure—it must be able to adapt to changes in the infrastructure without downtime</li>
|
|
325
|
+
<li>Each application component should be partition tolerant—in other words, it should be able to survive network latency (or loss of communication) among the nodes that support that component</li>
|
|
326
|
+
<li>Automation tools must be in place to orchestrate application responses to failures or other changes in the infrastructure (full disclosure, I am CTO of a company that sells such automation tools, <a href="http://www.enstratus.com">enStratus</a>)</li>
|
|
327
|
+
</ul>
|
|
328
|
+
<p>
|
|
329
|
+
Applications built with "design for failure" in mind don't need SLAs. They don't care about the lack of control associated with deploying in someone else's infrastructure. By their very nature, they will achieve uptimes you can't dream of with other architectures and survive extreme failures in the cloud infrastructure.
|
|
330
|
+
</p>
|
|
331
|
+
<p>
|
|
332
|
+
Let's look at a design for failure model that would have come through the AWS outage in flying colors:
|
|
333
|
+
</p>
|
|
334
|
+
<ul>
|
|
335
|
+
<li>Dynamic DNS pointing to elastic load balancers in Virginia and California</li>
|
|
336
|
+
<li>Load balancers routing to web applications in at least two zones in each region</li>
|
|
337
|
+
<li>A <a href="http://en.wikipedia.org/wiki/NoSQL_(concept)">NoSQL</a> data store with the ring spread across all web application availability zones in both Virginia and California</li>
|
|
338
|
+
<li>A cloud management tool (running outside the cloud!) monitoring this infrastructure for failures and handling reconfiguration</li>
|
|
339
|
+
</ul>
|
|
340
|
+
<p>
|
|
341
|
+
Upon failure, your California systems and the management tool take over. The management tool reconfigures DNS to remove the Virginia load balancer from the mix. All traffic is now going to California. The web applications in California are stupid and don't care about Virginia under any circumstance, and your NoSQL system is able to deal with the lost Virginia systems. Your cloud management tool attempts to kill off all Virginia resources and bring up resources in California to replace the load.
|
|
342
|
+
</p>
|
|
343
|
+
<p>
|
|
344
|
+
Voila, no humans, no 2am calls, and no outage! Extra bonus points for "bursting" into Singapore, Japan, Ireland, or another cloud! When Virginia comes back up, the system may or may not attempt to rebalance back into Virginia.
|
|
345
|
+
</p>
|
|
346
|
+
<p><b>Relational Databases</b></p>
|
|
347
|
+
<p>
|
|
348
|
+
OK, so I neatly sidestepped the issue of relational databases. Things are obviously not so clean with relational database systems and the NoSQL system almost certainly would have lost some minimal amounts of data in the cut-over. If that data loss is acceptable, you better not be running a relational database system. If it is not acceptable, then you need to be running a relational database system.
|
|
349
|
+
</p>
|
|
350
|
+
<p>
|
|
351
|
+
A NoSQL database (and I hate the term NoSQL with the passion of a billion white hot suns) <a href="http://en.wikipedia.org/wiki/CAP_theorem">trades off data consistency for something called partition tolerance</a>. The layman's description of partition tolerance is basically the ability to split your data across multiple, geographically distinct partitions. A relational system can't give you that. A NoSQL system can't give you data consistency. Pick your poison.
|
|
352
|
+
</p>
|
|
353
|
+
<p>
|
|
354
|
+
Sometimes that poison must be a relational database. And that means we can't easily partition our data across California and Virginia. You now need to look at several different options:
|
|
355
|
+
</p>
|
|
356
|
+
|
|
357
|
+
<ul>
|
|
358
|
+
<li>Master/slave across regions with automated slave promotion using your cloud management tool</li>
|
|
359
|
+
<li>Master/slave across regions with manual slave promotion </li>
|
|
360
|
+
<li>Regional data segmentation with a master/master configuration and automated failover</li>
|
|
361
|
+
</ul>
|
|
362
|
+
<p>
|
|
363
|
+
There are likely a number of other options depending on your data model and DBA skillset. All of them involve potential data loss when you recover systems to the California region, as well as some basic level of downtime. All, however, protect your data consistency during normal operations—something the NoSQL option doesn't provide you. The choice of automated vs. manual depends on whether you want a human making data loss acceptance decisions. You may particularly want a human involved in that decision in a scenario like what happened this week because only a human really can judge, "How confident am I that AWS will have the system up in the next (INSERT AN INTERVAL HERE)?"
|
|
364
|
+
</p>
|
|
365
|
+
|
|
366
|
+
<p><b>The Traditional Model</b></p>
|
|
367
|
+
<p>
|
|
368
|
+
As its name implies, the "design for failure" requires you to design for failure. It therefore significantly constrains your application architecture. While most of these constraints are things you should be doing anyways, most legacy applications just aren't built that way. Of course, "design for failure" is also heavily biased towards NoSQL databases which often are not appropriate in an enterprise application context.
|
|
369
|
+
</p>
|
|
370
|
+
<p>
|
|
371
|
+
The traditional model will support any kind of application, even a "design for failure" application. The problem is that it's often harder to build "design for failure" systems on top of the traditional model because most current implementations of the traditional model simply lack the flexibility and tools that make "design for failure" work in other clouds.
|
|
372
|
+
</p>
|
|
373
|
+
|
|
374
|
+
<p><b>Control, SLAs, Cloud Models, and You</b></p>
|
|
375
|
+
<p>
|
|
376
|
+
When you make the move into the cloud, you are doing so exactly because you want to give up control over the infrastructure level. The knee-jerk reaction is to look for an SLA from your cloud provider to cover this lack of control. The better reaction is to deploy applications in the cloud designed to make your lack of control irrelevant. It's not simply an availability issue; it also extends to other aspects of cloud computing like security and governance. You don't need no stinking SLA.
|
|
377
|
+
</p>
|
|
378
|
+
<p>
|
|
379
|
+
As I stated earlier, this outage highlights the power of cloud computing. What about Netflix, an AWS customer that kept on going because they had proper "design for failure"? Try doing that in your private IT infrastructure with the complete loss of a data center. What about another AWS/enStratus startup customer who did not design for failure, but took advantage of the cloud DR capabilities to rapidly move their systems to California? What startup would ever have been able to relocate their entire application across country within a few hours of the loss of their entire data center without already paying through the nose for it?
|
|
380
|
+
</p>
|
|
381
|
+
<p>
|
|
382
|
+
These kinds of failures don't expose the weaknesses of the cloud—they expose why the cloud is so important.
|
|
383
|
+
</p>
|
|
384
|
+
<!-- RSPEAK_STOP -->
|
|
385
|
+
|
|
386
|
+
|
|
387
|
+
</div>
|
|
388
|
+
<br clear="left"><div class="asset-footer">
|
|
389
|
+
|
|
390
|
+
|
|
391
|
+
|
|
392
|
+
<div class="entry-tags">
|
|
393
|
+
<h4 class="entry-tags-header">Tags<span class="delimiter">:</span></h4>
|
|
394
|
+
<ul class="entry-tags-list">
|
|
395
|
+
<li class="entry-tag"><a href="http://oreilly.com/blogs/tags.csp?tag=aws" rel="tag">aws</a><span class="delimiter">,</span></li> <li class="entry-tag"><a href="http://oreilly.com/blogs/tags.csp?tag=cloudcomputing" rel="tag">cloudcomputing</a><span class="delimiter">,</span></li> <li class="entry-tag"><a href="http://oreilly.com/blogs/tags.csp?tag=designforfailure" rel="tag">designforfailure</a><span class="delimiter">,</span></li> <li class="entry-tag"><a href="http://oreilly.com/blogs/tags.csp?tag=NoSQL" rel="tag">NoSQL</a></li>
|
|
396
|
+
</ul>
|
|
397
|
+
</div>
|
|
398
|
+
|
|
399
|
+
|
|
400
|
+
<br />
|
|
401
|
+
|
|
402
|
+
</div>
|
|
403
|
+
</div>
|
|
404
|
+
|
|
405
|
+
</div>
|
|
406
|
+
|
|
407
|
+
|
|
408
|
+
|
|
409
|
+
|
|
410
|
+
|
|
411
|
+
|
|
412
|
+
<div style="width: 100%; margin-right: 0px; margin-left: 0px; padding-right: 0px; padding-left: 0px;"><h3>You might also be interested in:</h3>
|
|
413
|
+
<div style="width: 100%; margin-right: 0px; margin-left: 0px; padding-right: 0px; padding-left: 0px;">
|
|
414
|
+
<!-- MyBuys Web Recommendation Zone -->
|
|
415
|
+
<div mybuyszone="4"></div>
|
|
416
|
+
<!-- End MyBuys Web Recommendation Zone -->
|
|
417
|
+
</div>
|
|
418
|
+
</div>
|
|
419
|
+
|
|
420
|
+
<div class="linebreak">
|
|
421
|
+
|
|
422
|
+
<div class="noindex">
|
|
423
|
+
<div id="comments" class="comments">
|
|
424
|
+
|
|
425
|
+
|
|
426
|
+
|
|
427
|
+
<h2 class="comments-header">20 Comments</h2>
|
|
428
|
+
<div class="comments-content">
|
|
429
|
+
|
|
430
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
431
|
+
<div id="comment-7184732" class="comment">
|
|
432
|
+
<div class="inner">
|
|
433
|
+
<div class="comment-header">
|
|
434
|
+
<div class="asset-meta">
|
|
435
|
+
<span class="byline">
|
|
436
|
+
By
|
|
437
|
+
|
|
438
|
+
<span class="vcard author">Razi Sharir</span>
|
|
439
|
+
|
|
440
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7184732"><abbr class="published" title="2011-04-23T11:11:48-08:00">April 23, 2011 11:11 AM</abbr></a>
|
|
441
|
+
|
|
442
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7184732, 'Razi Sharir')">Reply</a>
|
|
443
|
+
|
|
444
|
+
</span>
|
|
445
|
+
</div>
|
|
446
|
+
</div>
|
|
447
|
+
<div class="comment-content">
|
|
448
|
+
<p>Couldn't agree more. When we designed Xeround SQL Cloud Database-as-a-service; we looked at all the layers you listed for alternate DRP design: Physical > Virtual resource > Availability zone > Region > Cloud. <br />
|
|
449
|
+
With that in mind, we took a cloud agnostic approach enabling our users to run their databases on any public cloud - Amazon (East, Europe, same/multi zone), Rackspace and soon many other IaaS worldwide, private cloud (Vmware vCloud)… In fact we also support a similar approach PaaS wise – support Heroku, CloudControll and quite a few others coming soon.<br />
|
|
450
|
+
We know running a dB in the cloud is tricky and took the DBaaS direction, Acunna Matata worry free philosophy; auto everything – hilling, elastic scalability, distribution, even more front end SQL/NoSQL APIs coming soon.<br />
|
|
451
|
+
Try us at xeround.com (razi Sharir<br />
|
|
452
|
+
</p>
|
|
453
|
+
</div>
|
|
454
|
+
</div>
|
|
455
|
+
</div>
|
|
456
|
+
|
|
457
|
+
|
|
458
|
+
|
|
459
|
+
|
|
460
|
+
|
|
461
|
+
|
|
462
|
+
|
|
463
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
464
|
+
<div id="comment-7185990" class="comment">
|
|
465
|
+
<div class="inner">
|
|
466
|
+
<div class="comment-header">
|
|
467
|
+
<div class="asset-meta">
|
|
468
|
+
<span class="byline">
|
|
469
|
+
By
|
|
470
|
+
|
|
471
|
+
<span class="vcard author">Will</span>
|
|
472
|
+
|
|
473
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7185990"><abbr class="published" title="2011-04-23T13:34:18-08:00">April 23, 2011 1:34 PM</abbr></a>
|
|
474
|
+
|
|
475
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7185990, 'Will')">Reply</a>
|
|
476
|
+
|
|
477
|
+
</span>
|
|
478
|
+
</div>
|
|
479
|
+
</div>
|
|
480
|
+
<div class="comment-content">
|
|
481
|
+
<p>I thought the failure was that multiple availability zones died simultaneously, something that by design and per Amazon's docs should never happen short of a hurricane in Virginia. Note that out is exponentially harder to distribute your app across not only AZs but geographical areas as well: high speed links connect AZs within a geo, but going from one geo to another is extremely slow and not realtime.</p>
|
|
482
|
+
|
|
483
|
+
<p>Of course you design for failure, it happens every day on AWS. But can you design around multiple datacenters (availability zones) dying simultaneously? When AWS told you not to worry about that eventuality? Probably not without downtime and some serious compromises.</p>
|
|
484
|
+
</div>
|
|
485
|
+
</div>
|
|
486
|
+
</div>
|
|
487
|
+
|
|
488
|
+
|
|
489
|
+
|
|
490
|
+
|
|
491
|
+
|
|
492
|
+
|
|
493
|
+
|
|
494
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
495
|
+
<div id="comment-7186063" class="comment">
|
|
496
|
+
<div class="inner">
|
|
497
|
+
<div class="comment-header">
|
|
498
|
+
<div class="asset-meta">
|
|
499
|
+
<span class="byline">
|
|
500
|
+
By
|
|
501
|
+
|
|
502
|
+
<span class="vcard author">Alexander Muse</span>
|
|
503
|
+
|
|
504
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7186063"><abbr class="published" title="2011-04-23T13:43:25-08:00">April 23, 2011 1:43 PM</abbr></a>
|
|
505
|
+
|
|
506
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7186063, 'Alexander Muse')">Reply</a>
|
|
507
|
+
|
|
508
|
+
</span>
|
|
509
|
+
</div>
|
|
510
|
+
</div>
|
|
511
|
+
<div class="comment-content">
|
|
512
|
+
<p>It was a surprise that so many popular web services went down when Amazon went down. We always assumed one of two things would happen: that our infrastructure in the Amazon cloud would fail or our infrastructure in our data center would fail (hopefully not at the same time). <br />
|
|
513
|
+
</p>
|
|
514
|
+
</div>
|
|
515
|
+
</div>
|
|
516
|
+
</div>
|
|
517
|
+
|
|
518
|
+
|
|
519
|
+
|
|
520
|
+
|
|
521
|
+
|
|
522
|
+
|
|
523
|
+
|
|
524
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
525
|
+
<div id="comment-7186323" class="comment">
|
|
526
|
+
<div class="inner">
|
|
527
|
+
<div class="comment-header">
|
|
528
|
+
<div class="asset-meta">
|
|
529
|
+
<span class="byline">
|
|
530
|
+
By
|
|
531
|
+
|
|
532
|
+
<span class="vcard author">mike</span>
|
|
533
|
+
|
|
534
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7186323"><abbr class="published" title="2011-04-23T14:07:31-08:00">April 23, 2011 2:07 PM</abbr></a>
|
|
535
|
+
|
|
536
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7186323, 'mike')">Reply</a>
|
|
537
|
+
|
|
538
|
+
</span>
|
|
539
|
+
</div>
|
|
540
|
+
</div>
|
|
541
|
+
<div class="comment-content">
|
|
542
|
+
<p>The problem is that once EVERYONE falls back to a service in another availability zone, that zone suddenly has to handle twice the load (probably a lot more when Virginia goes down, because it's generally believed to have the most instances). We saw pretty heavy slowdown across zones even with only a handful of people following this approach. You need to either bring another provider into the mix, or just have faith that AWS keeps piles and piles of spare capacity.</p>
|
|
543
|
+
</div>
|
|
544
|
+
</div>
|
|
545
|
+
</div>
|
|
546
|
+
|
|
547
|
+
|
|
548
|
+
|
|
549
|
+
|
|
550
|
+
|
|
551
|
+
|
|
552
|
+
|
|
553
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
554
|
+
<div id="comment-7186642" class="comment">
|
|
555
|
+
<div class="inner">
|
|
556
|
+
<div class="comment-header">
|
|
557
|
+
<div class="asset-meta">
|
|
558
|
+
<span class="byline">
|
|
559
|
+
By
|
|
560
|
+
|
|
561
|
+
<span class="vcard author">BiggieBig</span>
|
|
562
|
+
|
|
563
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7186642"><abbr class="published" title="2011-04-23T14:35:25-08:00">April 23, 2011 2:35 PM</abbr></a>
|
|
564
|
+
|
|
565
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7186642, 'BiggieBig')">Reply</a>
|
|
566
|
+
|
|
567
|
+
</span>
|
|
568
|
+
</div>
|
|
569
|
+
</div>
|
|
570
|
+
<div class="comment-content">
|
|
571
|
+
<p>More bullshit. </p>
|
|
572
|
+
</div>
|
|
573
|
+
</div>
|
|
574
|
+
</div>
|
|
575
|
+
|
|
576
|
+
|
|
577
|
+
<!-- Loop through the reply comments -->
|
|
578
|
+
|
|
579
|
+
<div style="margin-left: 20px;">
|
|
580
|
+
|
|
581
|
+
<div id="comment-7188855" class="comment comment-reply">
|
|
582
|
+
<div class="inner">
|
|
583
|
+
<div class="comment-header">
|
|
584
|
+
<div class="asset-meta">
|
|
585
|
+
<span class="byline">
|
|
586
|
+
By
|
|
587
|
+
|
|
588
|
+
<span class="vcard author">jerhewet</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7186642">comment from BiggieBig</a>
|
|
589
|
+
|
|
590
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7188855"><abbr class="published" title="2011-04-23T17:14:05-08:00">April 23, 2011 5:14 PM</abbr></a>
|
|
591
|
+
|
|
592
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7188855, 'jerhewet')">Reply</a>
|
|
593
|
+
|
|
594
|
+
</span>
|
|
595
|
+
</div>
|
|
596
|
+
</div>
|
|
597
|
+
<div class="comment-content">
|
|
598
|
+
<p>Ayep. What BiggieBig said. The cloud fanatics really do need to wake the f__k up and smell the f__ckin' coffee.</p>
|
|
599
|
+
</div>
|
|
600
|
+
</div>
|
|
601
|
+
</div>
|
|
602
|
+
|
|
603
|
+
|
|
604
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
605
|
+
|
|
606
|
+
<!-- Loop through the reply comments -->
|
|
607
|
+
|
|
608
|
+
<div id="comment-7189537" class="comment comment-reply">
|
|
609
|
+
<div class="inner">
|
|
610
|
+
<div class="comment-header">
|
|
611
|
+
<div class="asset-meta">
|
|
612
|
+
<span class="byline">
|
|
613
|
+
By
|
|
614
|
+
|
|
615
|
+
<span class="vcard author">ronroddam</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7186642">comment from BiggieBig</a>
|
|
616
|
+
|
|
617
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7189537"><abbr class="published" title="2011-04-23T18:22:21-08:00">April 23, 2011 6:22 PM</abbr></a>
|
|
618
|
+
|
|
619
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7189537, 'ronroddam')">Reply</a>
|
|
620
|
+
|
|
621
|
+
</span>
|
|
622
|
+
</div>
|
|
623
|
+
</div>
|
|
624
|
+
<div class="comment-content">
|
|
625
|
+
<p>Succinct, not much substance or thoughtful consideration but succinct.</p>
|
|
626
|
+
</div>
|
|
627
|
+
</div>
|
|
628
|
+
</div>
|
|
629
|
+
|
|
630
|
+
|
|
631
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
632
|
+
|
|
633
|
+
</div>
|
|
634
|
+
|
|
635
|
+
|
|
636
|
+
|
|
637
|
+
|
|
638
|
+
|
|
639
|
+
|
|
640
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
641
|
+
<div id="comment-7187138" class="comment">
|
|
642
|
+
<div class="inner">
|
|
643
|
+
<div class="comment-header">
|
|
644
|
+
<div class="asset-meta">
|
|
645
|
+
<span class="byline">
|
|
646
|
+
By
|
|
647
|
+
|
|
648
|
+
<span class="vcard author">Justin Santa Barbara</span>
|
|
649
|
+
|
|
650
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187138"><abbr class="published" title="2011-04-23T15:20:15-08:00">April 23, 2011 3:20 PM</abbr></a>
|
|
651
|
+
|
|
652
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187138, 'Justin Santa Barbara')">Reply</a>
|
|
653
|
+
|
|
654
|
+
</span>
|
|
655
|
+
</div>
|
|
656
|
+
</div>
|
|
657
|
+
<div class="comment-content">
|
|
658
|
+
<p>AWS previously assured us that multiple Availability Zones wouldn't realistically fail at the same time. Now that proved to be untrue, you choose to say "Ah - you shouldn't have believed AWS, you should have been using multiple regions" Presumably when the next outage hits both US regions you'll say "Ah - of course you should have used the EU and Asia regions as well".</p>
|
|
659
|
+
|
|
660
|
+
<p>We should recognize AWS as a single point of failure and look at hosting across multiple providers. Fool me once, shame on you; fool me twice, shame on me.</p>
|
|
661
|
+
|
|
662
|
+
<p>This does require sophisticated management tools like enStratus, but you should use those tools to avoid putting all your eggs into the AWS basket.</p>
|
|
663
|
+
|
|
664
|
+
<p>I'm not sure that the rest of the technology stack has necessarily caught up to this model though - in particular NoSQL databases aren't the panacea you appear to believe them to be. Hopefully all the pieces of the technology stack will evolve.<br />
|
|
665
|
+
</p>
|
|
666
|
+
</div>
|
|
667
|
+
</div>
|
|
668
|
+
</div>
|
|
669
|
+
|
|
670
|
+
|
|
671
|
+
<!-- Loop through the reply comments -->
|
|
672
|
+
|
|
673
|
+
<div style="margin-left: 20px;">
|
|
674
|
+
|
|
675
|
+
<div id="comment-7187181" class="comment comment-reply">
|
|
676
|
+
<div class="inner">
|
|
677
|
+
<div class="comment-header">
|
|
678
|
+
<div class="asset-meta">
|
|
679
|
+
<span class="byline">
|
|
680
|
+
By
|
|
681
|
+
|
|
682
|
+
<span class="vcard author">George Reese</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187138">comment from Justin Santa Barbara</a>
|
|
683
|
+
|
|
684
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187181"><abbr class="published" title="2011-04-23T15:25:42-08:00">April 23, 2011 3:25 PM</abbr></a>
|
|
685
|
+
|
|
686
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187181, 'George Reese')">Reply</a>
|
|
687
|
+
|
|
688
|
+
</span>
|
|
689
|
+
</div>
|
|
690
|
+
</div>
|
|
691
|
+
<div class="comment-content">
|
|
692
|
+
<p>AWS has never in any conversation I have ever had said that multiple availability zones would not realistically fail at the same time. If they felt that way, don't you think they'd have an SLA better than 99.9%?</p>
|
|
693
|
+
|
|
694
|
+
<p>Of course, if you want to survive the failure of multiple availability zones, you should spread yourself across regions. I don't understand why this is so hard for people to understand.</p>
|
|
695
|
+
|
|
696
|
+
<p>Similarly, yes, you should have some ability to migrate your systems into another cloud. I don't think actual technical loss of all AWS regions (or even multiple regions) can happen absent of nuclear war or asteroid strike, but companies do go out of business/get sued/etc.</p>
|
|
697
|
+
</div>
|
|
698
|
+
</div>
|
|
699
|
+
</div>
|
|
700
|
+
|
|
701
|
+
|
|
702
|
+
<!-- Loop through the reply comments -->
|
|
703
|
+
|
|
704
|
+
<div style="margin-left: 20px;">
|
|
705
|
+
|
|
706
|
+
<div id="comment-7187433" class="comment comment-reply">
|
|
707
|
+
<div class="inner">
|
|
708
|
+
<div class="comment-header">
|
|
709
|
+
<div class="asset-meta">
|
|
710
|
+
<span class="byline">
|
|
711
|
+
By
|
|
712
|
+
|
|
713
|
+
<span class="vcard author">Justin Santa Barbara</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187181">comment from George Reese</a>
|
|
714
|
+
|
|
715
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187433"><abbr class="published" title="2011-04-23T15:45:36-08:00">April 23, 2011 3:45 PM</abbr></a>
|
|
716
|
+
|
|
717
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187433, 'Justin Santa Barbara')">Reply</a>
|
|
718
|
+
|
|
719
|
+
</span>
|
|
720
|
+
</div>
|
|
721
|
+
</div>
|
|
722
|
+
<div class="comment-content">
|
|
723
|
+
<p>From the EC2 homepage (http://aws.amazon.com/ec2/):<br />
|
|
724
|
+
"Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from failure of a single location."</p>
|
|
725
|
+
|
|
726
|
+
<p>From the EC2 FAQ (http://aws.amazon.com/ec2/faqs/):<br />
|
|
727
|
+
"Q: How isolated are Availability Zones from one another?<br />
|
|
728
|
+
Each availability zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone."</p>
|
|
729
|
+
|
|
730
|
+
<p>Seems pretty clear to me that multiple AZ failure is supposed to be unrealistic except in the case of disasters, and AWS even explicitly state that it would have to be a large scale disaster, not just a "measly" fire, tornado or flood :-)</p>
|
|
731
|
+
|
|
732
|
+
<p>In addition, AWS themselves engineered their own solutions reflecting this assumption (e.g. RDS Multi-AZ is multi-AZ, not multi-region)</p>
|
|
733
|
+
|
|
734
|
+
<p>Of course, you're right - AWS was over-promising here; we should have ignored what they stated and used multiple regions. But it's the same people and the same software that run those multiple regions, so I don't see understand how you continue to have faith that multiple regions won't go down except in extraordinary circumstances.</p>
|
|
735
|
+
|
|
736
|
+
<p>I think we're in agreement that you can't trust a single AZ; we've learned in this outage that you can't trust a single Region. We only disagree in that you continue to have faith in multiple AWS regions, whereas I have no reason to believe that e.g. an AWS software bug won't get deployed to all regions, or that a rogue AWS employee won't somehow shut down all the regions.</p>
|
|
737
|
+
|
|
738
|
+
<p>As for your conversations with AWS, if they were in fact privately saying to you that multiple AZ failure were likely, while publicly saying the opposite, I think you should publish that story.</p>
|
|
739
|
+
</div>
|
|
740
|
+
</div>
|
|
741
|
+
</div>
|
|
742
|
+
|
|
743
|
+
|
|
744
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
745
|
+
|
|
746
|
+
</div>
|
|
747
|
+
|
|
748
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
749
|
+
|
|
750
|
+
</div>
|
|
751
|
+
|
|
752
|
+
|
|
753
|
+
|
|
754
|
+
|
|
755
|
+
|
|
756
|
+
|
|
757
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
758
|
+
|
|
759
|
+
|
|
760
|
+
|
|
761
|
+
|
|
762
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
763
|
+
<div id="comment-7187212" class="comment">
|
|
764
|
+
<div class="inner">
|
|
765
|
+
<div class="comment-header">
|
|
766
|
+
<div class="asset-meta">
|
|
767
|
+
<span class="byline">
|
|
768
|
+
By
|
|
769
|
+
|
|
770
|
+
<span class="vcard author">JL</span>
|
|
771
|
+
|
|
772
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187212"><abbr class="published" title="2011-04-23T15:27:37-08:00">April 23, 2011 3:27 PM</abbr></a>
|
|
773
|
+
|
|
774
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187212, 'JL')">Reply</a>
|
|
775
|
+
|
|
776
|
+
</span>
|
|
777
|
+
</div>
|
|
778
|
+
</div>
|
|
779
|
+
<div class="comment-content">
|
|
780
|
+
<p>This was foretold decades ago in the movie Animal House:</p>
|
|
781
|
+
|
|
782
|
+
<p>"You f****ed up. You trusted us!"</p>
|
|
783
|
+
|
|
784
|
+
<p>I really like how various vendors jumped in these comments saying how their products would have prevented it. </p>
|
|
785
|
+
|
|
786
|
+
<p>a.k.a. see "Animal House".</p>
|
|
787
|
+
</div>
|
|
788
|
+
</div>
|
|
789
|
+
</div>
|
|
790
|
+
|
|
791
|
+
|
|
792
|
+
|
|
793
|
+
|
|
794
|
+
|
|
795
|
+
|
|
796
|
+
|
|
797
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
798
|
+
<div id="comment-7187298" class="comment">
|
|
799
|
+
<div class="inner">
|
|
800
|
+
<div class="comment-header">
|
|
801
|
+
<div class="asset-meta">
|
|
802
|
+
<span class="byline">
|
|
803
|
+
By
|
|
804
|
+
|
|
805
|
+
<span class="vcard author">John Duhring</span>
|
|
806
|
+
|
|
807
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187298"><abbr class="published" title="2011-04-23T15:33:32-08:00">April 23, 2011 3:33 PM</abbr></a>
|
|
808
|
+
|
|
809
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187298, 'John Duhring')">Reply</a>
|
|
810
|
+
|
|
811
|
+
</span>
|
|
812
|
+
</div>
|
|
813
|
+
</div>
|
|
814
|
+
<div class="comment-content">
|
|
815
|
+
<p>We documented our experience at bitmenu here:</p>
|
|
816
|
+
|
|
817
|
+
<p><a href="http://blog.bitmenu.com/2011/04/production-push-redundancy-is.html" rel="nofollow">http://blog.bitmenu.com/2011/04/production-push-redundancy-is.html</a></p>
|
|
818
|
+
|
|
819
|
+
<p>An event like this makes us value the new infrastructure even more.</p>
|
|
820
|
+
</div>
|
|
821
|
+
</div>
|
|
822
|
+
</div>
|
|
823
|
+
|
|
824
|
+
|
|
825
|
+
|
|
826
|
+
|
|
827
|
+
|
|
828
|
+
|
|
829
|
+
|
|
830
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
831
|
+
|
|
832
|
+
|
|
833
|
+
|
|
834
|
+
|
|
835
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
836
|
+
<div id="comment-7187684" class="comment">
|
|
837
|
+
<div class="inner">
|
|
838
|
+
<div class="comment-header">
|
|
839
|
+
<div class="asset-meta">
|
|
840
|
+
<span class="byline">
|
|
841
|
+
By
|
|
842
|
+
|
|
843
|
+
<span class="vcard author">iMeerkatCS</span>
|
|
844
|
+
|
|
845
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187684"><abbr class="published" title="2011-04-23T16:04:01-08:00">April 23, 2011 4:04 PM</abbr></a>
|
|
846
|
+
|
|
847
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187684, 'iMeerkatCS')">Reply</a>
|
|
848
|
+
|
|
849
|
+
</span>
|
|
850
|
+
</div>
|
|
851
|
+
</div>
|
|
852
|
+
<div class="comment-content">
|
|
853
|
+
<p>I think Amazon should stick with selling everything under the sun except cloud web services. Leave google to master the cloud much like they master everything else on the internet. EC2 FAiL :D</p>
|
|
854
|
+
</div>
|
|
855
|
+
</div>
|
|
856
|
+
</div>
|
|
857
|
+
|
|
858
|
+
|
|
859
|
+
<!-- Loop through the reply comments -->
|
|
860
|
+
|
|
861
|
+
<div style="margin-left: 20px;">
|
|
862
|
+
|
|
863
|
+
<div id="comment-7188110" class="comment comment-reply">
|
|
864
|
+
<div class="inner">
|
|
865
|
+
<div class="comment-header">
|
|
866
|
+
<div class="asset-meta">
|
|
867
|
+
<span class="byline">
|
|
868
|
+
By
|
|
869
|
+
|
|
870
|
+
<span class="vcard author">George Reese</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187684">comment from iMeerkatCS</a>
|
|
871
|
+
|
|
872
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7188110"><abbr class="published" title="2011-04-23T16:30:35-08:00">April 23, 2011 4:30 PM</abbr></a>
|
|
873
|
+
|
|
874
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7188110, 'George Reese')">Reply</a>
|
|
875
|
+
|
|
876
|
+
</span>
|
|
877
|
+
</div>
|
|
878
|
+
</div>
|
|
879
|
+
<div class="comment-content">
|
|
880
|
+
<p>Because Google has such a stellar track record?</p>
|
|
881
|
+
</div>
|
|
882
|
+
</div>
|
|
883
|
+
</div>
|
|
884
|
+
|
|
885
|
+
|
|
886
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
887
|
+
|
|
888
|
+
</div>
|
|
889
|
+
|
|
890
|
+
|
|
891
|
+
|
|
892
|
+
|
|
893
|
+
|
|
894
|
+
|
|
895
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
896
|
+
<div id="comment-7187775" class="comment">
|
|
897
|
+
<div class="inner">
|
|
898
|
+
<div class="comment-header">
|
|
899
|
+
<div class="asset-meta">
|
|
900
|
+
<span class="byline">
|
|
901
|
+
By
|
|
902
|
+
|
|
903
|
+
<span class="vcard author">NotImpressed</span>
|
|
904
|
+
|
|
905
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7187775"><abbr class="published" title="2011-04-23T16:08:53-08:00">April 23, 2011 4:08 PM</abbr></a>
|
|
906
|
+
|
|
907
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7187775, 'NotImpressed')">Reply</a>
|
|
908
|
+
|
|
909
|
+
</span>
|
|
910
|
+
</div>
|
|
911
|
+
</div>
|
|
912
|
+
<div class="comment-content">
|
|
913
|
+
<p>Your check from Amazon is the mail, tech shill guy. </p>
|
|
914
|
+
</div>
|
|
915
|
+
</div>
|
|
916
|
+
</div>
|
|
917
|
+
|
|
918
|
+
|
|
919
|
+
|
|
920
|
+
|
|
921
|
+
|
|
922
|
+
|
|
923
|
+
|
|
924
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
925
|
+
|
|
926
|
+
|
|
927
|
+
|
|
928
|
+
|
|
929
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
930
|
+
<div id="comment-7188393" class="comment">
|
|
931
|
+
<div class="inner">
|
|
932
|
+
<div class="comment-header">
|
|
933
|
+
<div class="asset-meta">
|
|
934
|
+
<span class="byline">
|
|
935
|
+
By
|
|
936
|
+
|
|
937
|
+
<span class="vcard author">Eric</span>
|
|
938
|
+
|
|
939
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7188393"><abbr class="published" title="2011-04-23T16:44:01-08:00">April 23, 2011 4:44 PM</abbr></a>
|
|
940
|
+
|
|
941
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7188393, 'Eric')">Reply</a>
|
|
942
|
+
|
|
943
|
+
</span>
|
|
944
|
+
</div>
|
|
945
|
+
</div>
|
|
946
|
+
<div class="comment-content">
|
|
947
|
+
<p>"The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider"</p>
|
|
948
|
+
|
|
949
|
+
<p>Sadly, no. That the developers are in charge of this stuff is why so many sites were down completely. They're terrible at it, don't value it, and even when they try to roll it out they do it poorly.</p>
|
|
950
|
+
|
|
951
|
+
<p>An IT guy would have spent 15 minutes on day 1 thinking about disaster recovery. A developer always wants to do it tomorrow and tomorrow, as we all know, never comes.</p>
|
|
952
|
+
</div>
|
|
953
|
+
</div>
|
|
954
|
+
</div>
|
|
955
|
+
|
|
956
|
+
|
|
957
|
+
|
|
958
|
+
|
|
959
|
+
|
|
960
|
+
|
|
961
|
+
|
|
962
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
963
|
+
|
|
964
|
+
|
|
965
|
+
|
|
966
|
+
|
|
967
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
968
|
+
<div id="comment-7188913" class="comment">
|
|
969
|
+
<div class="inner">
|
|
970
|
+
<div class="comment-header">
|
|
971
|
+
<div class="asset-meta">
|
|
972
|
+
<span class="byline">
|
|
973
|
+
By
|
|
974
|
+
|
|
975
|
+
<span class="vcard author">Mike Schinkel</span>
|
|
976
|
+
|
|
977
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7188913"><abbr class="published" title="2011-04-23T17:17:35-08:00">April 23, 2011 5:17 PM</abbr></a>
|
|
978
|
+
|
|
979
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7188913, 'Mike Schinkel')">Reply</a>
|
|
980
|
+
|
|
981
|
+
</span>
|
|
982
|
+
</div>
|
|
983
|
+
</div>
|
|
984
|
+
<div class="comment-content">
|
|
985
|
+
<p>Certainly, you can design for failure. And for those where failure it literally not an option, like things that deal with life-safety or where thousands of dollars are lost every second, sure.</p>
|
|
986
|
+
|
|
987
|
+
<p>But one simple thing you don't address is that doing so is a lot more expensive to design for failure during the development cycle. Yes, any bridge across troubled water can be over-built to ensure that it never, ever fails, but doing so is often so cost-prohibitive as to be unrealistic.</p>
|
|
988
|
+
|
|
989
|
+
<p>And lastly, your advocacy would have sounded more credible if you had stated up-front that you are CTO of a company that purposes to help people solve this problem in exchange for mucho deniro rather than bury that fact in the middle of the article.</p>
|
|
990
|
+
</div>
|
|
991
|
+
</div>
|
|
992
|
+
</div>
|
|
993
|
+
|
|
994
|
+
|
|
995
|
+
|
|
996
|
+
|
|
997
|
+
|
|
998
|
+
|
|
999
|
+
|
|
1000
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
1001
|
+
|
|
1002
|
+
|
|
1003
|
+
|
|
1004
|
+
|
|
1005
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
1006
|
+
<div id="comment-7189921" class="comment">
|
|
1007
|
+
<div class="inner">
|
|
1008
|
+
<div class="comment-header">
|
|
1009
|
+
<div class="asset-meta">
|
|
1010
|
+
<span class="byline">
|
|
1011
|
+
By
|
|
1012
|
+
|
|
1013
|
+
<span class="vcard author">anon</span>
|
|
1014
|
+
|
|
1015
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7189921"><abbr class="published" title="2011-04-23T19:25:39-08:00">April 23, 2011 7:25 PM</abbr></a>
|
|
1016
|
+
|
|
1017
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7189921, 'anon')">Reply</a>
|
|
1018
|
+
|
|
1019
|
+
</span>
|
|
1020
|
+
</div>
|
|
1021
|
+
</div>
|
|
1022
|
+
<div class="comment-content">
|
|
1023
|
+
<p>"In short, if your systems failed in the Amazon cloud this week, it wasn't Amazon's fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon's cloud computing model."</p>
|
|
1024
|
+
|
|
1025
|
+
<p>Oh yes, a company would provide you a cloud service to host your data and when that very service fails and renders your own operation useless it is your fault. So why pay for their service in the first place?</p>
|
|
1026
|
+
|
|
1027
|
+
<p>This sounded like an argument made by either a total irrational fanatic, or another network guy who is clueless about creating software, or both. Seems like outages these days are always the fault of the software developer(s) and never that of the one maintaining the network resource. </p>
|
|
1028
|
+
|
|
1029
|
+
<p>Anybody with common sense should stop reading right after that quoted sentence.</p>
|
|
1030
|
+
</div>
|
|
1031
|
+
</div>
|
|
1032
|
+
</div>
|
|
1033
|
+
|
|
1034
|
+
|
|
1035
|
+
<!-- Loop through the reply comments -->
|
|
1036
|
+
|
|
1037
|
+
<div style="margin-left: 20px;">
|
|
1038
|
+
|
|
1039
|
+
<div id="comment-7190021" class="comment comment-reply">
|
|
1040
|
+
<div class="inner">
|
|
1041
|
+
<div class="comment-header">
|
|
1042
|
+
<div class="asset-meta">
|
|
1043
|
+
<span class="byline">
|
|
1044
|
+
By
|
|
1045
|
+
|
|
1046
|
+
<span class="vcard author">Eric</span> in reply to <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7189921">comment from anon</a>
|
|
1047
|
+
|
|
1048
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7190021"><abbr class="published" title="2011-04-23T19:45:57-08:00">April 23, 2011 7:45 PM</abbr></a>
|
|
1049
|
+
|
|
1050
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7190021, 'Eric')">Reply</a>
|
|
1051
|
+
|
|
1052
|
+
</span>
|
|
1053
|
+
</div>
|
|
1054
|
+
</div>
|
|
1055
|
+
<div class="comment-content">
|
|
1056
|
+
<p>Well it's the fault of the software developers for thinking they don't need "clueless network guys"</p>
|
|
1057
|
+
|
|
1058
|
+
<p>You realize "in th3 cloud!!! ZOMG we're in cloud!!!" means nothing more than you're running a virtual machine in a data center somewhere. That's all amazon does. It's not magic - you're not safe because you're "in the cloud."</p>
|
|
1059
|
+
|
|
1060
|
+
<p>It's just a datacenter. That most software engineers don't know that is why they need "clueless network guys" to point it out to them.</p>
|
|
1061
|
+
</div>
|
|
1062
|
+
</div>
|
|
1063
|
+
</div>
|
|
1064
|
+
|
|
1065
|
+
|
|
1066
|
+
<!-- For each reply comment, recursively display any reply comments -->
|
|
1067
|
+
|
|
1068
|
+
</div>
|
|
1069
|
+
|
|
1070
|
+
|
|
1071
|
+
|
|
1072
|
+
|
|
1073
|
+
|
|
1074
|
+
|
|
1075
|
+
<!-- If comment has a parent comment. We ignore this, as we just want the top-level-parent comments -->
|
|
1076
|
+
|
|
1077
|
+
|
|
1078
|
+
|
|
1079
|
+
|
|
1080
|
+
<!-- If comment doesn't have a top-level-parent -->
|
|
1081
|
+
<div id="comment-7190068" class="comment">
|
|
1082
|
+
<div class="inner">
|
|
1083
|
+
<div class="comment-header">
|
|
1084
|
+
<div class="asset-meta">
|
|
1085
|
+
<span class="byline">
|
|
1086
|
+
By
|
|
1087
|
+
|
|
1088
|
+
<span class="vcard author">Abol</span>
|
|
1089
|
+
|
|
1090
|
+
on <a href="http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html#comment-7190068"><abbr class="published" title="2011-04-23T19:53:28-08:00">April 23, 2011 7:53 PM</abbr></a>
|
|
1091
|
+
|
|
1092
|
+
| <a title="Reply" href="javascript:void(0);" onclick="mtReplyCommentOnClick(7190068, 'Abol')">Reply</a>
|
|
1093
|
+
|
|
1094
|
+
</span>
|
|
1095
|
+
</div>
|
|
1096
|
+
</div>
|
|
1097
|
+
<div class="comment-content">
|
|
1098
|
+
<p>"100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage."</p>
|
|
1099
|
+
|
|
1100
|
+
<p>The problem was Amazon had multiple data centers fail simultaneously. Your comments ridiculing people for not being smart enough to span multiple *regions* are a bit strained. According to Amazon's docs, spanning multiple data centers within a single region should have been sufficient to guard against failures short of a regional natural disaster.</p>
|
|
1101
|
+
|
|
1102
|
+
<p>So far, it looks like Amazon did not architect their systems to properly isolate data centers from one another, namely by allowing an EBS failure in one center to cascade to others via a single region-wide failure point. Customers bear only limited blame for expecting them to adhere to their stated architectural principles. If Amazon had instead made an even larger goof and architected a single *global* failure point for EBS, this outage would have cascaded to the other regions as well, and your argument would be completely moot.</p>
|
|
1103
|
+
|
|
1104
|
+
<p>It is Amazon's fault for not properly isolating data centers. It is customers' fault only to the extent that they relied on Amazon as their exclusive host -- not that they failed to understand how to architect their apps as per Amazon's guidelines. <br />
|
|
1105
|
+
</p>
|
|
1106
|
+
</div>
|
|
1107
|
+
</div>
|
|
1108
|
+
</div>
|
|
1109
|
+
|
|
1110
|
+
|
|
1111
|
+
|
|
1112
|
+
|
|
1113
|
+
|
|
1114
|
+
</div>
|
|
1115
|
+
|
|
1116
|
+
|
|
1117
|
+
|
|
1118
|
+
<div class="comments-open" id="comments-open">
|
|
1119
|
+
|
|
1120
|
+
<h2 class="comments-open-header">Leave a comment</h2>
|
|
1121
|
+
|
|
1122
|
+
<div id="comment-form-reply" style="display:none">
|
|
1123
|
+
<input type="checkbox" id="comment-reply" name="comment_reply" value="" onclick="mtSetCommentParentID()" />
|
|
1124
|
+
<label for="comment-reply" id="comment-reply-label"></label>
|
|
1125
|
+
</div>
|
|
1126
|
+
<br />
|
|
1127
|
+
<div class="comments-open-content">
|
|
1128
|
+
|
|
1129
|
+
<form method="post" action="http://blogs.oreilly.com/cgi-bin/mt/mt-c.cgi" name="comments_form" id="comments-form" onsubmit="if (this.bakecookie.checked) rememberMe(this)">
|
|
1130
|
+
<input type="hidden" name="static" value="1" />
|
|
1131
|
+
<input type="hidden" name="entry_id" value="46231" />
|
|
1132
|
+
<input type="hidden" name="__lang" value="en" />
|
|
1133
|
+
<input type="hidden" name="parent_id" value="" id="comment-parent-id" /> <div id="comments-open-data">
|
|
1134
|
+
<div id="comment-form-name">
|
|
1135
|
+
<label for="comment-author">Name</label>
|
|
1136
|
+
<input id="comment-author" name="author" size="30" value="" />
|
|
1137
|
+
</div>
|
|
1138
|
+
<div id="comment-form-email">
|
|
1139
|
+
<label for="comment-email">Email Address</label>
|
|
1140
|
+
<input id="comment-email" name="email" size="30" value="" />
|
|
1141
|
+
</div>
|
|
1142
|
+
|
|
1143
|
+
<div id="comment-form-remember-me">
|
|
1144
|
+
<label for="comment-bake-cookie"><input type="checkbox" id="comment-bake-cookie" name="bakecookie" onclick="if (!this.checked) forgetMe(document.comments_form)" value="1" />
|
|
1145
|
+
Remember personal info?</label>
|
|
1146
|
+
</div>
|
|
1147
|
+
</div>
|
|
1148
|
+
<div id="comments-open-text">
|
|
1149
|
+
<label for="comment-text">Comments (You may use HTML tags for style)</label>
|
|
1150
|
+
<textarea id="comment-text" name="text" rows="15" cols="50"></textarea>
|
|
1151
|
+
</div>
|
|
1152
|
+
|
|
1153
|
+
<p id="comments-open-challenge"><input type="hidden" id="commchallenge_beacon" name="commchallenge_beacon" value="1" /><label for="commchallenge_answer">Type the word BLOG below. <strong>(required)</strong>:</label><br /><input type="text" id="commchallenge_answer" name="commchallenge_answer" /></p><script type="text/javascript">
|
|
1154
|
+
<!--
|
|
1155
|
+
if ((typeof commenter_name != 'undefined') ||
|
|
1156
|
+
(typeof getCommenterName != 'undefined' && getCommenterName())) {
|
|
1157
|
+
mtHide('comments-open-challenge');
|
|
1158
|
+
} else {
|
|
1159
|
+
mtShow('comments-open-challenge');
|
|
1160
|
+
}
|
|
1161
|
+
// -->
|
|
1162
|
+
</script>
|
|
1163
|
+
|
|
1164
|
+
|
|
1165
|
+
<div id="comments-open-footer">
|
|
1166
|
+
<!--input type="submit" accesskey="v" name="preview" id="comment-preview" value="Preview" /-->
|
|
1167
|
+
<input type="submit" accesskey="s" name="post" id="comment-submit" value="Submit" />
|
|
1168
|
+
|
|
1169
|
+
</div>
|
|
1170
|
+
</form>
|
|
1171
|
+
</div>
|
|
1172
|
+
</div>
|
|
1173
|
+
|
|
1174
|
+
|
|
1175
|
+
|
|
1176
|
+
</div>
|
|
1177
|
+
</div>
|
|
1178
|
+
|
|
1179
|
+
</div>
|
|
1180
|
+
|
|
1181
|
+
|
|
1182
|
+
|
|
1183
|
+
</div>
|
|
1184
|
+
</div>
|
|
1185
|
+
|
|
1186
|
+
<div id="beta">
|
|
1187
|
+
<div id="beta-inner">
|
|
1188
|
+
|
|
1189
|
+
<div class="widget-left">
|
|
1190
|
+
<h3>Popular Topics</h3>
|
|
1191
|
+
|
|
1192
|
+
<style type="text/css">
|
|
1193
|
+
#popular a{
|
|
1194
|
+
text-decoration: none;
|
|
1195
|
+
color: #990000;
|
|
1196
|
+
font-size:10px;
|
|
1197
|
+
}
|
|
1198
|
+
|
|
1199
|
+
#popular td {
|
|
1200
|
+
padding:1px;
|
|
1201
|
+
}
|
|
1202
|
+
#popular {
|
|
1203
|
+
padding-top:8px;
|
|
1204
|
+
}
|
|
1205
|
+
</style>
|
|
1206
|
+
<table id="popular" width="176">
|
|
1207
|
+
<tr>
|
|
1208
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/javascript/index.html">JavaScript</a></td>
|
|
1209
|
+
<td><a href="http://oreilly.com/iphone/index.html">iPhone</a></td>
|
|
1210
|
+
</tr>
|
|
1211
|
+
<tr>
|
|
1212
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/android/index.html">Android</a></td>
|
|
1213
|
+
<td><a href="http://oreilly.com/python/index.html">Python</a></td>
|
|
1214
|
+
</tr>
|
|
1215
|
+
<tr>
|
|
1216
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/css-html/index.html">HTML5 & CSS</a></td>
|
|
1217
|
+
<td><a href="http://headfirstlabs.com/">Head First</a></td>
|
|
1218
|
+
</tr>
|
|
1219
|
+
<tr>
|
|
1220
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/jquery/index.html">jQuery</a></td>
|
|
1221
|
+
<td><a href="http://oreilly.com/java/index.html">Java</a></td>
|
|
1222
|
+
</tr>
|
|
1223
|
+
<tr>
|
|
1224
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/ipad/index.html">iPad</a></td>
|
|
1225
|
+
<td><a href="http://oreilly.com/php/index.html">PHP</a></td>
|
|
1226
|
+
</tr>
|
|
1227
|
+
<tr>
|
|
1228
|
+
<td style="padding-right:12px;"><a href="http://oreilly.com/perl/index.html">Perl</a></td>
|
|
1229
|
+
<td><a href="http://oreilly.com/linux/index.html">Linux</a></td>
|
|
1230
|
+
</tr>
|
|
1231
|
+
</table>
|
|
1232
|
+
|
|
1233
|
+
</div>
|
|
1234
|
+
|
|
1235
|
+
<style>
|
|
1236
|
+
#bbooks {
|
|
1237
|
+
font-size: 10.8px;
|
|
1238
|
+
}
|
|
1239
|
+
#bbooks ul, #bbooks li {
|
|
1240
|
+
list-style-image:none;
|
|
1241
|
+
list-style-position:outside;
|
|
1242
|
+
list-style-type:none;
|
|
1243
|
+
margin:0pt;
|
|
1244
|
+
padding:0pt;
|
|
1245
|
+
}
|
|
1246
|
+
#bbooks li {
|
|
1247
|
+
display:inline;
|
|
1248
|
+
}
|
|
1249
|
+
#bbooks ul li a {
|
|
1250
|
+
border-bottom:1px solid #AAAAAA;
|
|
1251
|
+
color:#990000;
|
|
1252
|
+
display:block;
|
|
1253
|
+
margin:0pt;
|
|
1254
|
+
padding:4px 6px;
|
|
1255
|
+
text-decoration:none;
|
|
1256
|
+
}
|
|
1257
|
+
#bbooks ul ul li a {
|
|
1258
|
+
color:#666666;
|
|
1259
|
+
padding-left:18px;
|
|
1260
|
+
}
|
|
1261
|
+
#bbooks ul li a:hover {
|
|
1262
|
+
background-color:#F6F6F6;
|
|
1263
|
+
}
|
|
1264
|
+
#bbooks a.selected {
|
|
1265
|
+
background-color:#ECECEC;
|
|
1266
|
+
}
|
|
1267
|
+
|
|
1268
|
+
#bbooks ul li a {
|
|
1269
|
+
border-bottom:1px solid #AAAAAA;
|
|
1270
|
+
color:#990000;
|
|
1271
|
+
display:block;
|
|
1272
|
+
margin:0pt;
|
|
1273
|
+
padding:4px 6px;
|
|
1274
|
+
text-decoration:none;
|
|
1275
|
+
}
|
|
1276
|
+
#bbooks a, a:visited {
|
|
1277
|
+
text-decoration:none;
|
|
1278
|
+
}
|
|
1279
|
+
.rolldown {
|
|
1280
|
+
background:#F6F6F6 url(http://oreilly.com/images/oreilly/bullet_menu_open.gif) no-repeat scroll 6px 50%;
|
|
1281
|
+
padding-left:18px !important;
|
|
1282
|
+
}
|
|
1283
|
+
#bbooks a {
|
|
1284
|
+
color:#0000FF;
|
|
1285
|
+
}
|
|
1286
|
+
#bbooks a, a:visited {
|
|
1287
|
+
text-decoration:none;
|
|
1288
|
+
}
|
|
1289
|
+
|
|
1290
|
+
.hideSwitch {
|
|
1291
|
+
display:none;
|
|
1292
|
+
}
|
|
1293
|
+
|
|
1294
|
+
.showSwitch {
|
|
1295
|
+
display:block;
|
|
1296
|
+
}
|
|
1297
|
+
|
|
1298
|
+
.rollup {
|
|
1299
|
+
padding-left:18px !important;
|
|
1300
|
+
background:#fff url(http://oreilly.com/images/oreilly/bullet_menu.gif) no-repeat 6px;
|
|
1301
|
+
}
|
|
1302
|
+
|
|
1303
|
+
.rolldown {
|
|
1304
|
+
padding-left:18px !important;
|
|
1305
|
+
background:#F6F6F6 url(http://oreilly.com/images/oreilly/bullet_menu_open.gif) no-repeat 6px;
|
|
1306
|
+
}
|
|
1307
|
+
|
|
1308
|
+
.showtopic {
|
|
1309
|
+
padding-left:25px !important;
|
|
1310
|
+
}
|
|
1311
|
+
|
|
1312
|
+
</style>
|
|
1313
|
+
|
|
1314
|
+
|
|
1315
|
+
|
|
1316
|
+
<div class="widget-left"><h3>Browse Books</h3><div id="bbooks">
|
|
1317
|
+
<ul>
|
|
1318
|
+
<li><a href="#" onclick="toggleSheet('business'); return true" id="businessButton" class="rollup">Business & Culture</a>
|
|
1319
|
+
<ul id="business">
|
|
1320
|
+
<li>
|
|
1321
|
+
|
|
1322
|
+
<a href="http://oreilly.com/pub/topic/business" class="showtopic">
|
|
1323
|
+
|
|
1324
|
+
Business</a> </li>
|
|
1325
|
+
<li>
|
|
1326
|
+
|
|
1327
|
+
<a href="http://oreilly.com/pub/topic/culture" class="showtopic">
|
|
1328
|
+
|
|
1329
|
+
Digital Culture</a> </li>
|
|
1330
|
+
<li>
|
|
1331
|
+
|
|
1332
|
+
<a href="http://oreilly.com/pub/topic/finance" class="showtopic">
|
|
1333
|
+
|
|
1334
|
+
|
|
1335
|
+
Personal Finance</a> </li>
|
|
1336
|
+
<li>
|
|
1337
|
+
|
|
1338
|
+
<a href="http://oreilly.com/pub/topic/projectmanagement" class="showtopic">
|
|
1339
|
+
|
|
1340
|
+
Project & Career Management</a> </li>
|
|
1341
|
+
<li>
|
|
1342
|
+
|
|
1343
|
+
<a href="http://oreilly.com/pub/topic/socialmedia" class="showtopic">
|
|
1344
|
+
|
|
1345
|
+
Social Media</a> </li>
|
|
1346
|
+
|
|
1347
|
+
</ul>
|
|
1348
|
+
</li>
|
|
1349
|
+
<li><a href="#" onclick="toggleSheet('databases'); return false" id="databasesButton" class="rollup">Databases</a>
|
|
1350
|
+
<ul id="databases">
|
|
1351
|
+
<li>
|
|
1352
|
+
|
|
1353
|
+
<a href="http://oreilly.com/pub/topic/access" class="showtopic">
|
|
1354
|
+
|
|
1355
|
+
Access</a> </li>
|
|
1356
|
+
<li>
|
|
1357
|
+
|
|
1358
|
+
<a href="http://oreilly.com/pub/topic/mysql" class="showtopic">
|
|
1359
|
+
|
|
1360
|
+
|
|
1361
|
+
MySQL</a> </li>
|
|
1362
|
+
<li>
|
|
1363
|
+
|
|
1364
|
+
<a href="http://oreilly.com/pub/topic/oracle" class="showtopic">
|
|
1365
|
+
|
|
1366
|
+
Oracle</a> </li>
|
|
1367
|
+
<li>
|
|
1368
|
+
|
|
1369
|
+
<a href="http://oreilly.com/pub/topic/otherdatabases" class="showtopic">
|
|
1370
|
+
|
|
1371
|
+
Other Databases</a> </li>
|
|
1372
|
+
|
|
1373
|
+
<li>
|
|
1374
|
+
|
|
1375
|
+
<a href="http://oreilly.com/pub/topic/sql" class="showtopic">
|
|
1376
|
+
|
|
1377
|
+
SQL</a> </li>
|
|
1378
|
+
<li>
|
|
1379
|
+
|
|
1380
|
+
<a href="http://oreilly.com/pub/topic/sqlserver" class="showtopic">
|
|
1381
|
+
|
|
1382
|
+
SQL Server</a> </li>
|
|
1383
|
+
<li>
|
|
1384
|
+
|
|
1385
|
+
<a href="http://oreilly.com/pub/topic/theory" class="showtopic">
|
|
1386
|
+
|
|
1387
|
+
|
|
1388
|
+
Theory</a> </li>
|
|
1389
|
+
|
|
1390
|
+
</ul>
|
|
1391
|
+
</li>
|
|
1392
|
+
<li><a href="#" onclick="toggleSheet('design'); return false" id="designButton" class="rollup">Design & Graphics</a>
|
|
1393
|
+
<ul id="design">
|
|
1394
|
+
<li>
|
|
1395
|
+
|
|
1396
|
+
<a href="http://oreilly.com/pub/topic/adobecs3" class="showtopic">
|
|
1397
|
+
|
|
1398
|
+
Adobe CS3</a> </li>
|
|
1399
|
+
|
|
1400
|
+
<li>
|
|
1401
|
+
|
|
1402
|
+
<a href="http://oreilly.com/pub/topic/adobecs4" class="showtopic">
|
|
1403
|
+
|
|
1404
|
+
Adobe CS4</a> </li>
|
|
1405
|
+
<li>
|
|
1406
|
+
|
|
1407
|
+
<a href="http://oreilly.com/pub/topic/flash" class="showtopic">
|
|
1408
|
+
|
|
1409
|
+
Flash & Actionscript</a> </li>
|
|
1410
|
+
<li>
|
|
1411
|
+
|
|
1412
|
+
<a href="http://oreilly.com/pub/topic/graphics" class="showtopic">
|
|
1413
|
+
|
|
1414
|
+
Illustration & Graphics</a> </li>
|
|
1415
|
+
<li>
|
|
1416
|
+
|
|
1417
|
+
<a href="http://oreilly.com/pub/topic/photomanipulation" class="showtopic">
|
|
1418
|
+
|
|
1419
|
+
Photoshop & Photomanipulation</a> </li>
|
|
1420
|
+
|
|
1421
|
+
<li>
|
|
1422
|
+
|
|
1423
|
+
<a href="http://oreilly.com/pub/topic/printdesign" class="showtopic">
|
|
1424
|
+
|
|
1425
|
+
Print Design</a> </li>
|
|
1426
|
+
|
|
1427
|
+
</ul>
|
|
1428
|
+
</li>
|
|
1429
|
+
<li><a href="#" onclick="toggleSheet('audiovideo'); return false" id="audiovideoButton" class="rollup">Digital Audio & Video</a>
|
|
1430
|
+
<ul id="audiovideo">
|
|
1431
|
+
<li>
|
|
1432
|
+
|
|
1433
|
+
<a href="http://oreilly.com/pub/topic/digitalaudio" class="showtopic">
|
|
1434
|
+
|
|
1435
|
+
Digital Audio</a> </li>
|
|
1436
|
+
<li>
|
|
1437
|
+
|
|
1438
|
+
<a href="http://oreilly.com/pub/topic/digitalvideo" class="showtopic">
|
|
1439
|
+
|
|
1440
|
+
Digital Video</a> </li>
|
|
1441
|
+
|
|
1442
|
+
</ul>
|
|
1443
|
+
</li>
|
|
1444
|
+
<li><a href="#" onclick="toggleSheet('photography'); return false" id="photographyButton" class="rollup">Digital Photography</a>
|
|
1445
|
+
|
|
1446
|
+
<ul id="photography">
|
|
1447
|
+
<li>
|
|
1448
|
+
|
|
1449
|
+
<a href="http://oreilly.com/pub/topic/adobecs3" class="showtopic">
|
|
1450
|
+
|
|
1451
|
+
Adobe CS3</a> </li>
|
|
1452
|
+
<li>
|
|
1453
|
+
|
|
1454
|
+
<a href="http://oreilly.com/pub/topic/adobecs4" class="showtopic">
|
|
1455
|
+
|
|
1456
|
+
Adobe CS4</a> </li>
|
|
1457
|
+
<li>
|
|
1458
|
+
|
|
1459
|
+
<a href="http://oreilly.com/pub/topic/digiphoto" class="showtopic">
|
|
1460
|
+
|
|
1461
|
+
Digital Photography</a> </li>
|
|
1462
|
+
<li>
|
|
1463
|
+
|
|
1464
|
+
<a href="http://oreilly.com/pub/topic/photomanipulation" class="showtopic">
|
|
1465
|
+
|
|
1466
|
+
Photoshop & Photomanipulation</a> </li>
|
|
1467
|
+
|
|
1468
|
+
</ul>
|
|
1469
|
+
</li>
|
|
1470
|
+
|
|
1471
|
+
<li><a href="#" onclick="toggleSheet('hardware'); return false" id="hardwareButton" class="rollup">Hardware</a>
|
|
1472
|
+
<ul id="hardware">
|
|
1473
|
+
<li>
|
|
1474
|
+
|
|
1475
|
+
<a href="http://oreilly.com/pub/topic/devices" class="showtopic">
|
|
1476
|
+
|
|
1477
|
+
Devices & Peripherals</a> </li>
|
|
1478
|
+
<li>
|
|
1479
|
+
|
|
1480
|
+
<a href="http://oreilly.com/pub/topic/hardwarehacking" class="showtopic">
|
|
1481
|
+
|
|
1482
|
+
Hacks & Modifications</a> </li>
|
|
1483
|
+
|
|
1484
|
+
<li>
|
|
1485
|
+
|
|
1486
|
+
<a href="http://oreilly.com/pub/topic/pchardware" class="showtopic">
|
|
1487
|
+
|
|
1488
|
+
PC Hardware</a> </li>
|
|
1489
|
+
|
|
1490
|
+
</ul>
|
|
1491
|
+
</li>
|
|
1492
|
+
<li><a href="#" onclick="toggleSheet('homeoffice'); return false" id="homeofficeButton" class="rollup">Home & Office</a>
|
|
1493
|
+
<ul id="homeoffice">
|
|
1494
|
+
<li>
|
|
1495
|
+
|
|
1496
|
+
<a href="http://oreilly.com/pub/topic/security" class="showtopic">
|
|
1497
|
+
|
|
1498
|
+
Computer Security & Privacy</a> </li>
|
|
1499
|
+
<li>
|
|
1500
|
+
|
|
1501
|
+
<a href="http://oreilly.com/pub/topic/games" class="showtopic">
|
|
1502
|
+
|
|
1503
|
+
Games</a> </li>
|
|
1504
|
+
<li>
|
|
1505
|
+
|
|
1506
|
+
<a href="http://oreilly.com/pub/topic/homeentertainment" class="showtopic">
|
|
1507
|
+
|
|
1508
|
+
|
|
1509
|
+
Home Entertainment</a> </li>
|
|
1510
|
+
<li>
|
|
1511
|
+
|
|
1512
|
+
<a href="http://oreilly.com/pub/topic/homenetworking" class="showtopic">
|
|
1513
|
+
|
|
1514
|
+
Home Networking</a> </li>
|
|
1515
|
+
<li>
|
|
1516
|
+
|
|
1517
|
+
<a href="http://oreilly.com/pub/topic/mac" class="showtopic">
|
|
1518
|
+
|
|
1519
|
+
Mac OS X</a> </li>
|
|
1520
|
+
|
|
1521
|
+
<li>
|
|
1522
|
+
|
|
1523
|
+
<a href="http://oreilly.com/pub/topic/macprograms" class="showtopic">
|
|
1524
|
+
|
|
1525
|
+
Macintosh Programs</a> </li>
|
|
1526
|
+
<li>
|
|
1527
|
+
|
|
1528
|
+
<a href="http://oreilly.com/pub/topic/pchardware" class="showtopic">
|
|
1529
|
+
|
|
1530
|
+
PC Hardware</a> </li>
|
|
1531
|
+
<li>
|
|
1532
|
+
|
|
1533
|
+
<a href="http://oreilly.com/pub/topic/finance" class="showtopic">
|
|
1534
|
+
|
|
1535
|
+
|
|
1536
|
+
Personal Finance</a> </li>
|
|
1537
|
+
<li>
|
|
1538
|
+
|
|
1539
|
+
<a href="http://oreilly.com/pub/topic/windows" class="showtopic">
|
|
1540
|
+
|
|
1541
|
+
Windows 2000 & earlier</a> </li>
|
|
1542
|
+
<li>
|
|
1543
|
+
|
|
1544
|
+
<a href="http://oreilly.com/pub/topic/windows7" class="showtopic">
|
|
1545
|
+
|
|
1546
|
+
Windows 7</a> </li>
|
|
1547
|
+
|
|
1548
|
+
<li>
|
|
1549
|
+
|
|
1550
|
+
<a href="http://oreilly.com/pub/topic/windowsprograms" class="showtopic">
|
|
1551
|
+
|
|
1552
|
+
Windows Programs</a> </li>
|
|
1553
|
+
<li>
|
|
1554
|
+
|
|
1555
|
+
<a href="http://oreilly.com/pub/topic/windowsvista" class="showtopic">
|
|
1556
|
+
|
|
1557
|
+
Windows Vista</a> </li>
|
|
1558
|
+
<li>
|
|
1559
|
+
|
|
1560
|
+
<a href="http://oreilly.com/pub/topic/windowsxp" class="showtopic">
|
|
1561
|
+
|
|
1562
|
+
|
|
1563
|
+
Windows XP</a> </li>
|
|
1564
|
+
|
|
1565
|
+
</ul>
|
|
1566
|
+
</li>
|
|
1567
|
+
<li><a href="#" onclick="toggleSheet('sysadmin'); return false" id="sysadminButton" class="rollup">Networking & Sys Admin</a>
|
|
1568
|
+
<ul id="sysadmin">
|
|
1569
|
+
<li>
|
|
1570
|
+
|
|
1571
|
+
<a href="http://oreilly.com/pub/topic/apache" class="showtopic">
|
|
1572
|
+
|
|
1573
|
+
Apache</a> </li>
|
|
1574
|
+
|
|
1575
|
+
<li>
|
|
1576
|
+
|
|
1577
|
+
<a href="http://oreilly.com/pub/topic/certification" class="showtopic">
|
|
1578
|
+
|
|
1579
|
+
Certification</a> </li>
|
|
1580
|
+
<li>
|
|
1581
|
+
|
|
1582
|
+
<a href="http://oreilly.com/pub/topic/cisco" class="showtopic">
|
|
1583
|
+
|
|
1584
|
+
Cisco & other Routers</a> </li>
|
|
1585
|
+
<li>
|
|
1586
|
+
|
|
1587
|
+
<a href="http://oreilly.com/pub/topic/email" class="showtopic">
|
|
1588
|
+
|
|
1589
|
+
Email</a> </li>
|
|
1590
|
+
<li>
|
|
1591
|
+
|
|
1592
|
+
<a href="http://oreilly.com/pub/topic/homenetworking" class="showtopic">
|
|
1593
|
+
|
|
1594
|
+
Home Networking</a> </li>
|
|
1595
|
+
<li>
|
|
1596
|
+
|
|
1597
|
+
<a href="http://oreilly.com/pub/topic/projectmanagement" class="showtopic">
|
|
1598
|
+
|
|
1599
|
+
|
|
1600
|
+
Project & Career Management</a> </li>
|
|
1601
|
+
<li>
|
|
1602
|
+
|
|
1603
|
+
<a href="http://oreilly.com/pub/topic/protocols" class="showtopic">
|
|
1604
|
+
|
|
1605
|
+
Protocols</a> </li>
|
|
1606
|
+
<li>
|
|
1607
|
+
|
|
1608
|
+
<a href="http://oreilly.com/pub/topic/serveradmin" class="showtopic">
|
|
1609
|
+
|
|
1610
|
+
Server Administration</a> </li>
|
|
1611
|
+
|
|
1612
|
+
<li>
|
|
1613
|
+
|
|
1614
|
+
<a href="http://oreilly.com/pub/topic/serversecurity" class="showtopic">
|
|
1615
|
+
|
|
1616
|
+
Server Security</a> </li>
|
|
1617
|
+
<li>
|
|
1618
|
+
|
|
1619
|
+
<a href="http://oreilly.com/pub/topic/spam" class="showtopic">
|
|
1620
|
+
|
|
1621
|
+
Spam</a> </li>
|
|
1622
|
+
<li>
|
|
1623
|
+
|
|
1624
|
+
<a href="http://oreilly.com/pub/topic/telephony" class="showtopic">
|
|
1625
|
+
|
|
1626
|
+
|
|
1627
|
+
Telephony</a> </li>
|
|
1628
|
+
<li>
|
|
1629
|
+
|
|
1630
|
+
<a href="http://oreilly.com/pub/topic/wireless" class="showtopic">
|
|
1631
|
+
|
|
1632
|
+
Wireless</a> </li>
|
|
1633
|
+
|
|
1634
|
+
</ul>
|
|
1635
|
+
</li>
|
|
1636
|
+
<li><a href="#" onclick="toggleSheet('os'); return false" id="osButton" class="rollup">Operating Systems</a>
|
|
1637
|
+
<ul id="os">
|
|
1638
|
+
<li>
|
|
1639
|
+
|
|
1640
|
+
<a href="http://oreilly.com/pub/topic/linux" class="showtopic">
|
|
1641
|
+
|
|
1642
|
+
Linux/Unix</a> </li>
|
|
1643
|
+
<li>
|
|
1644
|
+
|
|
1645
|
+
<a href="http://oreilly.com/pub/topic/mac" class="showtopic">
|
|
1646
|
+
|
|
1647
|
+
Mac OS X</a> </li>
|
|
1648
|
+
<li>
|
|
1649
|
+
|
|
1650
|
+
<a href="http://oreilly.com/pub/topic/windows" class="showtopic">
|
|
1651
|
+
|
|
1652
|
+
|
|
1653
|
+
Windows 2000 & earlier</a> </li>
|
|
1654
|
+
<li>
|
|
1655
|
+
|
|
1656
|
+
<a href="http://oreilly.com/pub/topic/windows7" class="showtopic">
|
|
1657
|
+
|
|
1658
|
+
Windows 7</a> </li>
|
|
1659
|
+
<li>
|
|
1660
|
+
|
|
1661
|
+
<a href="http://oreilly.com/pub/topic/windowsvista" class="showtopic">
|
|
1662
|
+
|
|
1663
|
+
Windows Vista</a> </li>
|
|
1664
|
+
|
|
1665
|
+
<li>
|
|
1666
|
+
|
|
1667
|
+
<a href="http://oreilly.com/pub/topic/windowsxp" class="showtopic">
|
|
1668
|
+
|
|
1669
|
+
Windows XP</a> </li>
|
|
1670
|
+
|
|
1671
|
+
</ul>
|
|
1672
|
+
</li>
|
|
1673
|
+
<li><a href="#" onclick="toggleSheet('programming'); return false" id="programmingButton" class="rollup">Programming</a>
|
|
1674
|
+
<ul id="programming">
|
|
1675
|
+
<li>
|
|
1676
|
+
|
|
1677
|
+
<a href="http://oreilly.com/pub/topic/dotnet" class="showtopic">
|
|
1678
|
+
|
|
1679
|
+
|
|
1680
|
+
.NET & Windows Programming</a> </li>
|
|
1681
|
+
<li>
|
|
1682
|
+
|
|
1683
|
+
<a href="http://oreilly.com/pub/topic/ajax" class="showtopic">
|
|
1684
|
+
|
|
1685
|
+
Ajax</a> </li>
|
|
1686
|
+
<li>
|
|
1687
|
+
|
|
1688
|
+
<a href="http://oreilly.com/pub/topic/csharp" class="showtopic">
|
|
1689
|
+
|
|
1690
|
+
C#</a> </li>
|
|
1691
|
+
|
|
1692
|
+
<li>
|
|
1693
|
+
|
|
1694
|
+
<a href="http://oreilly.com/pub/topic/cprog" class="showtopic">
|
|
1695
|
+
|
|
1696
|
+
C/C++</a> </li>
|
|
1697
|
+
<li>
|
|
1698
|
+
|
|
1699
|
+
<a href="http://oreilly.com/pub/topic/certification" class="showtopic">
|
|
1700
|
+
|
|
1701
|
+
Certification</a> </li>
|
|
1702
|
+
<li>
|
|
1703
|
+
|
|
1704
|
+
<a href="http://oreilly.com/pub/topic/games" class="showtopic">
|
|
1705
|
+
|
|
1706
|
+
|
|
1707
|
+
Games</a> </li>
|
|
1708
|
+
<li>
|
|
1709
|
+
|
|
1710
|
+
<a href="http://oreilly.com/pub/topic/java" class="showtopic">
|
|
1711
|
+
|
|
1712
|
+
Java</a> </li>
|
|
1713
|
+
<li>
|
|
1714
|
+
|
|
1715
|
+
<a href="http://oreilly.com/pub/topic/otherprogramming" class="showtopic">
|
|
1716
|
+
|
|
1717
|
+
Other Programming</a> </li>
|
|
1718
|
+
|
|
1719
|
+
<li>
|
|
1720
|
+
|
|
1721
|
+
<a href="http://oreilly.com/pub/topic/perl" class="showtopic">
|
|
1722
|
+
|
|
1723
|
+
Perl</a> </li>
|
|
1724
|
+
<li>
|
|
1725
|
+
|
|
1726
|
+
<a href="http://oreilly.com/pub/topic/php" class="showtopic">
|
|
1727
|
+
|
|
1728
|
+
PHP</a> </li>
|
|
1729
|
+
<li>
|
|
1730
|
+
|
|
1731
|
+
<a href="http://oreilly.com/pub/topic/projectmanagement" class="showtopic">
|
|
1732
|
+
|
|
1733
|
+
|
|
1734
|
+
Project & Career Management</a> </li>
|
|
1735
|
+
<li>
|
|
1736
|
+
|
|
1737
|
+
<a href="http://oreilly.com/pub/topic/python" class="showtopic">
|
|
1738
|
+
|
|
1739
|
+
Python</a> </li>
|
|
1740
|
+
<li>
|
|
1741
|
+
|
|
1742
|
+
<a href="http://oreilly.com/pub/topic/ruby" class="showtopic">
|
|
1743
|
+
|
|
1744
|
+
Ruby</a> </li>
|
|
1745
|
+
|
|
1746
|
+
<li>
|
|
1747
|
+
|
|
1748
|
+
<a href="http://oreilly.com/pub/topic/secureprogramming" class="showtopic">
|
|
1749
|
+
|
|
1750
|
+
Secure Programming</a> </li>
|
|
1751
|
+
<li>
|
|
1752
|
+
|
|
1753
|
+
<a href="http://oreilly.com/pub/topic/vb" class="showtopic">
|
|
1754
|
+
|
|
1755
|
+
Visual Basic</a> </li>
|
|
1756
|
+
<li>
|
|
1757
|
+
|
|
1758
|
+
<a href="http://oreilly.com/pub/topic/webservices" class="showtopic">
|
|
1759
|
+
|
|
1760
|
+
|
|
1761
|
+
Web Services</a> </li>
|
|
1762
|
+
<li>
|
|
1763
|
+
|
|
1764
|
+
<a href="http://oreilly.com/pub/topic/xml" class="showtopic">
|
|
1765
|
+
|
|
1766
|
+
XML</a> </li>
|
|
1767
|
+
|
|
1768
|
+
</ul>
|
|
1769
|
+
</li>
|
|
1770
|
+
<li><a href="#" onclick="toggleSheet('science'); return false" id="scienceButton" class="rollup">Science & Math</a>
|
|
1771
|
+
|
|
1772
|
+
<ul id="science">
|
|
1773
|
+
<li>
|
|
1774
|
+
|
|
1775
|
+
<a href="http://oreilly.com/pub/topic/mapping" class="showtopic">
|
|
1776
|
+
|
|
1777
|
+
Mapping</a> </li>
|
|
1778
|
+
<li>
|
|
1779
|
+
|
|
1780
|
+
<a href="http://oreilly.com/pub/topic/math" class="showtopic">
|
|
1781
|
+
|
|
1782
|
+
Math</a> </li>
|
|
1783
|
+
<li>
|
|
1784
|
+
|
|
1785
|
+
<a href="http://oreilly.com/pub/topic/science" class="showtopic">
|
|
1786
|
+
|
|
1787
|
+
Science</a> </li>
|
|
1788
|
+
|
|
1789
|
+
</ul>
|
|
1790
|
+
</li>
|
|
1791
|
+
<li><a href="#" onclick="toggleSheet('security'); return false" id="securityButton" class="rollup">Security</a>
|
|
1792
|
+
<ul id="security">
|
|
1793
|
+
<li>
|
|
1794
|
+
|
|
1795
|
+
<a href="http://oreilly.com/pub/topic/security" class="showtopic">
|
|
1796
|
+
|
|
1797
|
+
Computer Security & Privacy</a> </li>
|
|
1798
|
+
|
|
1799
|
+
<li>
|
|
1800
|
+
|
|
1801
|
+
<a href="http://oreilly.com/pub/topic/secureprogramming" class="showtopic">
|
|
1802
|
+
|
|
1803
|
+
Secure Programming</a> </li>
|
|
1804
|
+
<li>
|
|
1805
|
+
|
|
1806
|
+
<a href="http://oreilly.com/pub/topic/serversecurity" class="showtopic">
|
|
1807
|
+
|
|
1808
|
+
Server Security</a> </li>
|
|
1809
|
+
<li>
|
|
1810
|
+
|
|
1811
|
+
<a href="http://oreilly.com/pub/topic/spam" class="showtopic">
|
|
1812
|
+
|
|
1813
|
+
|
|
1814
|
+
Spam</a> </li>
|
|
1815
|
+
|
|
1816
|
+
</ul>
|
|
1817
|
+
</li>
|
|
1818
|
+
<li><a href="#" onclick="toggleSheet('softwareengineering'); return false" id="softwareengineeringButton" class="rollup">Software Engineering</a>
|
|
1819
|
+
<ul id="softwareengineering">
|
|
1820
|
+
<li>
|
|
1821
|
+
|
|
1822
|
+
<a href="http://oreilly.com/pub/topic/designpatterns" class="showtopic">
|
|
1823
|
+
|
|
1824
|
+
Design Patterns</a> </li>
|
|
1825
|
+
<li>
|
|
1826
|
+
|
|
1827
|
+
<a href="http://oreilly.com/pub/topic/enterprisedev" class="showtopic">
|
|
1828
|
+
|
|
1829
|
+
Enterprise Development</a> </li>
|
|
1830
|
+
<li>
|
|
1831
|
+
|
|
1832
|
+
<a href="http://oreilly.com/pub/topic/projectmanagement" class="showtopic">
|
|
1833
|
+
|
|
1834
|
+
Project & Career Management</a> </li>
|
|
1835
|
+
<li>
|
|
1836
|
+
|
|
1837
|
+
<a href="http://oreilly.com/pub/topic/secureprogramming" class="showtopic">
|
|
1838
|
+
|
|
1839
|
+
Secure Programming</a> </li>
|
|
1840
|
+
<li>
|
|
1841
|
+
|
|
1842
|
+
<a href="http://oreilly.com/pub/topic/testing" class="showtopic">
|
|
1843
|
+
|
|
1844
|
+
Testing</a> </li>
|
|
1845
|
+
|
|
1846
|
+
</ul>
|
|
1847
|
+
</li>
|
|
1848
|
+
<li><a href="#" onclick="toggleSheet('web'); return false" id="webButton" class="rollup">The Web</a>
|
|
1849
|
+
|
|
1850
|
+
<ul id="web">
|
|
1851
|
+
<li>
|
|
1852
|
+
|
|
1853
|
+
<a href="http://oreilly.com/pub/topic/ajax" class="showtopic">
|
|
1854
|
+
|
|
1855
|
+
Ajax</a> </li>
|
|
1856
|
+
<li>
|
|
1857
|
+
|
|
1858
|
+
<a href="http://oreilly.com/pub/topic/flash" class="showtopic">
|
|
1859
|
+
|
|
1860
|
+
Flash & Actionscript</a> </li>
|
|
1861
|
+
|
|
1862
|
+
<li>
|
|
1863
|
+
|
|
1864
|
+
<a href="http://oreilly.com/pub/topic/mapping" class="showtopic">
|
|
1865
|
+
|
|
1866
|
+
Mapping</a> </li>
|
|
1867
|
+
<li>
|
|
1868
|
+
|
|
1869
|
+
<a href="http://oreilly.com/pub/topic/webapplications" class="showtopic">
|
|
1870
|
+
|
|
1871
|
+
Web Applications</a> </li>
|
|
1872
|
+
<li>
|
|
1873
|
+
|
|
1874
|
+
<a href="http://oreilly.com/pub/topic/browsers" class="showtopic">
|
|
1875
|
+
|
|
1876
|
+
|
|
1877
|
+
Web Browsers</a> </li>
|
|
1878
|
+
<li>
|
|
1879
|
+
|
|
1880
|
+
<a href="http://oreilly.com/pub/topic/webdesign" class="showtopic">
|
|
1881
|
+
|
|
1882
|
+
Web Design</a> </li>
|
|
1883
|
+
<li>
|
|
1884
|
+
|
|
1885
|
+
<a href="http://oreilly.com/pub/topic/webdev" class="showtopic">
|
|
1886
|
+
|
|
1887
|
+
Web Development</a> </li>
|
|
1888
|
+
|
|
1889
|
+
<li>
|
|
1890
|
+
|
|
1891
|
+
<a href="http://oreilly.com/pub/topic/webservices" class="showtopic">
|
|
1892
|
+
|
|
1893
|
+
Web Services</a> </li>
|
|
1894
|
+
|
|
1895
|
+
</ul>
|
|
1896
|
+
</li>
|
|
1897
|
+
</ul>
|
|
1898
|
+
</div></div><div class="widget-left">
|
|
1899
|
+
<h3>News Topics</h3>
|
|
1900
|
+
<div id="default-cloud" class="widget-cloud">
|
|
1901
|
+
<IFRAME src="http://www.oreillynet.com/oreilly/orn/newstagcloud.csp" name="related" width="174" height="300" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" ></IFRAME>
|
|
1902
|
+
</div>
|
|
1903
|
+
|
|
1904
|
+
</div>
|
|
1905
|
+
|
|
1906
|
+
|
|
1907
|
+
</div>
|
|
1908
|
+
</div>
|
|
1909
|
+
|
|
1910
|
+
<div id="gamma">
|
|
1911
|
+
<div id="gamma-inner">
|
|
1912
|
+
<div class="noindex"><div class="widget-right">
|
|
1913
|
+
<h3>Stay Connected</h3>
|
|
1914
|
+
<div class="widget-content">
|
|
1915
|
+
<a href="http://elists.oreilly.com/" onClick="var s=s_gi(s_account); s.products=';il-sc-elists'; s.eVar23='il-sc-elists'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/email-16x16.gif" alt="RSS 2.0 Feed" border="0" style="padding-bottom:20px;padding-right:8px;" align="left" />Subscribe to our Newsletters</a>
|
|
1916
|
+
|
|
1917
|
+
<br clear="all" />
|
|
1918
|
+
|
|
1919
|
+
<a href="http://youtube.com/oreillymedia" onClick="var s=s_gi(s_account); s.products=';il-sc-youtube'; s.eVar23='il-sc-youtube'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/youtube-icon.png" alt="O'Reilly on YouTube" border="0" style="padding-bottom:8px;padding-right:8px;" align="left" valign="center" />O'Reilly on YouTube</a>
|
|
1920
|
+
<br clear="all" />
|
|
1921
|
+
|
|
1922
|
+
<a href="http://twitter.com/oreillymedia" onClick="var s=s_gi(s_account); s.products=';il-sc-twitter'; s.eVar23='il-sc-twitter'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/twitter-16x16.png" alt="O'Reilly Media on Twitter" border="0" style="padding-bottom:8px;padding-right:8px;" align="left" />O'Reilly on Twitter</a>
|
|
1923
|
+
<br clear="all" />
|
|
1924
|
+
|
|
1925
|
+
<a href="http://www.facebook.com/OReilly" onClick="var s=s_gi(s_account); s.products=';il-sc-facebook'; s.eVar23='il-sc-facebook'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/facebook-16x16.png" alt="RSS 2.0 Feed" border="0" style="padding-bottom:8px;padding-right:8px;" align="left" />O'Reilly on Facebook</a>
|
|
1926
|
+
<br clear="all" />
|
|
1927
|
+
|
|
1928
|
+
<a href="feed://feeds.feedburner.com/oreilly/news" onClick="var s=s_gi(s_account); s.products=';il-sc-feeds-news'; s.eVar23='il-sc-feeds-news'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/feed-icon-16x16.png" alt="RSS 2.0 Feed" border="0" style="padding-bottom:8px; padding-right:8px;" align="left" />News Feed</a>
|
|
1929
|
+
<br clear="all" />
|
|
1930
|
+
|
|
1931
|
+
<a href="http://feeds.feedburner.com/oreilly/newbooks" onClick="var s=s_gi(s_account); s.products=';il-sc-feeds-newbooks'; s.eVar23='il-sc-feeds-newbooks'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/feed-icon-16x16.png" alt="RSS 2.0 Feed" border="0" style="padding-bottom:8px;padding-right:8px;" align="left" />New Titles Feed</a>
|
|
1932
|
+
<br clear="all" />
|
|
1933
|
+
|
|
1934
|
+
<a href="http://feeds.feedburner.com/oreilly/upcomingbooks" onClick="var s=s_gi(s_account); s.products=';il-sc-feeds-upcomingbooks'; s.eVar23='il-sc-feeds-upcomingbooks'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');"><img src="http://oreilly.com/images/icons/feed-icon-16x16.png" alt="RSS 2.0 Feed" border="0" style="padding-bottom:8px;padding-right:8px;" align="left" />Upcoming Titles Feed</a>
|
|
1935
|
+
<br clear="all" />
|
|
1936
|
+
|
|
1937
|
+
|
|
1938
|
+
<span class="more"><a href="http://www.oreillynet.com/feeds/" onClick="var s=s_gi(s_account); s.products=';il-sc-feeds'; s.eVar23='il-sc-feeds'; s.events='event5'; s.linkTrackVars='eVar23,products,events'; s.linkTrackEvents='event5'; s.tl(this,'o','Ad Click');">New to RSS?</a></span>
|
|
1939
|
+
|
|
1940
|
+
</div>
|
|
1941
|
+
</div>
|
|
1942
|
+
<div class="widget-right" style="margin-right: 0px; margin-left: 0px; padding-right: 0px; padding-left: 0px;"><h3>Recommended for You</h3>
|
|
1943
|
+
<div class="widget-content" style="margin-right: 0px; margin-left: 0px; padding-right: 0px; padding-left: 0px;">
|
|
1944
|
+
<!-- MyBuys Web Recommendation Zone -->
|
|
1945
|
+
<div mybuyszone="3"></div>
|
|
1946
|
+
<!-- End MyBuys Web Recommendation Zone -->
|
|
1947
|
+
</div>
|
|
1948
|
+
</div><div class="widget-right">
|
|
1949
|
+
<h3>Got a Question?</h3>
|
|
1950
|
+
<div class="widget-content">
|
|
1951
|
+
<div id="gsfn_list_widget">
|
|
1952
|
+
|
|
1953
|
+
|
|
1954
|
+
<div class="sidebar-item-content"><img src="http://oreilly.com/images/oreilly/satisfaction-icons.gif"><br />
|
|
1955
|
+
<div class="gsfn_content">
|
|
1956
|
+
<form id="gsfn_search_form" action="http://getsatisfaction.com/oreilly" method="get" accept-charset="utf-8" onsubmit="gsfn_search(this); return false;">
|
|
1957
|
+
<input type="hidden" name="widget" value="" />
|
|
1958
|
+
<input type="hidden" name="limit" value="3" />
|
|
1959
|
+
<input type="hidden" name="style" value="" />
|
|
1960
|
+
<input type="hidden" name="callback" value="gsfnResultsCallback" />
|
|
1961
|
+
<input type="hidden" name="format" value="json" />
|
|
1962
|
+
<label for="gsfn_search_query" class="gsfn_label">
|
|
1963
|
+
|
|
1964
|
+
Do you have a question about <strong>O'Reilly's products and services</strong>? Share an idea! Report a problem...</label><br /><br />
|
|
1965
|
+
<input type="text" size="16" name="query" value="" id="gsfn_search_query" maxlength="120" style="padding-bottom: 6px;"/><br />
|
|
1966
|
+
|
|
1967
|
+
<input type="submit" id="continue" value="Continue" />
|
|
1968
|
+
</form>
|
|
1969
|
+
|
|
1970
|
+
<div id="gsfn_search_results" style="height: auto;"></div>
|
|
1971
|
+
</div>
|
|
1972
|
+
|
|
1973
|
+
<br />
|
|
1974
|
+
|
|
1975
|
+
<a href="http://getsatisfaction.com/oreilly" class="widget_title">Active discussions:</a><br /><br />
|
|
1976
|
+
|
|
1977
|
+
<div id="gsfn_content">Loading... </div>
|
|
1978
|
+
|
|
1979
|
+
<div class="powered_by"><a href="http://getsatisfaction.com/"><img alt="Favicon" src="http://www.getsatisfaction.com/favicon.gif" style="vertical-align: middle;" /></a> <a href="http://getsatisfaction.com/">Service and support by Satisfaction</a></div>
|
|
1980
|
+
</div>
|
|
1981
|
+
</div>
|
|
1982
|
+
</div>
|
|
1983
|
+
</div>
|
|
1984
|
+
</div>
|
|
1985
|
+
</div>
|
|
1986
|
+
</div>
|
|
1987
|
+
|
|
1988
|
+
|
|
1989
|
+
|
|
1990
|
+
</div>
|
|
1991
|
+
</div>
|
|
1992
|
+
<div id="footer">
|
|
1993
|
+
<div id="footer-inner">
|
|
1994
|
+
<div id="footer-content">
|
|
1995
|
+
|
|
1996
|
+
<table border="0" style="font-size: 11px; text-align: left;">
|
|
1997
|
+
|
|
1998
|
+
<tbody>
|
|
1999
|
+
<tr><td valign="top" align="left" width="25%" style="padding-left: 20px; padding-right: 20px;">
|
|
2000
|
+
<a href="http://oreilly.com/"><img width="155" height="35" border="0" alt="O'Reilly Media" src="http://cdn.oreilly.com/images/standard/oreilly-logo-footer.gif"/></a>
|
|
2001
|
+
|
|
2002
|
+
<br /><br />
|
|
2003
|
+
© 2011, O'Reilly Media, Inc.<br/>(707) 827-7000 / (800) 998-9938<br/> All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. </td>
|
|
2004
|
+
|
|
2005
|
+
|
|
2006
|
+
<td valign="top" class="footercol1">
|
|
2007
|
+
<ul>
|
|
2008
|
+
<li><a href="http://oreilly.com/about/"><strong>About O'Reilly</strong></a></li>
|
|
2009
|
+
<li><a href="http://oreilly.com/academic/">Academic Solutions</a></li>
|
|
2010
|
+
<li><a href="http://oreilly.com/contact.html">Contacts</a></li>
|
|
2011
|
+
<li><a href="http://oreilly.com/oreilly/cs/">Customer Service</a></li>
|
|
2012
|
+
<li><a href="http://oreilly.com/jobs/">Careers</a></li>
|
|
2013
|
+
<li><a href="http://press.oreilly.com/">Press Room</a></li>
|
|
2014
|
+
<li><a href="http://oreilly.com/oreilly/privacy.csp">Privacy Policy</a></li>
|
|
2015
|
+
<li><a href="http://oreilly.com/terms/">Terms of Service</a></li>
|
|
2016
|
+
<li><a href="http://oreilly.com/oreilly/author/intro.csp">Writing for O'Reilly</a></li>
|
|
2017
|
+
</ul>
|
|
2018
|
+
</td>
|
|
2019
|
+
|
|
2020
|
+
<td valign="top" class="footercol2">
|
|
2021
|
+
<ul>
|
|
2022
|
+
<li><a href="http://oreilly.com/community/"><strong>Community</strong></a></li>
|
|
2023
|
+
<li><a href="http://oreilly.com/authors/">Authors</a></li>
|
|
2024
|
+
<li><a href="http://forums.oreilly.com/">Forums</a></li>
|
|
2025
|
+
<li><a href="https://members.oreilly.com/">Membership</a></li>
|
|
2026
|
+
<li><a href="http://elists.oreilly.com/">Newsletters</a></li>
|
|
2027
|
+
<li><a href="http://oreilly.com/feeds/">RSS Feeds</a></li>
|
|
2028
|
+
<li><a href="http://ug.oreilly.com/">User Groups</a></li>
|
|
2029
|
+
</ul>
|
|
2030
|
+
</td>
|
|
2031
|
+
|
|
2032
|
+
<td valign="top" class="footercol3">
|
|
2033
|
+
<ul>
|
|
2034
|
+
<li><strong>More O'Reilly Sites</strong></li>
|
|
2035
|
+
<li><a href="http://igniteshow.com/">igniteshow.com</a></li>
|
|
2036
|
+
<li><a href="http://makerfaire.com/">makerfaire.com</a></li>
|
|
2037
|
+
<li><a href="http://makezine.com/">makezine.com</a></li>
|
|
2038
|
+
<li><a href="http://craftzine.com">craftzine.com</a></li>
|
|
2039
|
+
<li><a href="http://labs.oreilly.com">labs.oreilly.com</a></li>
|
|
2040
|
+
</ul>
|
|
2041
|
+
|
|
2042
|
+
<ul>
|
|
2043
|
+
<li><strong>Partner Sites</strong></li>
|
|
2044
|
+
<li><a href="https://www.x.com/community/ppx/devzone">PayPal Developer Zone</a></li>
|
|
2045
|
+
<li><a href="http://blogs.forbes.com/oreillymedia/">O'Reilly Insights on Forbes.com</a></li>
|
|
2046
|
+
</ul>
|
|
2047
|
+
</td>
|
|
2048
|
+
</tr>
|
|
2049
|
+
|
|
2050
|
+
</tbody>
|
|
2051
|
+
</table>
|
|
2052
|
+
|
|
2053
|
+
<!-- Satisfaction Widget JS -->
|
|
2054
|
+
<script src="http://getsatisfaction.com/oreilly/widgets/javascripts/2f71b77af1/widgets.js" type="text/javascript"></script> <script src="http://getsatisfaction.com/oreilly/topics.widget?callback=gsfnTopicsCallback&limit=3&sort=recently_active" type="text/javascript"></script>
|
|
2055
|
+
<!-- End Satisfaction Widget JS -->
|
|
2056
|
+
|
|
2057
|
+
</div>
|
|
2058
|
+
</div>
|
|
2059
|
+
</div>
|
|
2060
|
+
|
|
2061
|
+
</div> <!-- /#content-09 -->
|
|
2062
|
+
</div>
|
|
2063
|
+
</div>
|
|
2064
|
+
<!-- MyBuys Page Parameters -->
|
|
2065
|
+
<script type="text/javascript">
|
|
2066
|
+
mybuys.setPageType("CONTENT_ITEM");
|
|
2067
|
+
mybuys.set("categoryid","http://purl.oreilly.com/resource-center/none");
|
|
2068
|
+
</script>
|
|
2069
|
+
<!-- #MyBuys Page Parameters -->
|
|
2070
|
+
<!-- analytics -->
|
|
2071
|
+
|
|
2072
|
+
<!-- Start Quantcast tag -->
|
|
2073
|
+
<script type="text/javascript" src=" http://edge.quantserve.com/quant.js "></script>
|
|
2074
|
+
<script type="text/javascript">_qoptions = { tags:"News" }; _qacct="p-20l78bOOCbhcg";quantserve();</script>
|
|
2075
|
+
<noscript>
|
|
2076
|
+
<a href=" http://www.quantcast.com/p-20l78bOOCbhcg " target="_blank"><img src=" http://pixel.quantserve.com/pixel/p-20l78bOOCbhcg.gif?tags=News " style="display: none;" border="0" height="1" width="1" alt="Quantcast"/></a>
|
|
2077
|
+
</noscript>
|
|
2078
|
+
<!-- End Quantcast tag -->
|
|
2079
|
+
<!-- google -->
|
|
2080
|
+
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
|
|
2081
|
+
</script>
|
|
2082
|
+
<script type="text/javascript">
|
|
2083
|
+
_uacct = "UA-4591498-1";
|
|
2084
|
+
urchinTracker();
|
|
2085
|
+
</script>
|
|
2086
|
+
<!-- #google -->
|
|
2087
|
+
|
|
2088
|
+
<!-- #analytics -->
|
|
2089
|
+
<script language="JavaScript" type="text/javascript">
|
|
2090
|
+
var s_account="ororeilly,orglobal" // change report suite ID accordingly
|
|
2091
|
+
</script>
|
|
2092
|
+
<!-- SiteCatalyst code version: H.20.3. Copyright 1997-2009 Omniture, Inc. More info available at http://www.omniture.com -->
|
|
2093
|
+
<script language="JavaScript" type="text/javascript" src="http://assets.oreilly.com/js/s_code.js"></script>
|
|
2094
|
+
<script language="JavaScript" type="text/javascript">
|
|
2095
|
+
s.pageName="oreilly:broadcast:the aws outage the clouds shining moment"
|
|
2096
|
+
s.channel="oreilly"
|
|
2097
|
+
s.prop1="oreilly:broadcast"
|
|
2098
|
+
s.prop2="oreilly:broadcast:broadcast"
|
|
2099
|
+
s.prop3="oreilly:broadcast:broadcast:broadcast"
|
|
2100
|
+
s.prop4="article"
|
|
2101
|
+
s.hier1="oreilly,broadcast,broadcast,broadcast"
|
|
2102
|
+
s.prop5="the aws outage the clouds shining moment"
|
|
2103
|
+
s.prop6="BC46231"
|
|
2104
|
+
s.prop7="04/23/2011" // publish date
|
|
2105
|
+
//s.prop15=""
|
|
2106
|
+
//These props should be set when a blog/article is read, post or reply made.
|
|
2107
|
+
s.prop21="george reese" // author name
|
|
2108
|
+
s.prop22="broadcast" // blog name
|
|
2109
|
+
s.prop23="the aws outage the clouds shining moment" // entry title
|
|
2110
|
+
s.prop24="04/23/2011" // post date
|
|
2111
|
+
//s.prop25="" // days since last post
|
|
2112
|
+
s.prop26="saturday" // day of week
|
|
2113
|
+
/* Conversion Variables */
|
|
2114
|
+
s.campaign=""
|
|
2115
|
+
s.events=""
|
|
2116
|
+
|
|
2117
|
+
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
|
|
2118
|
+
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
|
|
2119
|
+
<!-- End SiteCatalyst code version: H.20.2. -->
|
|
2120
|
+
|
|
2121
|
+
|
|
2122
|
+
|
|
2123
|
+
|
|
2124
|
+
<!-- MyBuys Page Initialization -->
|
|
2125
|
+
<script type="text/javascript">
|
|
2126
|
+
mybuys.initPage();
|
|
2127
|
+
</script>
|
|
2128
|
+
<!-- #MyBuys Page Initialization -->
|
|
2129
|
+
|
|
2130
|
+
|
|
2131
|
+
<!-- chartbeat -->
|
|
2132
|
+
<script type="text/javascript">
|
|
2133
|
+
var cbjspath = "static.chartbeat.com/js/chartbeat.js?uid=1632&domain=broadcast.oreilly.com";
|
|
2134
|
+
var cbjsprotocol = (("https:" == document.location.protocol) ? "https://s3.amazonaws.com/" : "http://");
|
|
2135
|
+
document.write(unescape("%3Cscript src='"+cbjsprotocol+cbjspath+"' type='text/javascript'%3E%3C/script%3E"))
|
|
2136
|
+
</script>
|
|
2137
|
+
<!-- #chartbeat -->
|
|
2138
|
+
|
|
2139
|
+
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/utilities/utilities.js"></script>
|
|
2140
|
+
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/datasource/datasource-min.js"></script>
|
|
2141
|
+
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/autocomplete/autocomplete-min.js"></script>
|
|
2142
|
+
<script type="text/javascript" src="http://content.atomz.com/sp1003bcf0/publish/autocomplete_data.js?sp_js_cache_ver=3"></script>
|
|
2143
|
+
</body>
|
|
2144
|
+
</html>
|
|
2145
|
+
|