summaryrefslogtreecommitdiff
path: root/src/talks
diff options
context:
space:
mode:
authorMonty Taylor <mordred@inaugust.com>2017-10-19 09:59:49 +0200
committerMonty Taylor <mordred@inaugust.com>2017-10-19 10:38:05 +0200
commit7ff3f031c0d45b5ea866297b6e68e15e5615ee60 (patch)
tree34df47452a02d8d0a309b0a2b241084444c54270 /src/talks
parentb87f3b387f0a8eb629a6c4ca955a8b396948218e (diff)
Add only-one-cloud talk
Diffstat (limited to 'src/talks')
-rw-r--r--src/talks/only-one-cloud.hbs317
1 files changed, 317 insertions, 0 deletions
diff --git a/src/talks/only-one-cloud.hbs b/src/talks/only-one-cloud.hbs
new file mode 100644
index 0000000..f4ec101
--- /dev/null
+++ b/src/talks/only-one-cloud.hbs
@@ -0,0 +1,317 @@
1<!doctype html>
2<html lang="en">
3
4 <head>
5 <meta charset="utf-8">
6
7 <title>It can't be Cloud Native if it only runs on one cloud</title>
8
9 </head>
10 <body>
11
12 <section id="those-who-do-not-understand" class="slide level2">
13 <blockquote>
14 Those who do not understand UNIX are condemned to reinvent it,
15 poorly.
16 </blockquote>
17 <h3>Henry Spencer</h3>
18 </section>
19
20 <section id="who-am-i-redhat" class="slide level2">
21 <h1>Who am I?</h1>
22 <img style="float:right; margin:24pt" src="/images/Logo_RH_CMYK_Default.jpg" />
23 <p> CTO Office </p>
24 <p> CI/CD and Automation</p>
25 <p> Zuul </p>
26 <p> Ansible </p>
27 </section>
28
29 <section id="who-am-i-openstack" class="slide level2">
30 <h1>Who am I?</h1>
31 <img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/openstack-cloud-software-vertical-large.png" />
32 <p>Developer Infrastructure Core Team</p>
33 <p>Shade PTL</p>
34 <p>Technical Committee (for another week)</p>
35 <p>Former Foundation Board of Directors</p>
36 <p>Infrastructure PTL Emeritus</p>
37 </section>
38
39 <section id="who-am-i-founder" class="slide level2">
40 <h1>In the beginning ...</h1>
41 <img style="width:700px; height: auto" src="/images/monty-launchpad.png" />
42 </section>
43
44 <section id="google-cluster-architecture" class="slide level2">
45 <blockquote>
46 Google's architecture features clusters of more than 15,000 commodity
47 class PCs with fault-tolerant software. This architecture achieves
48 superior performance at a fraction of the cost of a system built from
49 fewer, but more expensive, high-end servers.</blockquote>
50 <h3>Web Search for a Planet: The Google Cluster Architecture</h3>
51 <h3>Luiz Andre Barroso, Jeffrey Dean, Urs Hölzle - 2003</h3>
52 <p><a href='https://research.google.com/pubs/pub49.html'>
53 https://research.google.com/pubs/pub49.html</a></p>
54 </section>
55
56 <section id="google-cluster-architecture-summary" class="slide level2">
57 <ul>
58 <li>Assume failure</li>
59 <li>Use cheap servers, not expensive servers</li>
60 <li>Scale out, not up</li>
61 </ul>
62 </section>
63
64 <section id='shared-nothing' class="slide level2" data-transition='zoom'>
65 <h1>Shared Nothing</h1>
66 </section>
67
68 <section id="who-was-I-mysql" class="slide level2">
69 <h1>Who was I?</h1>
70 <img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/logo-mysql-170x115.png" />
71 <p>Professional Services</p>
72 <p>High Availability</p>
73 <p>Scaling</p>
74 <p>Cluster</p>
75 </section>
76
77 <section id="datacenter-crash" class="slide level2">
78 <blockquote>I asked for a crossover cable...</blockquote>
79 </section>
80
81 <section id="mysql-at-facebook" class="slide level2">
82 <h2>Why MySQL? Wouldn’t NoSQL databases, for example, be better suited for the massive workloads seen at Facebook?</h2>
83
84 <blockquote>I have not been able to find a transactional NoSQL database
85 better than InnoDB. And it’s easy to understand how MySQL Replication
86 works, which makes much easier to fix problems in production.
87 </blockquote>
88 <h3>Yoshinori Matsunobu, Facebook Engineering, 2014</h3>
89 </section>
90
91 <section id="mysql-lessons" class="slide level2">
92 <h1>Lessons from MySQL</h1>
93 <ul>
94 <li>Simple is better than complex</li>
95 <li>Know how your software works</li>
96 <li>How something fails is more important than how something works</li>
97 </ul>
98 </section>
99
100 <section id="who-was-I-sun" class="slide level2">
101 <h1>Who was I?</h1>
102 <img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/sun_microsystems_logo_2385.gif" />
103 <p>Professional Services</p>
104 <p>High Availability</p>
105 <p>Scaling</p>
106 <p>Cluster</p>
107 </section>
108
109 <section id="the-dot-in-dot-com" class="slide level2">
110 <img src='/images/m_img_23895.jpg' />
111 </section>
112
113 <section id="sun-lessons" class="slide level2">
114 <h1>Lessons from Sun</h1>
115 <ul>
116 <li>Simple is better than complex</li>
117 <li>Assume failure</li>
118 <li>Use cheap servers, not expensive servers</li>
119 <li>Scale out, not up</li>
120 </ul>
121 </section>
122
123 <section id="who-was-I-drizzle" class="slide level2">
124 <h1>Who was I?</h1>
125 <img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/Drizzle-logotype.svg" />
126 <p>Fork of MySQL</p>
127 <p>Modern C++0x</p>
128 <p>Microkernel Design</p>
129 </section>
130
131 <section id="two-better-than-one" class="slide level2" data-transition="zoom">
132 <h1>Why have one when you can have two at twice the price?</h1>
133 </section>
134
135 <section id="database-for-the-cloud" class="slide level2">
136 <h1>"A Database For The Cloud"</h1>
137 <ul>
138 <li>Removed bloat (triggers, stored procedures, mediumint)</li>
139 <li>Sensible Defaults - no config needed</li>
140 <li>Moved data dictionary into InnoDB tablespace</li>
141 <li>Immediate Ancestor of OpenStack's Gating</li>
142 </ul>
143 </section>
144
145 <section id="what-can-we-throw-out" class="slide level2">
146 <blockquote>
147 We used to sit around in the Unix Room saying,
148 '<em>What can we throw out?</em>
149 Why is there this option?' It's often because there is some deficiency
150 in the basic design — you didn't really hit the right design point.
151 Instead of adding an option, think about what was forcing you to add
152 that option.
153 </blockquote>
154 <h3>Doug McIlroy, 2005</h3>
155 </section>
156
157 <section id="unix-philosophy" class="slide level2">
158 <h1>UNIX philosophy</h1>
159 <ul>
160 <li>Make each program do one thing well. To do a new job, build afresh
161 rather than complicate old programs by adding new "features".</li>
162 <li>Expect the output of every program to become the input to another,
163 as yet unknown, program. Don't clutter output with extraneous
164 information. Avoid stringently columnar or binary input formats.
165 Don't insist on interactive input.</li>
166 <li>Design and build software, even operating systems, to be tried
167 early, ideally within weeks. Don't hesitate to throw away the clumsy
168 parts and rebuild them.</li>
169 <li>Use tools in preference to unskilled help to lighten a programming
170 task, even if you have to detour to build the tools and expect to
171 throw some of them out after you've finished using them.</li>
172 </ul>
173 <h3>Doug McIlroy, Bell System Technical Journal, 1978</h3>
174 </section>
175
176 <section id="unix-philosophy" class="slide level2">
177 <blockquote>
178 the power of a system comes more from the relationships among programs
179 than from the programs themselves
180 </blockquote>
181 <h3>The Unix Programming Environment</h3>
182 <h3>Brian Kernighan and Rob Pike</h3>
183 </section>
184
185 <section class="slide level2">
186 <h1>Cloud Native Is ... </h1>
187 <ul>
188 <li>Architectural and operational approach</li>
189 <li>Assume cloud</li>
190 <li>Assume failures</li>
191 <li>Microservices</li>
192 <li>Containerized?</li>
193 </ul>
194 </section>
195
196 <section class="slide level2">
197 <h1>12 Factor Application</h1>
198 <h3>I. Codebase - One codebase tracked in revision control, many deploys
199 </h3>
200 <h3>II. Dependencies - Explicitly declare and isolate dependencies</h3>
201 <h3>III. Config - Store config in the environment</h3>
202 <h3>IV. Backing services - Treat backing services as attached resources</h3>
203 <h3>V. Build, release, run - Strictly separate build and run stages</h3>
204 <h3>VI. Processes - Execute the app as one or more stateless processes</h3>
205 <h3>VII. Port binding - Export services via port binding</h3>
206 <h3>VIII. Concurrency - Scale out via the process model</h3>
207 <h3>IX. Disposability - Maximize robustness with fast startup and graceful shutdown</h3>
208 <h3>X. Dev/prod parity - Keep development and production as similar as possible</h3>
209 <h3>XI. Logs - Treat logs as event streams</h3>
210 <h3>XII. Admin processes - Run admin/management tasks as one-off processes</h3>
211 </section>
212
213 <section class="slide level2" data-transition='zoom'>
214 <h1>This is awesome</h1>
215 </section>
216
217 <section class="slide level2" data-transition='zoom'>
218 <h1>Except for III</h1>
219 <h2>I use config files</h2>
220 <h3 class="fragment">Ooops</h3>
221 </section>
222
223 <section class="slide level2" data-transition='zoom'>
224 <h1>VI. Stateless</h1>
225 <h2>If /dev/null is fast in web scale I will use it. Is it web scale?</h2>
226 <h3 class="fragment">Use a service to store your data - like a database</h3>
227 <h3 class="fragment">Is that database service web scale?</h3>
228 </section>
229
230 <section class="slide level2">
231 <blockquote>
232 If /dev/null is fast in web scale I will use it. Is it web scale?
233 </blockquote>
234 <h3>MongoDB is web scale</h3>
235 <p><a href='http://www.mongodb-is-web-scale.com/'>
236 http://www.mongodb-is-web-scale.com</a></p>
237 </section>
238
239 <section class="slide level2">
240 <blockquote>
241 The tragedy of modern man is not that he knows less and less about
242 the meaning of his own life, but that it bothers him less and less.
243 </blockquote>
244 <h3>Václav Havel</h3>
245 </section>
246
247 <section id="datacenter-as-computer" class="slide level2">
248 <blockquote>
249 As computation continues to move into the cloud, the computing platform
250 of interest no longer resembles a pizza box or a refrigerator, but a
251 warehouse full of computers. ... in other words, we must treat the
252 datacenter itself as one massive warehouse-scale computer.
253 </blockquote>
254 <h3>The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines</h3>
255 <h3>Luiz André Barroso, Urs Hölzle - 2009</h3>
256 <p><a href='https://research.google.com/pubs/pub35290.html'>
257 https://research.google.com/pubs/pub35290.html</a></p>
258 </section>
259
260 <section id="unix-portable" class="slide level2">
261 <blockquote>
262 The use of top-down design methods and high-level languages in
263 producing portable applications software is well established. By
264 applying the same principles at the systems programming level,
265 portability can be extended to the operating system itself. Although
266 the Unix operating system was developed for a specific computer (the
267 DEC PDPll), its concise and elegant design and the careful selection
268 of 'primitives' which it provides make it an ideal candidate for
269 portability.
270 </blockquote>
271 <h3>UNIX: a portable operating system?</h3>
272 <h3>Richard Miller - 1978</h3>
273 </section>
274
275 <section class="slide level2" data-transition='zoom'>
276 <h1>If the datacenter is the new computer ...</h1>
277 </section>
278
279 <section class="slide level2" data-transition='zoom'>
280 <h1>Then the power of OpenStack is as a portable Operating System</h1>
281 </section>
282
283 <section class="slide level2" data-transition='zoom'>
284 <h1>Just as MVS was an Operating System for IBM System/370 ...</h1>
285 </section>
286
287 <section class="slide level2" data-transition='zoom'>
288 <h1>AWS is an Operating System specific to Amazon Datacenters</h1>
289 </section>
290
291 <section class="slide level2" data-transition='zoom'>
292 <h1>Google Cloud is an Operating System specific to Google
293 Datacenters</h1>
294 </section>
295
296 <section class="slide level2" data-transition='zoom'>
297 <h1>If sets of cheaper commodity servers are superior to fancy custom
298 built high-end hardware ...</h1>
299 </section>
300
301 <section class="slide level2" data-transition='zoom'>
302 <h1>Then commodity data centers with a common Operating System should
303 be better than fancy data centers controlled by one or two companies
304 </h1>
305 </section>
306
307 <section class="slide level2">
308 <h1>Linux won the battle for single-computer Operating Systems.</h1>
309 </section>
310
311 <section class="slide level2">
312 <h1>Let's win the battle for a Free, Open and Portable Operating System
313 for warehouse-scale computers.</h1>
314 </section>
315
316 </body>
317</html>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-26 03:48:21 +0000