The second NetDevOps Days kicked off at the end of last year in New York City, hosting professionals from around the world to learn from and educate each other about the full spectrum of technologies, best practices, and challenges in the network automation ecosystem. This one-day, vendor-neutral automation event proudly featured a distinguished group of top Network Automation experts who shed light on the latest in network automation.
In “A DevOps retrospective: What we can learn from a decade of DevOps to make sure we all win with NetDevOps,” Network Automation experts Mark Coleman, Chief Evangelist at NetBox Labs and Christopher Liljenstolpe, Chief Architect at Cisco Data Center Networks, joined forces to discuss all things DevOps.
Whether you saw this presentation in person, watched it online, or heard about this for the first time, we’ve compiled some key points and concepts from Coleman and Liljenstolpe’s discussion at NetDevOps Days – New York, so you can understand more about what DevOps is, and how we can learn from the last decade of DevOps.
What is DevOps and what is driving it?
“You can try to answer this question,” says Coleman, “but what you’re going to find out is that there are a million correct answers.” Or according to Liljenstolpe, “a million equally incorrect answers.”
Coleman has been working in the DevOps space before it was even known as DevOps. “When I worked at TomTom back in the late 00’s, we had tens of teams all trying to get their code shipped in specific release windows and hitting up against deployment challenges, testing challenges, it was hard and valuable features didn’t get to the customer on time because there was just so much mess in the way. We pulled together a group of people to try to figure things out and I later found out that what we were doing had a name: DevOps.”
Thinking back to when DevOps first popped up, Coleman remembers CALMS, an acronym for describing the fundamental properties of the DevOps movement, that stands for Culture, Automation, Lean, Measurement and Sharing. The elements all seemed correct but Coleman found it hard to work with. “Well, surely if I’m ‘sharing,’ that’s part of ‘culture,’” he says.
After living through a decade of DevOps, Coleman realized that “with all these amorphous things we’re trying to improve, DevOps isn’t just one thing, it’s everything.” It encompasses concepts like small teams, version control, loosely coupled architecture, shared vision, and more. “DevOps is an amalgamation of ideas,” he says. “It’s a collection of concepts to solve a specific problem and it has been very successful despite, or perhaps because of, lacking a nice clean definition.”
So, what was really driving DevOps? Coleman and Liljenstolpe say there are three main drivers that every company wishes they could be better at, some need to do all three, some a subset:
- Agility: The faster your product goes to market, the quicker you can test ideas and generate revenue.
- Resilience: From revenue to reputation, going faster is good unless you break too many things while doing it.
- Scale: The scale at which software is operating has, for many companies, exploded.
A brief history of DevOps
Like Coleman and Liljenstolpe, many first started looking for something like DevOps when they experienced the “the wall of confusion.”
“Back then, I would make sure my program compiled and ran locally and send it to ops. When I saw that code on the website or on the devices, I would have no idea how it got there. But I didn’t care,” Coleman says. “At the time programmers ‘throwing it over the wall’ like this was commonplace and it was a huge symptom of the underlying problem.”
In the wall of confusion phenomenon, two groups (in this case dev and ops) have a locally optimized view of when their job is complete. I’ve sent my code, I’m on to the next thing. “I used to ship code and then the ops would say, ‘It’s not performing, it’s not fast enough.’ I would be thinking, ‘I don’t have time for that, I’m already working on the next feature. It’s hard to imagine these days.’”
The reason for this wall of confusion is clashing incentives, “developers were incentivized to make new features, to make change happen.” Operations on the other hand, have a different set of incentives, says Coleman. “Operations were incentivized on stability. Change and stability, don’t mix well without the right tooling and practices in place. This is kind of why DevOps came along in the first place,” he explains.
In Liljenstolpe’s experience, the wall of confusion made things so frustrating that sometimes “if operations people were gone for too long, we’d start replacing things,” he says. “Otherwise, we just shipped changes and told them they had to go justify why this router was out of configuration.”
“One thing that makes DevOps hard is complexity,” Liljenstolpe mentions. “As you add complexity to the infrastructure you’re working on, it makes improving the processes around it inherently more difficult.” Complexity can come from scale, churn, or the things you need to automate. But from an infrastructure perspective, Liljenstolpe says complexity is like carrying the burdens of our past with us. “We carry all of this old stuff with us, and we have no idea if it is still necessary. When the complexity keeps building and building, now we have a bigger state engine we have to automate.”
Liljenstolpe continues, explaining, “this is why we’d all get unhappy when vendors changed the command line interface (CLI). Because we had thousands of scripts we had to go change.”
To capture the benefits of DevOps, Liljenstople says, “infrastructure operators need to get to the point where they’re willing to leave a lot of the old design patterns behind. This is necessary because it reduces the state and the scope of the state that we actually want to automate.”
To fix this, “we need better tools,” suggests Liljenstolpe. “We need better APIs, and we also need to be realistic about what things we actually need to automate. By simplifying our infrastructure, it should make things easier to automate moving forward.”
Which leads to our next question…
When will DevOps come to the world of networking?
“NetDevOps is why we’re all here today,” says Coleman “, but the naming is unimportant. It’s the underlying drivers that are important. Do you have teams who are locally optimizing their work to the detriment of the business? Do you have challenges with the agility of your networking teams, are your networks less resilient than you’d like them to be? Are you being asked to deal with bigger and bigger networks? If so then looking into Devops practices is advisable.”
For Coleman, the growth of NetDevOps will benefit from the rich legacy of DevOps. “We can actually take everything people have been doing for the last decade in DevOps and use most of it – to stand on the shoulders of giants so to speak,” Coleman says. “The one bit that isn’t taken from the last decade of DevOps, the bit that’s networking specific, that’s the bit we’re going to go and fix together,” he explains.
At the beginning of any movement, the ability to change direction is huge. Moving forward, Coleman and Liljenstolpe are confident about two things: That it’s a great time to be doing NetDevOps (or whatever you call it where you work!), and that each and every one of us is capable of doing it. “Somebody can write a blog post that changes the way we all think about NetDevOps and it’s probably going to be a person in this room,” says Coleman. If you’re reading this right now, perhaps it could be you too.
Watch the webinar to learn more from Mark Coleman and Christopher Liljenstolpe, or explore more expert talks from NetDevOps Days – New York.
Editor’s Note: NetDevOps Days has joined forces with AutoCon! Learn more.
