To Be Continued: Release Engineering Tools at Netflix

It is fitting that our first episode to be split into a TV-esque cliffhanger is with our Netflix panel! In episode 28, we discussed Netflix’s unique engineering culture; in part two, we discuss with the panel the dynamics of how Netflix develops its release engineering tools, Netflix’s cloud prize, configuration management vs. baked potatoes, what percentage of the Internet Netflix actually uses at peak, plus the panel’s guilty (and possibly embarrassing) Netflix pleasures; find out what they are and more when we wrap up:

To Be Continued: Release Engineering Tools at Netflix

Join J. Paul Reed, aka @SoberBuildEng, Youssuf El-Kalay, aka @buildscientist, EJ Ciramella, aka @eciramella, Sascha Bates, aka @sascha_d, and Seth Thomas, aka @cheeseplus plus another installment of #DevOpsDearAbby!

Or, download Episode 29, or any of our previous shows!

Show Links/Notes

DevOps Dear Abby

@zsepi asks “Despite having worked maintenance years on legacy codebases at BigCo, I don’t see why people keep picking on ‘enterprise developers’; shouldn’t we approach code with the assumption that everyone did their best given the circumstances (culture, skills, deadlines, etc.)?

@StevenMurawski asks via email:

Why are ops guys in primarily Windows environments looked down upon (or feel looked down upon) in the DevOps community? Very often references will be “oh, and on Windows” like the ops guys running Windows wouldn’t be expected to be as professional as their compatriots on the *nix side of things. How can a primarily Windows ops guy fit in to this DevOps community?

Join Us!

What’s your design and testing process for your organization’s build/release engineering tools?

Do you use active configuration management or the “baked AMI” approach?

Join the discussion!

Tags: ,

Comments are closed.