NRE Labs NRE Labs In The Wild, 21 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Seven Deadly Deceptions of Network Automation

Description

It’s been a journey discovering DevNetOps and network reliability engineering. With help from peers and NRE friends, I’ve faced debate and dogma forged in the fiery cynicism of the networking I&O silo. To share these lessons, let’s overturn some anti-patterns and deceptions.

Original blog:
https://jameskelly.net/blog/2018/3/20/seven-deadly-deceptions-of-network-automation

Shared on DZone:
https://dzone.com/articles/seven-deadly-deceptions-of-network-automation-podc

A

Welcome back, this is James Kelly. This is seven deadly deceptions of network automation. Before we start just a quick. Thank you as usual to everybody that subscribes on James Kelly dinette follows me on LinkedIn shares and likes my stuff there or wherever Twitter SoundCloud youtubes, where I post the podcasts right just a big. Thank you. So seven deadly deceptions of network automation. We start off with a quote from the great man Leonardo da Vinci. The greatest deception men suffer is from their own opinions.

A

Network automation does not an automated network, make those same words started my formative piece on dev net ops, it reasoned that we must elevate, DevOps culture processes and principles above technology and random acts of network automation and instead pursue holistically automated network engineering and operations. The professional that implements this from code to production is the network reliability, engineer, NR II the NRI implements Devon adopts for network infrastructure, just as the sre implements DevOps for apps and platforms.

A

It's been a journey, discovering definite opsin NRI, with the help from peers and NRI friends, I've faced debate and dogma forged in the fiery cynicism of the networking, I and ho silo to share these lessons. Let's overturn some anti patterns and deceptions, starting with the opposite of the NRI. Those who say automation is not for me one. It's not for me. You used to hear people say we're not Google. We don't have those problems or need those solutions.

A

Today, everyone is mad for giffy Google's infrastructure for everyone else, and racing for the same outcomes as the unicorns. If you think you're a thoroughbred horse in a different race, you're utterly deceiving yourself and your business is heading to the glue factory. Before we can change our minds, we must open our minds. Life is an inside job if you're a network admin. The rationale to retitle yourself as an NRI is right in front of you.

A

Look forward, you'll see a future less doldrum, more creative and one where you have more control over your own destiny and that of your organization and more pay and job opportunities. Yes, NRI is an actual job title with retitling comes reform. You used to rely on vendors for all Network engineering, but this relegated operations, people to technicians instead of technologists as an NRI. You don't need to hop over the proverbial dev ops wall to engineer boxes or Sdn systems.

A

You just need to lower the wall and pick up where vendors leave off their day of product delivery to market and to you is your day: zero, where you automate not only integration, workflows, but outcomes like accuracy, reliability, scale, efficiency and hops. Speed.

A

Deception and myth number two: it's all about automation and technology rod. Michel said if you automate a mess, you get an automated mess. Automation must follow architecture and accuracy. It's common for builders to want to build, but you cannot be so Swift as to forget the blueprints. There's a balance to strike between build and design. To be sure, a DevOps mindset promotes build iteration, as did Mark Twain when he said. Progressive improvement beats delayed perfection.

A

Of course, it's not all planning processes or forging culture, but technocrats tend to obsess over technology too much network, reliability, engineering and Devon adopts is not only about technology. Just as racing is not only about cars number three. It's only about open source, look I'm, a proponent of open source and believe it aligns with human nature, from github to the growth of the CNC F and so many other projects. The open source watershed has hit, however, especially in networking.

A

There is plenty of closed-source, fortunately, open api's make integration and automation possible even for closed systems. Today, open api is are increasingly commonplace because they're, not a nicety they're, a necessity. Moreover, the as code get ops and see ICD movements shine the automation spotlight onto pre-production pipelines and processes. These trends are supported by and apply equally to open and closed source software. So don't like closed source deter your Devon adopts desires, deception, number four, it's incompatible with ITIL, InfoSec, Ino or Hardware.

A

You might believe, there's no need for infrastructure, rapid iteration, agility and experimentation, but just because you don't need all the benefits of a DevOps culture doesn't mean you don't need any. You may also deceive yourself thinking. Networking is different, but just because network hardware is more foundational than application. Software and less flexible today doesn't make definite ops ideas impossible. In fact, it's precisely because networking is foundational that having it automated is crucial and we'll add simplicity and flexibility.

A

First of all, there's a large software side to networking Sdn and a fee network management where we can more easily apply definite ops, behaviors, translating some behaviors like CI CD and chaos. Engineering to network devices, however, isn't straightforward. In a past article on the new stack I examined difficulties of aligning agile to today's architectures in network operating systems, boxes and topologies.

A

In reaaargh attacking networking for dev net ops, we ought to draw inspiration from micro services, obviously a catalyst for the traditional DevOps transformation, because smaller architectural units allow for smaller, safer and speedier steps of change. Finally, many DevOps practitioners have overcome organizational policy barriers like ITIL and InfoSec has well established in the DevOps handbook. Success lies in rallying anarchy, rather the DevOps principles, automate, insecurity, compliance and consistency.

A

Number five: it's not obvious where to start well. The territory is now increasingly marked with maps, training and didactic case studies, but don't mistake studying for starting complement your wonder with some wander, try playing with get sharpen up your programming fingers and give that tool the world. There are many paths to success, even if your journey is serpentine, even if you lose TrueNorth, you may pick up useful tools and lessons in unexpected places like building any new habit. It's useful to have a buddy or better.

A

Yet a two Pizza team, you'll progress, quickest in green fields to choose a team project that has no technical debt when you're just starting out and take small wins and small risks. When you allow for failure and iteration, you record the lessons into processes and automated systems and you grow people.

A

The easiest place to start is at the beginning of the project stream, where it's small, not down in the ocean, start at a zero and flow from pre-production to production, build as simple as an automated pipeline as possible to integrate artifacts secrets and configuration is code. You can mature, expand the middle like pipeline, orchestration, building, testing integration, more testing and mutable deliveries and finally orchestrated deployments into staging and then production.

A

Eventually, beyond networking and Sdn automated deployments, you will have other in production, automation, extensions for system, integration and event handling that can follow the same pipeline deception. Number six, it's all about speed I want to go fast. That was a quote from Ricky Bobby. You remember: Will Ferrell played him in Talladega Nights.

A

Keeping up with the pace of Technology is ever harder and so goes to saying. The future belongs to the fast, but when it comes to automation, the NRE title tells us something very important. We must focus on reliability.

A

Speed alone will never win a race and speed without reliability is a glorious way to crash and burn just ask rocket scientists if you're a race car driver one smarter than Ricky Bobby. You would say that to finish first, you must first finish a twin burden today. Equally, as confronting as the need for speed is complexity, you know if Dijkstra a networking hero for his SPF algorithm were alive.

A

Today he would be a champion of network reliability, engineering, simplicity, a coincidental port, Mon towing of NRI and the juniper Anthem, because of his famous quote, Dijkstra's famous quote: simplicity is prerequisite to reliability. In summary, we need speed and we need smart. We must be consistent with simplicity, effectiveness, efficiency and reliability. Smart, while employing the economies of velocity agility scale and reach speed.

A

We all love going fast, but it's not how fast you drive it's, how you drive fast and finally, deception, number, seven, it's all about Devin adopts an NRI. The hype of DevOps, an SRE, is probably warranted if you seriously put it to work. I believe the same is true for deaf net ops, an NRI. However, these are just signposts like the Buddhist lesson that the finger pointing to the moon is not the moon itself. If you miss the moon for the finger, you've missed the glory.

A

The real truth in technology is that transformation is the only timeless topic. Digital transformation has been around for three decades and digital intelligence transformation is probably on its way next to manage transformation in technology equipped for an evolvable architecture and process, incorporate continuous improvement and in people embrace continuous learning. I'll leave you with a final quote: I often use when speaking on these topics.

A

It's not the strongest of the species that survive nor the most intelligent, but the one most responsive to change that was Charles, Darwin and finally waving the NRA flag live at open networking summit next Wednesday at 11:15, Matt, O's, well and I will be speaking on NRE and Devon adopts at the open networking summit. We will be joined by Doug lardo from Riot Games, who will share his lessons from the front lines if you happen to be there.

A

Please join us if not take to Twitter, and let us know what you think there or comment below if you're reading the article on how you see the evolution of the NRE, that's it for this episode. Thanks again, this has been James Kelly. Reading the seven deadly deceptions of network automation, my own article published Wednesday, March, 21st, 2018 and again thanks to everybody that likes follows or shares this stuff. You can find more on James Kelly net and my LinkedIn I'll close with a quote from Turing Award winner Tony Hoare on reliability.

A

He says the unavoidable price of reliability is simplicity,.