The Oregon Trail to Kubernetes [I]

Can a small team operating 2000 CPUs, escape the glorified bash infighting of Configuration Management to homestead the scalable compute plains of Kubernetes? A journey of transitioning from Googles …

Can a small team operating 2000 CPUs, escape the glorified bash infighting of Configuration Management to homestead the scalable compute plains of Kubernetes? A journey of transitioning from Google’s Compute Engine to the blessed Container Engine. The route we chose diverged from the never ending landscape of single purpose YAML tutorials and retreading Configuration Management tools with templating. Instead, we chose a mountain pass of defining Kubernetes Resources as Go code for compiled type checking, composability, validation, and potential for extension. The case study of a small team breaking trail through ecosystems of application design, schedule paradigms, deprecation dysentery, and holding legacy together with bailing wire. A retrospective of value added versus time wasted on the path to great opportunities on Kubernetes. Talk Overview: Lytics Stack and overview(whoami) Loading the Wagon: Design and decision considerations(Read the Borg Paper) Deprecation Dysentery: Wait wait don’t use that. Mirages of disappointment: Systems which couldn’t make it to Kubernetes. Compute Resource Hunting Massacre: Avoiding compute underuse; taking advantage of scheduler. Handyman’s Corner: The bailing wire and zip-tie Kubernetes tools and services built to keep the broken axle(legacy systems) intact through the journey. Blizzards of the Kubernetes: from a user’s perspective who can’t follow every SIG; surviving the avalanche of ecosystem changes. Cascadia found: the wins, plans to rebuild what was abandoned, and breathing the free air. Next: Sim City