Episode: 10 Apr 2019
http://www.thecloudcast.net/2019/04/network-reliability-engineering-nre-nre.html
Interesting show and a great idea to reduce the barriers to entry for networking folks wanting to learn automation skills, but the idea of focusing narrowly on network reliability engineering as a take off from site reliability engineering really seems to perpetuate the network silo. The concept is “Site RE,” and expressly not Dev RE, Ops RE, Net RE, Security RE… More on this in the later discussion of frustration about getting an API key.
Around 16:00 there’s discussion about the inadvisability of putting a new release of networking system software on a prod device because it’s expected to be buggy. Paraphrasing, Automation is about reliability, not about going faster. This idea isn’t really explored. It’s not clear why the goal can’t be both better reliability and iterating faster or even if one reinforces the other.
Around 17:15, discussion about the name “DevNetOps”: DevNetOps as a term is as barfy as anything that overloads DevOps, which is “supposed to be” the organizational construct that takes a business problem and creates a collaborative IT solution to provide business value.
It’s fine that the networking staff is automating, but why are they automating? Can the networking person describe how the automation project brings value to the business? For that matter, what’s the value to the business of networking staff taking time to learn the prerequisites like version control?
Test driven approach [using a declarative approach with tests written to validate the config on the way to production deployment] This was a teaser of an interesting topic applied to network configuration and deployment, but ended up being mostly about measurements rather than what tests might be useful and sketching how to implement them besides simply measuring, say, latencies in the lab and later in prod.
I understand the podcast is time limited, perhaps it’s worth returning to test driven development as applied to networking functions. One could even blue sky a domain driven design for networking infra with micro domains of bounded context that would decouple the networking "monolith."
When I hear that networking staff are trying to use automation tools more effectively, but are frustrated by the prerequisites such as getting an API key, I’m wondering how integrated the staff is with the dev or ops-deployment side of the organization.
Typically a dev person in an organization with basic DevOps culture would show the person how to do it, pair programming style. Even as a minimum the dev would say, “Go to StackOverflow, if the answer can’t be Googled.” If a dev wouldn’t provide that help, the organization has bigger problems than getting an API key.