Skip to content

Instantly share code, notes, and snippets.

@temujin9
Forked from ryanj/gist-reveal.it-slides.html
Last active March 8, 2019 12:51
Show Gist options
  • Save temujin9/071dfc16a11833db2af57437f93a8dcb to your computer and use it in GitHub Desktop.
Save temujin9/071dfc16a11833db2af57437f93a8dcb to your computer and use it in GitHub Desktop.
Gist-powered Revealjs slideshow presentations http://gist-reveal.it
<section data-background-transition='zoom' data-transition='concave' data-background='http://ryanjarvinen.com/presentations/shared/img/broadcast_reveal_dark.png' data-state='blackout'>
<h1>Rebuild From Scratch:</h1>
<h2>Hashistack, Kubernetes, and Creative Destruction</h2>
</section>
<section>
<h2>Here's the deal:</h2>
<ul>
<li class="fragment">I think I only get about one good basic "why Kubernetes" talk in me before the market completely oversaturates.</li>
<li class="fragment">This is that talk. I'll try to keep it at least a little technical.</li>
<li class="fragment">Like most presentations, this is semi-autobiographical. I'll try to keep it at least minimally relevant.</li>
<li class="fragment">Like much of what I write, this ends up making some impolite commentary about good people's good work.</li>
<li class="fragment">I will try to front-load this with my failures, so you can take my trash talking with plenty of salt.</li>
</ul>
</section>
<section>
<h2>Ancient History:</h2>
<p>I started programming when I was 14, and at 15 I was literally hired off the street to program . . . </p>
<p class="fragment"> . . . which set unrealistic expectations for how easy it would be to get future programming work.</p>
<p class="fragment">Especially since I started getting into web development in 2000 . . . just in time for the bubble to burst.</p>
<h1 class="fragment"><em>FUCK</em></h1>
<p class="fragment">(My apologies for the profanity, but it won't improve.)</p>
</section>
<section>
<h2>Skipping Ahead</h2>
<ul>
<li><strike>PHP horror stories</strike></li>
<li><strike>Found DevOps at National Instruments</strike></li>
<li><strike>Open-sourced Ironfan and Cloudformation-Ruby-DSL</strike></li>
<li class="fragment">Really what I am good at is using open source software</li>
<li class="fragment">. . . and Google</li>
</ul>
</section>
<section>
<h1>Picking Losers</h1>
<p>Early example: I decided around the time that I worked at National Instruments that what the open source world needed was a High Availability LAMP stack. I was going to call it . . . </p>
<div class="fragment">
<h2>CLAMP</h2>
<p>Cluster Linux Apache MySQL PHP</p>
</div>
<h1 class="fragment"><em>FUCK</em></h1>
</section>
<section>
<h2>Ironfan</h2>
<ul>
<li>Familiarity: first thing of this sort I'd worked with, and I'd gotten good at it.</li>
<li>Association: had already been at the helm of it for a while.</li>
<li class="fragment">Ultimately didn't have support of the company behind it.</li>
</ul>
<h1 class="fragment"><em>FUCK</em></h1>
</section>
<section>
<h2>Bazaarvoice</h2>
<h3>Leaving Configuration Management for Container Orchestration</h3>
<ul>
<li><strike>Once had a much longer presentation on this, which included gross barnyard analogies.</strike></li>
<li>Configuration Management is ultimately a halfway step, replicating old-school ops practices in tech.</li>
<li>High degree of centralization: Chef runs, for instance, innately couple all parts to all other parts.</li>
<li>Container Orchestration decouples the application from the machine, allowing proper separation of concerns.</li>
</ul>
</section>
<section>
<h2>BV Flynn</h2>
<ul>
<li>"You're British, so scale it down a bit."</li>
<li>Knew that I had to produce results fairly quickly if I wanted to sustain buy-in.</li>
<li class="fragment">Ultimately too full-stack to play nice with other ecosystems, too small to compete.</li>
</ul>
</section>
<section>
<h2>Hashistack</h2>
<ul>
<li>Struck out on my own from Bazaarvoice, founded Greenfield.</li>
<li>Started building replacement for bv-flynn in Terraform.</li>
<li>Watched demos from Hashistack folks, realized how far ahead of Flynn their ecosystem was.</li>
<li class="fragment"><h1><em>FUCK</em></h1></li>
<li class="fragment">Ultimately ran into "non-standard deploy" issues, and realized that Kubernetes had won.</li>
</ul>
<h1 class="fragment"><em>FUCK</em></h1>
</section>
<section>
<h2>Why Brag On This?</h2>
<ul>
<li class="fragment">They were the right choice in the context.</li>
<li class="fragment">Changing your mind in technology is a virtue.</li>
<li class="fragment">Every failure was a guidepost.</li>
<li class="fragment">This is what it feels like to be ahead of the curve as a user: you pick a lot of eventual losers.</li>
<li class="fragment">The closer you get to a breaking wave, the more often you're going to need to cuss and reorient.</li>
</ul>
</section>
<section>
<h2>Terraform</h2>
<ul>
<li class="fragment">Infrastructure-as-a-Service provider abstraction.</li>
<li class="fragment">That's it, but that's enough.</li>
</ul>
</section>
<section>
<h2>Kubernetes</h2>
<ul>
<li>High availability and high efficiency architecture out of the box.</li>
<li>"Amenities": the ability to provide common tooling that requires little or nothing to use.</li>
<!-- Ingress controller, logging, etc. Deep end is serverless, or maybe nocode. -->
<li>"The Airplane Rule": the core tools work the same on your laptop as they do in the cloud.</li>
<!--
- No longer able to call it the airplane rule, thanks to in-flight wifi
- Minikube provides out of the box
-->
<li>Packaging: Helm let me go from zero experience to automated Wordpress in 2 normal workdays.</li>
</ul>
</section>
<section>
<h2>What It All Gives Me</h2>
<ul>
<li class="fragment"><strike>KLEMP - Kubernetes / Linux / Nginx / MariaDB / Python</strike></li>
<li class="fragment">Predictable shared build architecture.</li>
<!--
- "works on my machine" issues are lessened when every build uses a Kubernetes setup
- Imagine the chaos if every part of your organization insisted on using a different version control system for the same code
- Now imagine how you'll feel in a decade, looking back at the obnoxious variety of different ways your code deploys across environments
-->
<li class="fragment">A standard to develop against.</li>
<!--
- Kubernetes' won the container management wars: Google, Microsoft, and even Docker all support it, and the market for talks about it is saturating
- Like Ubuntu Linux, or a three prong plug: a simple-to-describe interface I can expect to be ubiquitous is usually a better strategic choice
-->
<li class="fragment">A tool I can largely just <em>use</em>, with less glue code than before.</li>
<!--
- Ultimately, 80%+ of what I write is glue code, so the savings here is actually pretty important
-->
</ul>
</section>
<section>
<h2>Rebuild From Scratch</h2>
<ul>
<li class="fragment">"Backups don't matter. Restores do."</li>
<li class="fragment">Rebuilds are restores for architecture.</li>
</ul>
</section>
<section>
<h2>Why do you keep throwing old tools away?</h2>
<ul>
<li class="fragment">"Code is a liability." -- Charity Majors https://twitter.com/mipsytipsy/status/957788851140882432</li>
<li class="fragment">Every line of code that you maintain weighs you down.</li>
<li class="fragment">Stop maintaining code that isn't core to your business.</li>
<li class="fragment">Celebrate every time you get to throw out custom code in favor of standard tools.</li>
</ul>
</section>
<!--
Hands up:
- Who uses Linux in their enterprise deployments today?
- Who uses BSD?
- Who uses AIX?
- Who uses OS/2?
- Who uses Multics?
Kubernetes has reached critical mindshare for container orchestration, the way Linux has for internet servers. Any competing system is now fighting an uphill losing battle against network effects. This is happening now. Expertise with Kubernetes is going to be wildly valuable.
The bad news is that you may be able to sell your Chef or Puppet expertise until you retire, but at some point they're going to go the way of OS/2 and Multics.
The good news is that if you can use Chef or Puppet, learning Kubernetes is no great hurdle, and there's no better time to do so. If you don't have the option of using a native implementation (AWS, GCloud, Azure, and others), Terraform can help you get there, and can also help you manage your other cloud resources.
-->
<section>
<h2>Thanks</h2>
<p>Nathaniel Eliot</p>
<p>@temujin9</p>
<p>The Greenfield Guild</p>
<h3><a href="http://gist-reveal.it/071dfc16a11833db2af57437f93a8dcb">http://gist-reveal.it/071dfc16a11833db2af57437f93a8dcb</a></h3>
<!--
- If you'd like help with Kubernetes, we'd love to talk.
- If you want to freelance with a team that's all-in on Kubernetes, let me know.
-->
</section>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment