Words are Hard with Emily Freeman

Matty talks with Emily Freeman, author of DevOps for Dummies, about how DevOps has changed and what comes next. Both had just started new jobs: Emily came from Microsoft's cloud advocacy team to AWS, working on DevOps strategy and messaging across the product line, and Matty left Red Hat for Pulumi, an infrastructure as code startup, with several former Chef colleagues, doing developer advocacy. Matty notes the show began at the end of 2013, so it has existed for most of the time DevOps has. The cold open is Emily on the explicit tag: "Have you fucking met me?"

What's Next for DevOps

Emily says the market is hungry for the next phase. Agile was about 20 years ago and DevOps 11 or 12. When Andrew Clay Shafer and Patrick Debois started it in 2009, teams were siloed with code thrown over a wall, and DevOps was a solution for bringing them together, which has mostly worked, though renaming the operations team a DevOps team "is not DevOps." Now the systems are distributed, the people are too, and the cloud adds managed services that remove pain but can cost visibility. Emily is thinking about how to capture telemetry and observability without getting into the weeds, and whether machine learning can help.

Matty says black boxes aren't inherently bad, and you need to know the promise is fulfilled and what to do if not. Matty compares it to Chef customers who asked how Chef does all 16 steps to build a server, when changing step 2 makes steps 3 through 10 unnecessary. Emily says systems are "a spaghetti of roots" like plant roots, so looking only at system A may miss the impact of B or C. Matty says you need to know things to the boundary at which you can influence change, like not knowing the power company rerouted your electricity.

Not All Silos Are Bad, and Left Means Awareness

Matty says DevOps over-rotated on culture because engineers will play with tools anyway, and that "not all silos are bad," as with literal grain silos, which exist for safety. The goal is cross-functionality, not NoOps. On shifting left, Matty says you push awareness and consideration left, not the work, and recalls the example of a colleague at a 1990s mail order company who kept being asked to teach everything about Photoshop in an afternoon. Emily agrees that being aware of someone's specialty, constraints and motivations is different from knowing how to do it, such as reading JavaScript without being a front-end engineer.

Emily adds that terms like "shift left" have gotten hand-wavy and people want to know how to apply them. Matty recalls 2014, when every devopsdays talk was about empathy because nobody knew what it was, and now people ask how to deal with people. Matty jokes that removing code from prod is "shipping left." Emily thinks DevOps is in late adoption, and Matty says the adoption phases overlap, noting that after a year working with state and local government many people still need the basics and others ask how to do it.

Cloud Engineering and Platforms

Matty has been thinking about cloud engineering as a discipline, which is what many people mean by SRE, although SRE is a specific way to implement it. Matty says a platform team is essentially an internal Heroku: a service with an interface, so feature teams don't need the nuts and bolts. Emily says it's a "service with an interface. That's it." Matty says a platform doesn't need bespoke Kubernetes, and can be cobbled together from other services. Matty also says the multi-cloud myth is the lowest common denominator unless you build a platform in front. Emily describes cloud engineering as being an infrastructure optimizer.

Visibility and Value

Emily asks how to stop valuing people by their place in the stack: front-end, back-end, platform, infrastructure. Some organizations favor devs, and Google in Emily's view over-indexes on SREs. Emily says much of spreading awareness is removing the fear of not being valuable, and that the empathy talked about for 12 years means "this shit is hard." Matty says it's a visibility problem: ops is like being a corporate lawyer, known only when something fails. Sales is the most visible part of an organization because everyone understands its value, and the further down the stack, the closer to utility, like a power company, the less visibility. Matty says this is why NoOps was a bad idea and likes the term operational excellence.

Words Are Hard

Matty recalls an early guest saying the value of DevOps is that it frees up the most important resource, the developers, which was the quiet part said out loud. Emily says massive companies saying they're obsessed with the developer is fine if inclusive, but about 90 percent of the operations community does not identify as a developer. Emily defaulted to engineer for the book and notes AWS uses builders, a term Emily hasn't heard outside that ecosystem. Matty: "Words are hard, which is that is what we're going to call this episode." Emily says you can appreciate someone's value without taking on their responsibility, like knowing how to change windshield wipers but not tires.

• The Best DevOps Blogs (the review giving ADO 5 out of 5)
• DevOps For Dummies