Add only-one-cloud talk
This commit is contained in:
Monty Taylor
parent
b87f3b387f
commit
7ff3f031c0
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
|
|
@ -0,0 +1,317 @@
|
|||
<!doctype html>
|
||||
<html lang="en">
|
||||
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<title>It can't be Cloud Native if it only runs on one cloud</title>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<section id="those-who-do-not-understand" class="slide level2">
|
||||
<blockquote>
|
||||
Those who do not understand UNIX are condemned to reinvent it,
|
||||
poorly.
|
||||
</blockquote>
|
||||
<h3>Henry Spencer</h3>
|
||||
</section>
|
||||
|
||||
<section id="who-am-i-redhat" class="slide level2">
|
||||
<h1>Who am I?</h1>
|
||||
<img style="float:right; margin:24pt" src="/images/Logo_RH_CMYK_Default.jpg" />
|
||||
<p> CTO Office </p>
|
||||
<p> CI/CD and Automation</p>
|
||||
<p> Zuul </p>
|
||||
<p> Ansible </p>
|
||||
</section>
|
||||
|
||||
<section id="who-am-i-openstack" class="slide level2">
|
||||
<h1>Who am I?</h1>
|
||||
<img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/openstack-cloud-software-vertical-large.png" />
|
||||
<p>Developer Infrastructure Core Team</p>
|
||||
<p>Shade PTL</p>
|
||||
<p>Technical Committee (for another week)</p>
|
||||
<p>Former Foundation Board of Directors</p>
|
||||
<p>Infrastructure PTL Emeritus</p>
|
||||
</section>
|
||||
|
||||
<section id="who-am-i-founder" class="slide level2">
|
||||
<h1>In the beginning ...</h1>
|
||||
<img style="width:700px; height: auto" src="/images/monty-launchpad.png" />
|
||||
</section>
|
||||
|
||||
<section id="google-cluster-architecture" class="slide level2">
|
||||
<blockquote>
|
||||
Google's architecture features clusters of more than 15,000 commodity
|
||||
class PCs with fault-tolerant software. This architecture achieves
|
||||
superior performance at a fraction of the cost of a system built from
|
||||
fewer, but more expensive, high-end servers.</blockquote>
|
||||
<h3>Web Search for a Planet: The Google Cluster Architecture</h3>
|
||||
<h3>Luiz Andre Barroso, Jeffrey Dean, Urs Hölzle - 2003</h3>
|
||||
<p><a href='https://research.google.com/pubs/pub49.html'>
|
||||
https://research.google.com/pubs/pub49.html</a></p>
|
||||
</section>
|
||||
|
||||
<section id="google-cluster-architecture-summary" class="slide level2">
|
||||
<ul>
|
||||
<li>Assume failure</li>
|
||||
<li>Use cheap servers, not expensive servers</li>
|
||||
<li>Scale out, not up</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id='shared-nothing' class="slide level2" data-transition='zoom'>
|
||||
<h1>Shared Nothing</h1>
|
||||
</section>
|
||||
|
||||
<section id="who-was-I-mysql" class="slide level2">
|
||||
<h1>Who was I?</h1>
|
||||
<img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/logo-mysql-170x115.png" />
|
||||
<p>Professional Services</p>
|
||||
<p>High Availability</p>
|
||||
<p>Scaling</p>
|
||||
<p>Cluster</p>
|
||||
</section>
|
||||
|
||||
<section id="datacenter-crash" class="slide level2">
|
||||
<blockquote>I asked for a crossover cable...</blockquote>
|
||||
</section>
|
||||
|
||||
<section id="mysql-at-facebook" class="slide level2">
|
||||
<h2>Why MySQL? Wouldn’t NoSQL databases, for example, be better suited for the massive workloads seen at Facebook?</h2>
|
||||
|
||||
<blockquote>I have not been able to find a transactional NoSQL database
|
||||
better than InnoDB. And it’s easy to understand how MySQL Replication
|
||||
works, which makes much easier to fix problems in production.
|
||||
</blockquote>
|
||||
<h3>Yoshinori Matsunobu, Facebook Engineering, 2014</h3>
|
||||
</section>
|
||||
|
||||
<section id="mysql-lessons" class="slide level2">
|
||||
<h1>Lessons from MySQL</h1>
|
||||
<ul>
|
||||
<li>Simple is better than complex</li>
|
||||
<li>Know how your software works</li>
|
||||
<li>How something fails is more important than how something works</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id="who-was-I-sun" class="slide level2">
|
||||
<h1>Who was I?</h1>
|
||||
<img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/sun_microsystems_logo_2385.gif" />
|
||||
<p>Professional Services</p>
|
||||
<p>High Availability</p>
|
||||
<p>Scaling</p>
|
||||
<p>Cluster</p>
|
||||
</section>
|
||||
|
||||
<section id="the-dot-in-dot-com" class="slide level2">
|
||||
<img src='/images/m_img_23895.jpg' />
|
||||
</section>
|
||||
|
||||
<section id="sun-lessons" class="slide level2">
|
||||
<h1>Lessons from Sun</h1>
|
||||
<ul>
|
||||
<li>Simple is better than complex</li>
|
||||
<li>Assume failure</li>
|
||||
<li>Use cheap servers, not expensive servers</li>
|
||||
<li>Scale out, not up</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id="who-was-I-drizzle" class="slide level2">
|
||||
<h1>Who was I?</h1>
|
||||
<img style="float:right; margin-right:24pt; width:300px; height: auto" src="/images/Drizzle-logotype.svg" />
|
||||
<p>Fork of MySQL</p>
|
||||
<p>Modern C++0x</p>
|
||||
<p>Microkernel Design</p>
|
||||
</section>
|
||||
|
||||
<section id="two-better-than-one" class="slide level2" data-transition="zoom">
|
||||
<h1>Why have one when you can have two at twice the price?</h1>
|
||||
</section>
|
||||
|
||||
<section id="database-for-the-cloud" class="slide level2">
|
||||
<h1>"A Database For The Cloud"</h1>
|
||||
<ul>
|
||||
<li>Removed bloat (triggers, stored procedures, mediumint)</li>
|
||||
<li>Sensible Defaults - no config needed</li>
|
||||
<li>Moved data dictionary into InnoDB tablespace</li>
|
||||
<li>Immediate Ancestor of OpenStack's Gating</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id="what-can-we-throw-out" class="slide level2">
|
||||
<blockquote>
|
||||
We used to sit around in the Unix Room saying,
|
||||
'<em>What can we throw out?</em>
|
||||
Why is there this option?' It's often because there is some deficiency
|
||||
in the basic design — you didn't really hit the right design point.
|
||||
Instead of adding an option, think about what was forcing you to add
|
||||
that option.
|
||||
</blockquote>
|
||||
<h3>Doug McIlroy, 2005</h3>
|
||||
</section>
|
||||
|
||||
<section id="unix-philosophy" class="slide level2">
|
||||
<h1>UNIX philosophy</h1>
|
||||
<ul>
|
||||
<li>Make each program do one thing well. To do a new job, build afresh
|
||||
rather than complicate old programs by adding new "features".</li>
|
||||
<li>Expect the output of every program to become the input to another,
|
||||
as yet unknown, program. Don't clutter output with extraneous
|
||||
information. Avoid stringently columnar or binary input formats.
|
||||
Don't insist on interactive input.</li>
|
||||
<li>Design and build software, even operating systems, to be tried
|
||||
early, ideally within weeks. Don't hesitate to throw away the clumsy
|
||||
parts and rebuild them.</li>
|
||||
<li>Use tools in preference to unskilled help to lighten a programming
|
||||
task, even if you have to detour to build the tools and expect to
|
||||
throw some of them out after you've finished using them.</li>
|
||||
</ul>
|
||||
<h3>Doug McIlroy, Bell System Technical Journal, 1978</h3>
|
||||
</section>
|
||||
|
||||
<section id="unix-philosophy" class="slide level2">
|
||||
<blockquote>
|
||||
the power of a system comes more from the relationships among programs
|
||||
than from the programs themselves
|
||||
</blockquote>
|
||||
<h3>The Unix Programming Environment</h3>
|
||||
<h3>Brian Kernighan and Rob Pike</h3>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<h1>Cloud Native Is ... </h1>
|
||||
<ul>
|
||||
<li>Architectural and operational approach</li>
|
||||
<li>Assume cloud</li>
|
||||
<li>Assume failures</li>
|
||||
<li>Microservices</li>
|
||||
<li>Containerized?</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<h1>12 Factor Application</h1>
|
||||
<h3>I. Codebase - One codebase tracked in revision control, many deploys
|
||||
</h3>
|
||||
<h3>II. Dependencies - Explicitly declare and isolate dependencies</h3>
|
||||
<h3>III. Config - Store config in the environment</h3>
|
||||
<h3>IV. Backing services - Treat backing services as attached resources</h3>
|
||||
<h3>V. Build, release, run - Strictly separate build and run stages</h3>
|
||||
<h3>VI. Processes - Execute the app as one or more stateless processes</h3>
|
||||
<h3>VII. Port binding - Export services via port binding</h3>
|
||||
<h3>VIII. Concurrency - Scale out via the process model</h3>
|
||||
<h3>IX. Disposability - Maximize robustness with fast startup and graceful shutdown</h3>
|
||||
<h3>X. Dev/prod parity - Keep development and production as similar as possible</h3>
|
||||
<h3>XI. Logs - Treat logs as event streams</h3>
|
||||
<h3>XII. Admin processes - Run admin/management tasks as one-off processes</h3>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>This is awesome</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>Except for III</h1>
|
||||
<h2>I use config files</h2>
|
||||
<h3 class="fragment">Ooops</h3>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>VI. Stateless</h1>
|
||||
<h2>If /dev/null is fast in web scale I will use it. Is it web scale?</h2>
|
||||
<h3 class="fragment">Use a service to store your data - like a database</h3>
|
||||
<h3 class="fragment">Is that database service web scale?</h3>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<blockquote>
|
||||
If /dev/null is fast in web scale I will use it. Is it web scale?
|
||||
</blockquote>
|
||||
<h3>MongoDB is web scale</h3>
|
||||
<p><a href='http://www.mongodb-is-web-scale.com/'>
|
||||
http://www.mongodb-is-web-scale.com</a></p>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<blockquote>
|
||||
The tragedy of modern man is not that he knows less and less about
|
||||
the meaning of his own life, but that it bothers him less and less.
|
||||
</blockquote>
|
||||
<h3>Václav Havel</h3>
|
||||
</section>
|
||||
|
||||
<section id="datacenter-as-computer" class="slide level2">
|
||||
<blockquote>
|
||||
As computation continues to move into the cloud, the computing platform
|
||||
of interest no longer resembles a pizza box or a refrigerator, but a
|
||||
warehouse full of computers. ... in other words, we must treat the
|
||||
datacenter itself as one massive warehouse-scale computer.
|
||||
</blockquote>
|
||||
<h3>The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines</h3>
|
||||
<h3>Luiz André Barroso, Urs Hölzle - 2009</h3>
|
||||
<p><a href='https://research.google.com/pubs/pub35290.html'>
|
||||
https://research.google.com/pubs/pub35290.html</a></p>
|
||||
</section>
|
||||
|
||||
<section id="unix-portable" class="slide level2">
|
||||
<blockquote>
|
||||
The use of top-down design methods and high-level languages in
|
||||
producing portable applications software is well established. By
|
||||
applying the same principles at the systems programming level,
|
||||
portability can be extended to the operating system itself. Although
|
||||
the Unix operating system was developed for a specific computer (the
|
||||
DEC PDPll), its concise and elegant design and the careful selection
|
||||
of 'primitives' which it provides make it an ideal candidate for
|
||||
portability.
|
||||
</blockquote>
|
||||
<h3>UNIX: a portable operating system?</h3>
|
||||
<h3>Richard Miller - 1978</h3>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>If the datacenter is the new computer ...</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>Then the power of OpenStack is as a portable Operating System</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>Just as MVS was an Operating System for IBM System/370 ...</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>AWS is an Operating System specific to Amazon Datacenters</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>Google Cloud is an Operating System specific to Google
|
||||
Datacenters</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>If sets of cheaper commodity servers are superior to fancy custom
|
||||
built high-end hardware ...</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2" data-transition='zoom'>
|
||||
<h1>Then commodity data centers with a common Operating System should
|
||||
be better than fancy data centers controlled by one or two companies
|
||||
</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<h1>Linux won the battle for single-computer Operating Systems.</h1>
|
||||
</section>
|
||||
|
||||
<section class="slide level2">
|
||||
<h1>Let's win the battle for a Free, Open and Portable Operating System
|
||||
for warehouse-scale computers.</h1>
|
||||
</section>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
Loading…
Reference in New Issue