For years the cornerstone of the "DevOps" movement has been lots of people urging sysadmins and operations engineers to get better at writing code.  "You can't be a real devops engineer unless you write software and tests!", they say.  Well, they were right, and message has been received.  Writing software is now a part of every engineering interview.  

But ... is that where it stops?  What about all the developers who barely know how to log in and debug their own software, or who have no idea what happens to their code after they deploy it?  They need DevOps too ... or rather, they need "OpsDev".  They need the critical skills that have long been associated with operations and systems engineering: reproducing complex bugs, optimizing queries, designing and building resilient infrastructure, deploying their own services, instrumenting them for debuggability, scaling and owning and monitoring high quality services.

This is not just a fuzzy culture talk, it's a very practical talk filled with real tips and stories from teams that have undergone the hard switch.  Lots of software engineers dread this transition, but 1) you aren't really going to have a choice before long, since dedicated ops teams to clean up messes are fading away, and 2) this is a better world and you should want it!  Having solid ops skills makes you a superhero.  Empathy and shared crossfunctional skill sets create a better world for all of us.

 
1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

-- introduce history of devops

-- traditional divide between ops and dev

-- discuss trends in industry: scarce eng cycles, dwindling ops resources, remaining teams are powerful and impactful (orders of magnitudes more nodes to human ratio)

-- in the future, ops primarily communicate with dev via APIs and vice versa.  the in-house ops team is becoming a rarer phenomenon

-- ops aren't going away, but they are working behind APIs like Dyn, AWS, etc.  This means ... SWE's are in charge of their own services.  SWEs are doing their own ops.

-- how is SWE ops different from traditional infra ops?  (flip side: how is infra programming different than SWE programming?)

-- what specific skills are most critical, and which can you discard?  give examples of things to work on learning in: instrumentation, debugging, alerting, performance, db query tuning, etc

-- common pitfalls done by opsdevs: overalerting, burning out, more

-- why is this a glorious future, why should you be happy to say goodbye to siloed development?  because you are a more powerful, happy and self-sufficient engineer

-- thank you!!

Learning Outcome

Tips, tools, tricks for addressing the transformation and education of software engineers in your org who are adopting ops skills.

What do you do when you can't hire enough ops engineers to fiill your need?

What to do when things go wrong -- disaster stories and how to recover.

Target Audience

Engineering managers, ops, developers, software engineers, directors

schedule Submitted 6 months ago

Comments Subscribe to Comments

comment Comment on this Proposal